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: 18

Hi Michael,

I think each module that supports a due date/submitby (whatever each module calls it) should be left as it is; it's working well now and for the most part can be left as it is (as inconsistant as the field naming is) - unless there is a specific need to resolve those issues.

I have asked Tim for suggestions on the best way to implement this in the Core, and he's given me some good suggestions. It's also raised another question in my mind as well; as what's in Quiz now aparently allows for extra time on a quiz timelimit, whereas what we're proposing (and already using in our Moodle 1.9 installation in Production in Quiz) will simply extend the close date a student has to attempt the quiz in. Modifying the timelimit on a student by student (or even group/grouping) basis clearly adds another level of complexity, and while I do see this as being vitally important in the future, we won't be able to include this functionality in the short term in our module. Thankfully the Quiz module does implement it already, so for now that will need to be a work around. Once the code for this is released we're happy for someone in the Community to implement this.

Excusing Quiz module specifics (which will need to be considered at some level from day 1) I think it's best to proceed as I mentioned above. As a simplistic overview each module would then check with Core for 'extensions' and if there is an extension to the due date found for a specific CMID & User that module would then adjust it's due date to suit for that users session only.

The way I see it being implemented is something like:
In core would be an Extensions class (lib/extensionslib.php ?), comprising all the logic which modules will call to check for extensions. After a module has queried it's own tables for the details of the activity, it would call $asmnt = extensions::update_duedate($cm->id, $user->id, $asmnt, 'timedue'); passing in the cm->id, user->id, $asmnt (represents the details of the activity itself) and the field which contains the due date that extensions needs to update. Of course that could also be managed inside the method with a switch, but I can see that being a bit of a mess (though maybe somewhat more reliable?). This is based on looking at the function quiz_update_effective_access() with some changes on how it may be implemented in a way that can suit all modules.

Gradebook will also need to be able to call this method to determine if there was an extension for a specific activity but I don't see that being a major issue.

The method described above would determine wheather a user has an individual extension for the activity, or if they have been granted a global extension (course wide, group or grouping based?). I really like your suggestion of automatically granting extensions for specific students as requested, even though that might have to come in a future version it's absolutely possible, and I think we would also get some value from it at our Uni also.

Most of my thoughts of implementation above are simply on the fly thoughts, so I'm open to suggestions and improvements.

The module we are developing above does already have it's own tables to store requests for extensions, with the status of these present also. 

You do raise a valid point regarding the history of each extension; we're also logging to core Moodle logs, so they can certainly be viewed through existing logging systems, but I think an easy to view table of extension history adds some useful information for staff who are approving/reviewing the extension.

The breadcrumb saying 'Site Administration' is purely an artefact of where the menu is located at the moment - I simply needed a quick and easy place to access the menu while I'm developing it. It's actually being designed so that a staff member can have a 'global' view of all their pending requests in all courses so this menu item may remain in the future, but of course it is most valuable at Course level and is being developed to work that way primarily.

Blind marking has not been considered at this point; but thanks for raising it - we will certainly need to give it some consideration. Depending on how it works there may be a requirement to disallow extensions for blind marked assessments perhaps, but again it's up in the air and we're open to suggestions.

Average of ratings: -
In reply to James McLean

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

by James McLean -

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.

Average of ratings: -
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

Average of ratings: -
In reply to James McLean

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

by James McLean -

So, flying in the face of what I've previously said here, and based on the suggestions you made Michael, I've begun working on a 'deadlines' plugin module to centralise open/close/due/cutoff dates. Borrowing heavily from the Plaigirism implementation, I've started working on getting this side of things working against 2.5dev.

I am working in a local GIT branch, but I'm not able to push to github as yet, even via https, which is likely an issue on the local network. I'll create a service call (local help-desk term..) to get networks to allow my workstation SSH or GIT access to github, and then if others want to look at the code they can.

Not much to see yet, except the plugins page:

 

Even that doesn't do much of note yet, but glad I got that part done in an afternoon though.

Average of ratings: -
In reply to James McLean

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

by James McLean -

I have a modified version of mod_assign which is now reading all dates from the central 'deadlines' module, and using the *_supports() functionality.

Dates are hard-coded so far, but working on the database layer right now. Database tables are being installed on installation at the moment for both the deadlines and extensions modules.

Coming togeather quite quickly now!

Average of ratings: -
In reply to James McLean

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

by James McLean -

Modified version of mod_assign is now working with the Deadlines and Extensions plugin. Adding and Updating deadline (and open time, and cutoff) in the Deadline module itself; and also querying the Deadline plugin for deadlines for staff and students.

Queries the Deadline module which then checks it's own plugins for dates relevant to that student (generally due dates) and activity.

This architecture should prove handy as it will be trivial to develop more deadline plugins; such as to allow (for example) Special Needs students to be automatically granted an extension without them having to request it - which if memory serves was another one of Michael's fantastic suggestions smile It will work such that the actual Extensions plugin won't have to be installed for that part to work, or even the actual Deadlines plugin (which plugs into the Deadline module). 

I shouldn't get to far ahead of myself here. This is really not much more than proof of concept at the moment, as it's really had NO testing so far and I know I've probably forgotten something important.

Still, it's exciting smile

Average of ratings: -
In reply to James McLean

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

by James McLean -

Ok, so again it's been too long since my last post to report progress, but oh well that's how it goes when there's a lot of things that rely on me smile

Anyway, the Deadline/Deadlines/Extensions plugin has been progressing still. It's quite stable now with mod_assign (admittedly only my own limited testing so far) but working well. I've looked at implementing migration of the standard mod_assign deadlines etc into Deadlines on install; which shouldn't be too hard. Obviously there is a lot of considerations to be made here, plus of course other modules too. And, of course, existing Extensions in mod_assign and mod_quiz (and others later!) will need to be handled too. Perhaps a task for a little later on (or the community if anyone is interested - most of the hooks are there).

Anyway, I've spent some more time on getting Group extensions implemented, firstly in the UI and of course in the code too. 

Obviously there is a little to be implemented here yet (staff member to send to) but when a student requests an extension (link in mod_assign submission page for now; this will require community input on the best place for it) on an activity that is assigned to a group, if any of the members request an extension Extensions will see that and perform the request on the behalf of the group.

The Staff UI also sees this:

(squashed for screen snip).

Now, when any member of the group associated with the request (determined by looking up group members that the requesting user is a part of) they will all recieve the extended deadline (no screenshot available, implementation of this incomplete at the moment).

Global extensions builds on the group extensions functionality, and essentially allows multiple groups to recieve the same extension - however they cannot (at this moment) be requested by a student; as they'e designed to cater for public holidays, lecturer/academic illness etc and only to be applied by the lecturer/academic.

So, that is the Global Extension creation screen. The 'Apply Extension To' boxes all work OK with JS enabled; though this may be an accessability issue going forward. Further investigation needed to make these work without JS.

It's currently setup so that if an activity is assigned to a specific grouping, it makes sense to only show groups in the assigned grouping for selection - as extensions shouldn't ever apply to anyone outside the grouping anyway. Alternatively, if an assessment has no grouping assigned, all Groups in the course are available for selection:

All good!

Error handling is fairly seamless:

As you can see attempting to add a global extension to no groups fails; though, it could be argued that this would be valid - and applies to all students in the course regardless of their group. However, that's how the business rules I originally worked from were structured so that's how it is now. This could be configurable.

One major improvement in this 2.4 version over the previous 1.9 version is the ability for multiple global extensions on a single activity - thanks to the entirely new database structure the 2.4 version uses.

I openly and freely admit this is UI a kludgy hodge-podge, and only 1/2 implemented! I've discussed this screen with one of our BA's and he's going to come up with a better way of presenting this information as what's there now is essentially an 'evolution' of the previous version - but what it really needs is a revolution! Again also happy to hear community suggestions.

Some more work has happened on activity enable/modification.

Apologies for the length of that screenshot. I've included some of the mod_assign fields intentionally though to show that the extensions can be enabled/disabled from the edit screen. Deadlines stuff there is just to prove to me that it's happening in a 'dynamic' way, and deadline is checking it's own plugins to see if they have fields to add to the form when requested (deadlines & extensions).

That kind of pairs with the activity configuration page:

which clearly allows bulk enable/disable of extension requests allowed and cutoff dates. In addition to that, editing one of the items will allow more configuration, such as allowing specific users to have access to approving extensions:

This one is essentially complete, a little work required on displaying the selected users etc. 

Having two areas to enable/disable extensions on an activity is admittedly a bad way to do things. But, I'm a developer (yes that copout again) and sometimes I'm not great at coming up with UIs that people can use easily.

There's a lot of files:

My network issues regarding github access are 1/2 sorted, I have access via the git port - but because I haven't used git very much, I didn't know I also needed SSH access, so that port is still blocked. I'll work with our Network guys to get that resolved shortly, however I may be able to tarball what's here and email it if people want to have a closer look. Warning; it's 2.5dev, I'm working in a local branch, but I don't know how to rebase yet (I think that's what I need to do based on the reading i've done), so it's probably a month or so old. I do need to work that out...

Of note, I'm working on getting to MoodleMoot 2013 in Melbourne, hopefully to present these changes at the conference. I presented at the 2010 'moot and loved it, I'd love to do it again!

So, I don't think I really have much more to add at the moment, other than to say it's still progressing and I'm still here and haven't disappeared!

Average of ratings: -
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

This is all looking really quite nice, and I'm looking forward to being able to play with this.

It would also be nice to see if there is any comments/thoughts from Moodle HQ!(?). Even if just to give their thoughts about this, given the potential knock on effect.

Also things like the likelihood of this seeing integration into core....?

Average of ratings: -
In reply to Michael Hughes

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

by James McLean -

Thanks Michael.

Yes I'd love to hear what HQ have to say about these changes and possible Core integration. It's a fairly signifigant piece of work so there will need to be quite a lot of community testing before it does go forward for possible integration.

We're hoping to start our own internal UAT on it next week - but I still have some development to complete on it! (always the way..) smile

Remaining work (according to our requirements) is:
Student request page needs to be ported (should be fairly trivial)
Student submit request page is only partially ported from 1.9 (not saving extensions as yet)
Quiz module modification and integration
 - request screens to check for quiz and work with time limit extensions (hooks and structure present, UI work needed)
Some further work remains on checking and returning group/global extension dates correctly (should be trivial, again all the hooks are present)
Lots of UI tidy ups based on our BAs input and hopefully community suggestions down the track.
 - Integration with Course menus, suggestions on location for these links appreciated!
My Deadlines block needs to actually do something useful - just used as a temporary location for links to Extensions pages.
Documentation. 
Documentation.
More documentation! PHP doc is about 50% done for the main classes, what's there is fairly complete.

And, to make things more fun, I've been pulled off the code for this morning to work on a change to the 1.9 version (which we still have in production...) but that should be a trivial change.

Average of ratings: -
In reply to James McLean

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

by James McLean -

I've put some further time into the group extensions code, that all appears to work well enough now.

A bit more in the way of abstract methods in the base deadline library code to introduce some methods for getting open date, cutoff dates etc. They all return the saved date for the Deadlines plugin but Extensions returns 0 for those - and that is effectively ignored by the Deadline code.

I now have some code on Github; so I will be asking for feedback shortly.

Average of ratings: -
In reply to James McLean

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

by James McLean -

We're going to be going into own own UAT with the deadline/extensions code this week. I've been updating the git repository with further changes and features as I've been working on things.

I have sent the details to a few people in the community with no response as yet, but if anyone is interested in having a look at the code base please send me a message here and I'll forward the link. Just want to get some feedback on the architechture and the code prior to releasing it to everyone.

Average of ratings: -
In reply to James McLean

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

by James McLean -

I've polished up the code a bit, fixed a few more bugs and sent it off for our internal UAT.

I've been given approval to submit an abstract to AU MoodleMoot 2013, and I'm working on that now - so I will hopefully see everyone there!

Average of ratings: -
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

James,

I've started to have a play with it and I think it looks really good. 

Found a few bugs:

1) on deadline/extensions/?page=request_edit&eid=1 (I accessed this by clicking on the Approved link item in the status column on the /deadline/extensions page 

Strict Standards: Declaration of form_staff_request_edit::set_readonly() should be compatible with that of form_base::set_readonly() in C:\Users\Public\moodledevroot\moodle_head\deadline\extensions\forms\form_staff_request_edit.php on line 29

2) on the same page: Coding error detected, it must be fixed by a programmer: PHP catchable fatal error

More information about this error

Debug info: Argument 2 passed to moodle_database::record_exists() must be an array, none given, called in [dirroot]\deadline\extensions\lib.php on line 799 and defined 
Error code: codingerror
Stack trace:
  • line 406 of \lib\setuplib.php: coding_exception thrown
  • line 1660 of \lib\dml\moodle_database.php: call to default_error_handler()
  • line 799 of \deadline\extensions\lib.php: call to moodle_database->record_exists()
  • line 251 of \deadline\extensions\forms\form_staff_request_edit.php: call to extensions_plugin::is_extension_approver()
  • line 915 of \lib\formslib.php: call to form_staff_request_edit->definition_after_data()
  • line 396 of \deadline\extensions\extension_base.php: call to moodleform->display()
  • line 96 of \deadline\extensions\index.php: call to extension_base->display()

A few other thoughts:

1) We tend to use a student registration number as a student identifier, which we store as a custom profile field...it might be nice if the request list could be customisable to display a user profile field (the idnumber column is used by some people for this data as well). This tends be slightly more useful than username. 

2) Sorting of extension request table would be helpful.

I'll keep playing with it, but like I said looks good to me.

Average of ratings: -
In reply to Michael Hughes

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

by James McLean -

Sorry Michael, I missed notification of a reply to this thread.

Looks like you've grabbed a copy when it was in a bit of a state of flux; That issue should be well and truly resolved now smile

I like your suggestions about having the column types sortable and configurable, i'll see if I can make the change.

Also, my abstract submission to present at MoodleMoot AU was denied sad So, I guess I won't be going now.

Average of ratings: -
In reply to James McLean

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

by James McLean -

I've merged 2.6dev into my branch, but haven't done a lot of testing with it yet. I had to re-add some changes to the add and update functions as they've changed a lot in a recent version. 

Worked OK with a quick test, but there may be remaining issues (in fact I'd be surprised if there wasn't)

Average of ratings: -
In reply to James McLean

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

by James McLean -

I've been pushing changes and bugfixes up to my Github branch, it's all quite stable now as far as I can tell. UAT is finally about to happen, and we have a software tester who will be testing the entire process end to end, and I'm sure he'll find a couple of issues that will need resolving.

Average of ratings: -
In reply to James McLean

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

by James McLean -
Well, that was embarrassing!

When I posted my last post I didn't intend to effectively abandon the public version of this, but the past 12 months or so have been crazy at work which is obviously the priority. I was at MoodleMoot AU 2014 just a week ago and I'm excited to get the public version moving again after talking to a lot of passionate Moodle people, particularly in the Higher Ed sector here in Australia.

In the past 12 months though lots of bugs and issues have been fixed, but a few implementation issues remain at this point. Having said that i've got the basics of the system working against 2.8dev now, and I am about to get onto resolving some of the implementation issues i'm not entirely happy about.

What remains here before I would be comfortable announcing this more publically is to take better advantage of the events system when activities are added. There will have to be changes around the place to get this to work.

More details to come.
Average of ratings: -
In reply to James McLean

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

by Garry Edmonds -

Hi James,

We have had an enquiry at our university for a better method of handing assignment extensions and we were referred to this page. Your plugin looks very interesting. Where you able to offer a public version of your plugin?

Average of ratings: -