UniSA's Assignment Extensions Module 1.9 -> 2.x

Re: UniSA's Assignment Extensions Module 1.9 -> 2.x

by James McLean -
Number of replies: 1

Having just had a look at mod_assign, can anyone think of any reason why extensions::update_duedate() can't be called from get_coursemodule_from_id() (lib/datalib.php:1470) ?

It's a common function that all activities (infact all modules) call, and if it can be done without introducing too much overhead, it could be a reasonable place for the call to extensions duedate code to go. The major thing that stands out immediately is that it doesn't know the $USER.

In reply to James McLean

Re: UniSA's Assignment Extensions Module 1.9 -> 2.x

by Michael Hughes -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

I'd maybe make one observation about a call like 

extensions::update_duedate($cm->id, $user->id, $asmnt, 'timedue');

specifying the field by string (whilst providing an work around to the fact that different modules call this different things) probably isn't terribly great and opens some holes where typos in the field name by a developer could break other data!

If the due date field is bumped in to the course_modules table then it would then at least implement the data storage for EVERY module (whether they start observing it or not), which in my head makes more sense if this is aimed at address it at a core-level...

 I'm also slightly concerned that the a function named "update_duedate" that doesn't update the database is mis-named...given it's loading the due date into the assignment, I'd *prefer* something like "fetch_duedate" or even just "get_duedate". Reading it this way (if I wasn't paying attention) I'd be wondering why I'm trying to save the due date to the DB when I'm reading it...

(The DB code is similarly named "get_record*" to fetch *from* the DB and "update_record*" to write back to the DB)\

 

 

Oh and No I couldn't think of a reason...smile