-
Bug
-
Resolution: Fixed
-
Minor
-
3.11.10, 4.0, 4.0.4
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MDL-72490-master -
Some staff has set up incorrect date restrictions which lead to a file that can never be viewed, e.g.:
Image
In this case, nobody can view the file because there is no date which is both after 14 December and before 20 November.
We want to add a change to core Moodle specific to the date restrictions when you are editing restrictions. The system should not allow you to add a date restriction if there is any other date restriction that would conflict with it - in that case, an error should appear next to it and ideally you can't save it.
The screenshot below has an example where there are two Date restrictions, and the second one conflicts with the first (the first one allows access from 18 August 00:00, the second only allows access until that same time - the result is that there is no time when access is allowed).
I also added a 'Grade' restriction without setting it up, just so we can see how warnings (in this case 'Please set' appear).
Under this planned implementation, the second Date would show a similar warning text 'Conflicts with other date restrictions'.
Note this code has to run in the date restriction javascript by looking for earlier date restrictions on the page.
Specific logic:
If the combination logic is 'all of the following' (so that the text between each restriction is 'and', not 'or')...
Then if this date conflicts with one of the above dates within the same restriction group (see below)
Then show the warning message next to this date
'Conflicts' means that:
If this date A is 'until' (<), then if any previous date B is 'from' (>=) and if the selected date-time B is greater than or equal to A
If this date A is 'from' (>=), then if any previous date B is 'until' (<) and if the selected date-time B is less than or equal to A
It is possible to create a nested tree of restrictions. Because we are only checking the date restrictions within one restriction group (i.e. at the top level, or within a specific nested one) this means you will still be able to put extra effort in to create a conflict manually, for example if you create two restriction groups each of which has one date in. However, we are only really trying to catch the most common cases i.e. top level or within the same group.