General plugins

 
 
Picture of James McLean
UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Hi Folks,

At the University of South Australia we have a very large Moodle instance, this year we've had over 40,000 individual students login and access the system (UniSA and OUA students) and over 2500 courses created and used. Our Extensions module has had over 200,000 requests! I myself have been working with Moodle since 2009 here at UniSA and as such we've made a lot of interesting improvements and enhancements to our Moodle instance. For various reasons, the code for these is stuck in 1.9 Moodle-land and as such we have a lot of work to do to bring these changes into 2.x. 

At MoodleMoot 2012 we met a lot of people from the Tertiary sector that were as passionate as we are about moving Moodle forward, especially for our sector. We were excited to hear the new Assign module would have extensions, however it doesn't implement as much functionality as we have now. To resolve this, we're planning that starting in the next couple of weeks and continuing into the new year we will port our existing Extensions module to Moodle 2.4 and, once it's close to stable, release it to the community.

It should be said that the Extensions module was intentionally specced and written to suit UniSA, and what our Academics were asking for. For our development efforts in porting the module this does need to be our primary focus, but given that we're intending to release this to the community we are certainly willing to hear suggestions from the community. We'll do our best to implement suggestions that will improve the process, but there will likely be items we can't do due to time constraints. I'm sure you'll understand, but of course that's where the community comes in, and the open nature of the module will mean that anyone is free to modify the code to suit them and contribute it back (or not!)

Our current implementation isn't perfect. On the surface it works well, but under the skin there is a lot of work to do to port it following the full Moodle standards, with a view to having the code extensively used out in the community (particularly the Higher Ed sector).

Now, to whet your appetite, what we have now is as follows. As they say, a picture is worth 1000 words, so I'll include some screenshots of what functionality we have currently. As an aside, our Extensions module also integrates with Quiz (1.9, slight hack there!). Bear with me while these screenshots step back in time to 1.9!

Firstly, creating an Assignment goes through a Wizard (this will also be ported to 2.4 at a later date) we have a page which allows the creator to enable or disable extension requests by students, and of the course staff, who can approve these requests. Some details have been obscured for privacy.

The academic will then proceed through the remainder of the Wizard, and the assessment item or Quiz is then created. The final page of the Wizard is the 'Standard' Moodle activity add screen, they will set the remainder of the details (such as due date) just as they would in any other Moodle instance. Here we have tight integration with other UniSA systems, so due dates, summative/formative status come from an up-stream system. That's a whole other ballgame I won't go into here smile

The real benefits we feel are in the Student side. In our system Students can view a list of all assessment items, and for any quiz or Assignment where the extensions are permitted they may request an extension via Moodle, rather than having to contact the course staff off-line or via email. The staff member is then free to approve or deny the request or ask for further information, via a selectable status. Once it's been approved, this can then be withdrawn by the student if they choose to, or the staff member can revoke the extension should they need to.

Now, onto the process of requesting an extension.

Firstly, they select the Extensions link in our Course Essentials block:

This block is specific to UniSA - for the community release of Extensions it will be written to support the standard Moodle menu functions. This block may be released to the community, but again it's quite specific to our environment so may be of limited use to other organisations. 

When the student accesses the Extensions link, they're presented with a list of their current extensions, and they have the ability to request a new extension. We're using full Moodle Forms functionality for all screens, it should be mentioned, so a lot of these pages will port to 2.x really easily. Again I've obscured personal details for obvious reasons.

Now, this student is free to request another extension, as their extended due date has not yet passed. Our business rules allow students to request a new extension until the due date has been met, whether that's the actual assignment due date, an extension or even a global (group level) extension (to be discussed below). My intention is to make that functionality modifiable by the institution using the module; as that may not suit everyone.

In this case, I'll show requesting an extension for Assignment 2, Report Internals:

As you can see, there is clearly an area where a student can tell the academic that the dog ate their homework, and we've got the provision to upload supporting documentation to go along with the request (sick certificates or whatever the case may be). Finally, they may select a date in the future (ours defaults to a short date, again this would be another configurable parameter). Finally, they select a staff member from the drop down. These staff members are as selected in the Wizard; however again this will need to be configurable in the community version of this module so that it works standalone.

Unfortunately, I did not have a screenshot of the 'pending' request, however it looks like the previous student request simply with 'Approved' reading 'Pending'.

On the Assignment page, we can see the student can clearly view this information. Automatic Extension refers to a 'Global' or Class level extension, to be discussed below.

Now, onto the Staff side.

The module is written such that it detects if the user viewing the module is Staff or Student, and presents the relevant view to the user at the time. Staff have the ability to 'Quick Approve' should they choose to, by simply selecting a checkbox on the items they wish to approve, and then pressing the relevant button.

This screen also give the ability for a staffmember to grant an extension for a student in their class, which allows for cases where a student may not be physically able to request one, such as hospital illness or other reasons.

Please excuse the screenshots, I needed to split them in two due to the way I was capturing them, but please be assured they are all on the one page, and everything does line up smile Everything does look better in the real module, I needed to squash the browser down for capture. Again i've obscured personal details.

Now, should the staff member select the Status (it will generally show a string representing it's current status) they will have the ability to view and modify the extension itself. In this window we will see details of the student who requested the extension, their message (I blanked it out in this case as it was personal). We can also see there were no documents supplied, but should they be supplied they will present as a URL and will open in the relevant application (PDF Reader, Word etc).

So, that's the bulk of the Individual Extension Requests stuff. This side of it is quite straight forward, and I don't expect any issues with getting this part to work. I have a number of ideas on how to get this working with the Assign module (the new 2.3 one); I was hopeful the Extensions implemented in the new module would use one of the Submission plugins (the architechture of that is really nice under the skin, fwiw) however what has been implemented is deeply built into the system and in my 2hr look at the code doesn't appear to be 'pluginable'.

Thoughts are that we could modify Assign to work with a submission plugin for the assignment dates, or this module could simply write to the new column in the table and save the date there - but that would be frought with danger no doubt. We really want to avoid custom local hacks wherever possible, as we want this code to work for as many people as possible.

We also need this to work for Quiz, as we currently have that functionality. I haven't done extensive investigation on how to implement that side of it yet, either, but like the above it's a problem that doesn't need immediate resolution; but we'll need to think about it soon.

I'll gloss over Global extensions, it works a little like the above, except for the fact that students cannot request it (at least via Moodle). It's useful for instances where for example, an class may have public holiday on a Monday and they miss a lecture, but another class gets their lecture on a Tuesday. Of course it would also be useful for lecturer illness, etc.

As we can see here, we have seperate assignments for Internal and External students, and this academic has been nice enough to grant an extension until December 17th. The Grouping listed is just the Grouping assigned to the Assignment, not actually who it's applied to.

On the Edit screen, it's quite self explanatory. We see the original due date, and the new date selected. The staff member also has the ability to add a message to explain why the extension has been granted.
Finally, we have a new moodle form item we've created called the Select Picker. It will show Available Items in the Right hand side, and Selected items on the left. It works as you'd expect - double click will move the item from one side to the other, as will selecting and then clicking a button to move it. It works with all the standard Moodle error 'stuff', for example you can validate the input in the normal way, and it will present the error. It's essentially a custom group item.

So, that's the bulk of it. We'll have our work cut out for us, but for developers like myself this is the kind of thing we love smile We're really interested to get community feedback on this, so any suggestions can be considered for inclusion in the beginning.

Ultimately we would like to see this code make it into Core and for it to be maintained by the community - a lofty goal. But, lets not put the cart before the horse, we've got a lot of work to do between now and then smile

I'm going to start porting our code inside the next week, but then I'll be on leave for a few weeks in late December for Christmas, and then in the new year I'm back on deck and will be working on this (and other aspects of our M2 implementation) full time again. I'll keep tabs on this thread over the Christmas break, but I won't be doing much development on this during that time.

We're excited to get some feedback on this, positive and negative, and we're excited to to get this up and running!


 
Average of ratings:Useful (1)
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

I'm surprised there hasn't been any responses to this as yet. Did I post in the wrong forum? We're of the opinion this is an exciting addition and something that a lot of people will get benefit out of.

I've begin the implementation of this in my local Moodle2 development environment; I've got a few ideas already on improvements that can be made such as a 'global view' for Course Staff, so if they visit the Extensions page from the main menu without being in a specific course it will show a list of all extensions in all courses they are a part of, with the standard list of functionality as described above.

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

I've been able to spend quite a few hours on this over the past few days, and it's coming along nicely. I've implemented a number of capabilities that cover requesting, modifying, deleting, withdrawing and of course approving extensions, and I've also come up with a much nicer and simpler way of storing the data in the database than what we had in the 1.9 version.

I have also been making everything configurable, such as the ability to have individual extensions enabled, and global disabled (and vice versa), a global level 'cut off date' for extension requests (to allow for selection in the case of a Uni level policy, should it exist) plus there will be a seperate configuration setting for this at an activity level should an academic like to make a selection.

I've just touched the tip of the iceberg with what needs to be done, but I'm enjoying it and super keen to have something to show here (even if it's just one or two pages!) before I go on leave in a week and a half smile

If anyone has any comments or suggestions, fire away, I'd love to hear any feedback on this.

 

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Made some good progress today:

Doesn't look like too much, but the progress is signifigant. Dummy data used above, and clearly the table content isn't finished yet. But, I'm impressed with how easy porting this code to Moodle 2 has been so far.

More to come as it's developed.

 

 
Average of ratings: -
Picture of Rob Woof
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Hi James,

This looks like a very useful plugin. I will await developments with interest. I manage the Moodles for the Registrar's Dept at Moore College in Sydney (http://moore.edu.au/), and late submissions are the bane of our existence. Having the ability to manage individual extensions is a very cool possibility. It looks like you have everything covered conceptually, so I don't have any ideas to add. However I will put my hand up as a possible tester - we're currently moving from Moodle 2.2 to 2.3, and I'm looking forward to 2.4 - one of our requirements is blind marking, and we have a custom assignment (2.2) type for that, but it's built into 2.4.

Cheers,
Rob

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Thanks Rob. We're honestly still a couple of months away from having a version that will be ready for external testing, but we're looking forward to getting it out there as soon as we can.

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Some minor progress has been made, I needed to build a page to allow extensions to be enabled for individual activities (per cmid), so that's what i've started on.

 

The intention is to add some buttons below the form, to allow a 'quick enable' mode to be used, which will use the defaults (for approvers specifically). If they want to drill down a bit more and only allow certain people to approve the extensions they'll need to use the Edit link and subsequent page to setup that information.

The table above is a custom MoodleForm object, so making the form actions work from here should be a walk in the park. Might need a minor tweak or two, but should be good to go from here.

Intention for the empty columns on the right will be some quick stats on the extensions in the system.

Staff view of requests is taking shape, too:

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

I'm back at work now, after a few much needed weeks off, so I'll be working on this again some time this week.

I'll post with my progress again later in the week.

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

The Staff page for viewing requests is more or less done:

 

I've made some good progress with the editing of student requests, and also the tracking and display of extension modification history:

This is the history display below, but I needed to split the screenshots so they'd fit here better.

The History display will be configurable, so that it Admins can restrict it's visibility to certain roles, or to allow academics to view it. Ive also added some other niceties like the Pending Count on the Individual Extensions link above, configurable too, which allows easy viewing of when an extension is waiting.

I've spent some time working with the menus also, but there's not much to see as yet, mainly just getting familiar with how to modify and work with those in Moodle2 without making custom changes. So far so good, just nothing worth seeing as yet.

I have a plan on how to integrate this with core Moodle code, so that other modules can check for extensions. It will require extending some current Core Moodle functionality, but I'll have to discuss with some core team members for the best way forward.

Progressing well.

 
Average of ratings: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group Developers

Just been looking at this since the MDL-7315 tracker item mentioned it.

We're a similar sized institution in the UK, and one of the things that we've also been wrestling with is the management of extensions, and we're currently going through a (reasonably) major project that is looking at the assignment management process of which extensions is a significant aspect.

I was wondering if you'd consider letting us evaulate this and give some feedback on it from a slightly different perspective? 

We've been developing quite a lot of custom components for Moodle for our institution so we may be able to help with the community version...

 
Average of ratings: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group Developers

I've got a few questions about the (technical) approach that you've gone for as we've been kicking some ideas about.

The current mod_assign has extension handling stuff in it, and we were thinking that the one approach

(1) would be to move the "due-ness" data out of mod_assign into the parent class, and then introduce a new "supports" option that would allow each mod to report whether or not it supports the notion of deadlines.

or

(2) the due date be storedup to the course_modules table, so that a module that supports deadlines would write the "default" due date to the cm (much like visibility etc).

The Extension manager would be a plugin type that maintains it's own database tables to track the requesting and granting of extension, but the actual due date of any granted extension tracking would be done via a core table:
cmid, userid, duedate

Core moodle would provide an interface that only sets and evaluates the dueness of an activity:

1) set_due_date($cm, $user, $newduedate, $extmanager); - records a due date for a user against an activity
2) get_due_date($cm, $user); which would take into account the $cm->duedate value (default value for the activity's submission) and any extension granted
3) get_extension_info($cm, $user); - Returns about the extension

This would mean that the majority of the logic for granting and managing extension is the the Extension Manager plugin, and so could allow multiple extension managers to allow different rules, so you could have an "Individual" Extension Manager and "Group" Extension Manager, a "Cohort Extension Manager" or a "Automatically grant users with recorded special needs" Extension Manager

A few other thoughts/questions:
* Would it make sense that the Extension history is actually written to the Moodle log? Either "in addition" or "instead of" this would mean extensions can be viewed throught the existing logging mechanism, but I'm aware that there would be tradeoffs for either approach.
* It looks from the screenshots that the Extensions Requests is sitting in the "Site Administration". Is this just a quirk, as it would strike me that it would really be a course-level tool?
* Have you given any thought to the impact of this with respect to Blind Marking? As granting an extension to someone may provide enough information to break the 'blindness'.

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group 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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group Developers

Oooh..looking forward to seeing this!

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group 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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of Michael Hughes
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group 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
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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

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: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 
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: -
Picture of Nadav Kavalerchik
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

Beautiful work! I am looking forward to use it (on Moodle 2+)

 
Average of ratings: -
Picture of James McLean
Re: UniSA's Assignment Extensions Module 1.9 -> 2.x
 

Thanks!

 
Average of ratings: -