Future major features

Proposal/questions: Support for "cloning" assets

Picture of Brad Smith
Re: Proposal/questions: Support for "cloning" assets

Bump? I realize I got awfully wordy here, and maybe I'm completely off-base with the whole idea, but if anyone out there has a solid enough understanding of the rationale behind the current database design, to say so, even "you're way off base (and here's roughly why)" would be great to know. Otherwise, maybe this is an opportunity to make some improvements in upcoming versions?

Average of ratings: -
Re: Proposal/questions: Support for "cloning" assets

Hi Brad,

Thanks for your suggestion - here are some other ways you can achieve parts of what you want:

Importing Activities (static copy - updates to the parent are not reflected in the child)

Have one course and enrol mutiple groups of students into it (one copy - cannot be shared at the activity level)

Use LTI and have Moodle as both a provide and a consumer (does mostly what you want). Checkout the LTI provider in the plugins database.

In the database now each activity instance is associated with one and only one course module record - changing this would break many many things.

Cheers, Damyon

Average of ratings: -
Picture of Brad Smith
Re: Proposal/questions: Support for "cloning" assets

Thanks for the tip about LTI. I'll look into that.

I'm still curious as to why that "one and only one course module" limitation exists, if anyone has the time and inclination to explain. If there's a reason for it other than the fact that other stuff has already been built on top of it then great, but if it's a design flaw then perhaps correcting it could be considered for the next major version that doesn't guarantee backwards compatibility? Either way, I acknowledge that this isn't the sort of thing that would just be changed in an update to the 2.x line. 

Average of ratings: -
Simon Coggins
Re: Proposal/questions: Support for "cloning" assets
Core developersPlugin developers

I don't know of any specific reason, other than I guess that it wasn't a requirement at the time it was implemented the way it is.

As a feature I think it would be great, and we actually gave it some thought as to if we could implement something like this for Totara, but it is hard to see a path to making such a fundamental change to the existing code.

For example, I suspect it would break moodle's hierarchical capabilities system. If you have a forum activity for example, in mdl_forum:

id name
1 My forum

And you put the same instance in two courses via mdl_course_modules:

id course module instance
1 2 11 1
2 2 11 1

Then the context table will need to look like this:

id contextlevel instanceid path  
1 10 0 /1 Site context
2 50 1 /1/2 Site course
3 40 1 /1/3 Miscellaneous category
23 50 2 /1/3/23 Our first course
24 70 1 /1/3/23/24 Our forum activity in course 1
47 50 3 /1/3/47 Our second course
48 70 1 /1/3/47/48 Our forum activity in course 2

So now any changes to activity level capabilities are no longer stored in one place, plus you need to figure out which courses contain the activity so you can rebuild the cache, and before you know it you have to rewritten accesslib.php smile.

You can see how a single modified assumption (one course module record per instance) can lead to further changes to other assumptions (one context per instance), which then leads to more changes...

So yes, something for Moodle 3.x I suspect.



Average of ratings: -