Moodle

attaching two diff files - the first just changes the requires_date_before string. The positive one changes all of the require statements to positive statements rather than negative. Rather than telling them when it is not available, we can tell them when it is available. Also this string struck me as odd:

$string['requires_completion_3']='Not available unless the activity <strong>$a</strong> is complete and failed.';

Might this indicate to the student that they are to try and fail it? Not only complete it but because of the and they are also required to fail it. I understand the intent is to accept both completion and failures but it is strangely worded. I actually think it would be better if it said that it were available when the activity is either completed or failed.

Peace - Anthony

Helen - I've added Sam as a watcher of this since he is working on the conditional activity stuff. Peace - Anthony

Anthony, thanks for your report.

+1 from me for the improvements you suggest.

Sam, I hope you don't mind this issue being assigned to you for consideration.

Comments:

1) 'Not available after' is definitely not appropriate with the system as-is - it means something different.

'Not available from 20 March' means that if you look at it on 20 March you will not be able to see it. [This is how the system uses the dates.]

'Not available after 20 March' means that if you look at it on 20 March you will still be able to see it.

2) The missing space should be added by the system in code (the function mentioned) not in a language string - having spaces at the end of a language string is silly imo.

3) I agree that the positive wording is better, but I don't like 'beginning', so my favourite variation of the options above would be:

Activity conditionally restricted: 'Available from 17 March 2009. Available before 20 March 2009.'

4) Rather than just fiddling with language strings, should we alter the way dates are selected and behave? I could change it so that the form modifies the second date to be 23:59:59 on the day selected, ie the dates are both inclusive. Would this make it easier to understand?

The disadvantage of this is if you are trying to 'line up' activities ie have it so one appears when the next disappears. With the current system, you can do this by setting the 'end date' of one the same as the 'start date' of the next. With the change to 23:59:59, you would need to set the end date of one to one day before the start date of the next. Probably not the end of the world, just saying.

5) With changes to the logic, a single string could be used for two dates. For example...

(one date)
Available from 17 March 2009.

(one date)
Available up to 20 March 2009.

(both dates)
Available from 17 March 2009 to 20 March 2009.

6) Don't forget the case with the two dates is probably not going to be used all that often, so this hopefully isn't too important...

Sam - I understand what you are saying with #1. #2, I agree the space is best handled by the code. We will just have to check whether the string already has something in it to determine whether to add the separating space. #3, positive statements tend to be clearer for users. In looking at how dates are handled for the assignment module, they allow the teacher to set date and time and are inclusive so I think for consistency that is how conditional activities should be but you may want to double check this is correct so as long as we are consistent I will be happy. It is too early for me to wrap my head around the disadvantage you mention but once I'm awake I will come back and comment. Regarding #5, I liked the simplicity of the logic in listing each condition separately and now worrying about combining them. It made it clear how many conditions there were. I don't have strong feelings either wayl #6, I would be afraid to predict how users are going to use it. I suspect both dates will be used fairly frequently but we shall see. Thanks for your continued work on this. I liked what I saw and think this is a big step forward for Moodle. Conditional activities have been requested for a long time. Peace - Anthony

OK, done. I have made the following changes:

1. The dates are now inclusive. This is achieved by setting the 'until' date to 23:59:59 on the selected day (while the 'from' date is 0:00:00).

2. I have changed the display of the dates so that it correctly takes into account the user's timezone. If the user has a timezone which makes those dates have times OTHER than 0:00:00 and 23:59:59, then the full date and time will be shown. If the times are as expected, then only the dates will be shown. This supports correct behaviour when a server has users from multiple time zones.

3. I changed the strings as suggested, and added a new lang string to encompass the 'both dates' condition [I thought that was better, even though Anthony didn't]. This incidentally includes the space

4. This change incorporates a Moodle database update to adjust any existing 'available until' times by 1 second. Without this, any existing usage would shift its deadlines by 1 day if you edited a resource and then saved it again. [Presumably nobody has any real deployments using this... but just in case somebody somewhere was relying on it for a demo or something.]

Sam - I wonder if we are setting folks up for confusion. Looking at the course screenshot, you will see that the availability dates are for April (Available from April 15, 2009 to April 29 2009, 12:59 AM.') based off of the conditional data which sets a time specific time by default. I suspect it will not be long before someone request the ability to set not only the conditional date but also the time. In any case, when looking at the assignment it has a different set of available dates which are based on the assignment's available from due date (Available from: Saturday, December 27, 2008, 07:10 AM). Do we need both? Is there a distinction between them? If so, how do we articulate that? Peace - Anthony

Sam - I've checked the new wording and it looks good to me. I'm going to go ahead and close this issue. The question about available from can be worked out in another issue. Let me know if you want me to create it. Peace - Anthony

Anthony - The default dates (if you edit and save the activity) should not include times provided that you are in the same timezone as the server. If they do, even after editing and saving, then this is probably a bug (looks like a DST issue of some sort). Presuming the test server is correctly configuired timewise, could you file a separate issue about this?

I agree people might want the ability to set things to particular times. We can give them that if they like. The problem they would experience then, however, is it won't be possible to set something valid for exactly a day. You can choose 0:00 to 23:55 in 5 minute increments, but you can't choose to 23:59:59 the way this system works. In other words if we used the time selector, we would basically have to revert to people specifying it using the next day at 0:00 (making it look non-inclusive again). That's not very nice. I suppose it might be possible to extend the time selector to allow a special 'end of day' option but off the top of my head I don't see a good way to do that...

As for confusion with assignment dates, this may be an issue. Obviously as this is a general system it currently applies to all modules, which means that for the few modules which have their own dates, it might be inappropriate. There are two possible solutions to that:

1) Provide a way to disable (hide) the condition dates for certain module types. [But, the module dates don't do everything that' the condition dates can...]

2) If custom dates don't do anything that the condition dates wouldn't, then remove the module's dates in favour of the condition dates.

If it turns out that both dates do different things and are useful (ie you wouldn't want to use condition dates to close assignment because it makes it impossible for users to look at their assignment later - but then again, you might possibly want some way to make it completely hide assignments) then perhaps we should figure out some better way to distinguish between the dates. One possibility might be to make the whole condition section into 'advanced' so that it's hidden by default, not sure if that works.

Sam - I am not going to worry about the display containing the time. I do not think that is a bug. I probably do have times configured differently (in other words the user I was using was not using the system timezone). I do this because of my work with MRBS in which there is a lot of timezone stuff. If it does prove to be a bug, I'm sure it will be discovered and reported. Similarly with the ability to specify times. I would not recommend hiding the conditional - if anything I would encourage the module to get rid of their dates. So +1 for option #2. So I would say at this point, it is an issue for each module to check how it is using conditional dates and make sure that it makes sense. Might we add "Review core modules for ambiguities regarding conditional dates" or something along those lines as a subtask to the work on conditional dates? Peace - Anthony

For info: I just checked in an extra change to this bug number because I had forgotten to alter the validation code. It did not let you set the 'from' and 'to' dates the same date. This was correct behaviour when the second date was exclusive, but is not correct behaviour now that both dates are inclusive, as it means you can't have something available just for one day.

Sam - I suspect not being able to have something available for one day will only reinforce the eventual need for this to be time based rather than date based. Peace - Anthony