Need UI for granting project extensions

Bug #587747 reported by Matt Giuca
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
IVLE
Triaged
High
Matt Giuca

Bug Description

There is currently no way for a lecturer to grant a student an individual project extension. We need some UI for this.

See also bug #492544 (respect project extensions).

Tags: submit

Related branches

Revision history for this message
Matt Giuca (mgiuca) wrote :

Also see comment #1 on bug #492549 -- regarding the implementation of the extension granting mechanism.

Matt Giuca (mgiuca)
tags: added: submit
Revision history for this message
Matt Giuca (mgiuca) wrote :

I've been thinking. Current data structure for extensions is to store a 'timestamp' of when the new deadline is due. I've got a bit of a problem with that, which is the following use case:

   1. Lecturer grants student Jim 2 day extension.
   2. Lecturer grants entire subject a 3 day extension (by modifying the project's actual deadline).

Now the question is, should Jim be required to submit 2 days after the original deadline, 3, or 5? (In other words, does modifying the project deadline update any existing extensions). There are three possible answers here:

a) Jim keeps his original deadline (almost certainly undesirable, as he was obviously given special consideration and is now at a disadvantage compared to everyone else)
b) Jim's deadline is now the same as everyone else's (possible, but unlikely; it's possible that the lecturer gave numerous students an extension and then decided to give everyone in the subject a blanket extension to catch up, and didn't intend to further extend Jim's deadline).
c) Jim's deadline was pushed back a further 3 days (most likely; the project has been extended but Jim still has additional special circumstances).

I am thinking of this as a data structure issue, because if extension has a 'deadline' field, then the answer is (a) (anyone who has been granted an extension will not have their deadline changed if the project deadline changes). This can be made into situation (b) by making the rule for honouring extensions "the later of the project deadline and extension deadline", so effectively changing the deadline past any student's given extension deadline deletes the extension (but the extension object still exists). But this still doesn't give us the most likely desired outcome (c).

I might like to change the data structure so that extension doesn't have a deadline field, but a 'duration' field which is either a time duration (days,hours,mins,secs) or just an int in days (as I can't think of why you would grant an extension which is not a whole number of days). Then you automatically get situation (c).

Is this good? Will changing it break anything? I don't think that table has ever been used.

Another possibility is we keep the "deadline" field, but when changing the deadline of a project, we iterate through all ProjectExtensions for that project and update all the deadlines accordingly. That's probably more work than changing the data structure. In that case, we could offer the lecturer a checkbox which says "Update all extensions by the same amount." which is checked by default, allowing the choice of (b) or (c).

I vote we change the data structure.

Revision history for this message
Matt Giuca (mgiuca) wrote :

The necessary migration is:
BEGIN;
ALTER TABLE project_extension DROP deadline;
ALTER TABLE project_extension ADD days INT NOT NULL;
COMMIT;

I vote for the number of days as an int. As I said above, I can't imagine why you'd want a non-whole-number of days for an individual student extension. It doesn't justify all the date math.

Revision history for this message
William Grant (wgrant) wrote : Re: [Bug 587747] Re: Need UI for granting project extensions

On Thu, 2010-07-22 at 03:55 +0000, Matt Giuca wrote:
> The necessary migration is:
> BEGIN;
> ALTER TABLE project_extension DROP deadline;
> ALTER TABLE project_extension ADD days INT NOT NULL;
> COMMIT;
>
> I vote for the number of days as an int. As I said above, I can't
> imagine why you'd want a non-whole-number of days for an individual
> student extension. It doesn't justify all the date math.

+1.

That table has never been used, so there's no data migration issue.

Revision history for this message
David Coles (dcoles) wrote :

I think it's an interesting corner case but inclined to agree that an "x day extension" is best modeled by an INT number of days after the official deadline. It makes things "just work" in a sane fashion (and if staff want to deviate it's no more work than the old DATE deadline would have been).

And whilst it would be nice to be able to grant users an hour extension (say a lecture clash), extensions should be exceptional. Thus less than 24 hours doesn't really seem worth the bother (unless the project was ridiculously short).

Matt Giuca (mgiuca)
Changed in ivle:
milestone: 1.0.2 → 1.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.