Proposal/questions: Support for "cloning" assets

Proposal/questions: Support for "cloning" assets

by Brad Smith -
Number of replies: 4

Hello all,

First, a disclaimer: I've been digging through docs and source code for a while now as I maintain and customize a Moodle instance at work, but there's still a lot about the internals that I don't understand, and it's possible that I'm just missing something obvious here. Please accept my apologies in advance if that's the case, especially if I come across as presumptuous, or critical of a sensible design. 

Ok, so, here's the short version: 

Looking at the database schema underlying Moodle, it seems that the many:many relationship between courses and module instances via the course_modules table could provide the level of abstraction needed to allow an activity or resource to have instances in more than one course at a time. Let's call this "cloning" an asset. Unlike importing an asset from another course, which creates an independent copy, updates to a cloned asset would affect every instance of it. This would be very useful in situations where assets are frequently remixed into custom courses, where importing can create a maintenance nightmare. 

The thing is, there are a bunch of other things in the db schema that seem to negate how useful this could be, and I don't really get why they're there. 

Words get cumbersome at this point, so I took some time to put together a gDocs drawing to describe examples of what I'm talking about (no Google account necessary to view), as well as a proposed solution. You will probably need to zoom in to read it properly-- just select View->100% from the menu, or use the magnifying glass tool:

https://docs.google.com/drawings/d/1Sl-xWv_b8GpD2rG-EUfvvMqJMNMaQ999h1LMdQSG8lc/edit?usp=sharing

I realize that this would be a huge undertaking, and maybe not enough people besides me care about this feature to make it happen, but if there's a good reason to not even try I'd like to know, in case I decide to mess around with it, and just for the sake of understanding. 

Thanks to anyone who can offer suggestions and/or clarifications (btw, I've enabled comments in the doc in case annotating one of the images is easier).

Average of ratings: -
In reply to Brad Smith

Re: Proposal/questions: Support for "cloning" assets

by Brad Smith -

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: -
In reply to Brad Smith

Re: Proposal/questions: Support for "cloning" assets

by Damyon Wiese -

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: -
In reply to Damyon Wiese

Re: Proposal/questions: Support for "cloning" assets

by Brad Smith -

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: -
In reply to Brad Smith

Re: Proposal/questions: Support for "cloning" assets

by Simon Coggins -

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.

Simon

 

Average of ratings: -