Moodle
  1. Moodle
  2. MDL-27242

Restrict Access by time as well as day

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Activity completion
    • Labels:
      None
    • Testing Instructions:
      Hide

      You must have enabled availability support at system level for all tests.

      Some background: This change does not affect the logic about whether users are permitted to access/see activities, which was always based on time values in seconds. The change only affects how the settings are edited and displayed. That's why this test does not include 'can the user access...' type steps.

      Test upgrade step:

      1. Before running the system upgrade, ensure that you have some activities with an 'available until' date set, for example to 14 October. (Which means they will be available until 14 October at 23:59:59.)
      2. Run the system upgrade and go back to the course

      • Verify that that the activity still displays as available until 14 October.
        3. Edit the activity.
      • Verify that the 'until' date now shows as 15 October 00:00

      Editing change

      4. Add a new activity (any kind) on the course.

      • Verify that the available from/until dates are both disabled.
      • Verify that the value for these dates is 0:00 on current day. (This allows users to more easily take advantage of the 'shorthand' date-only display.)

      Test display change

      5. Add a number of activities with the following from/to dates and verify that the text is the same as given here. I have written them in the format [from date] to [to date] = [expected text]. The result may vary in specific details based on your time format - this is the spectacularly horrible format that, I think, is Moodle default. (01:05 PM? Really? I think you mean 1.05 pm, if you must insist in not using 24-hour clock... anyhow, separate issue.)

      a. 14 Oct 13:05 to 17 Oct 12:10 = Available from 14 October 2011, 01:05 PM to 17 October 2011, 12:10 PM.
      b. 14 Oct 0:00 to 17 Oct 12:10 = Available from 14 October 2011 to 17 October 2011, 12:10 PM.
      c.14 Oct 13:05 to 18 Oct 0:00 = Available from 14 October 2011, 01:05 PM to 17 October 2011.'
      d. 14 Oct 0:00 to 18 Oct 0:00 = Available from 14 October 2011 to 17 October 2011.
      e. 14 Oct 0:00 to 15 Oct 0:00 = Available on 14 October 2011.
      f. 14 Oct 13:05 to 15 Oct 0:00 = Available from 14 October 2011, 01:05 PM to 15 October 2011, 12:00 AM.
      g. 14 Oct 0:00 to 14 Oct 12:05 = Available from 14 October 2011, 12:00 AM to 14 October 2011, 12:05 PM.
      h. 14 Oct 13:05 to [disabled] = Available from 14 October 2011, 01:05 PM.
      i. 14 Oct 0:00 to [disabled] = Available from 14 October 2011.
      j. [disabled] to 14 Oct 13:05 = Available until 14 October 2011, 01:05 PM.
      k [disabled] to 15 Oct 0:00 = Available until 14 October 2011.

      (yes I did this during development - I found it quickest to add labels.)

      Show
      You must have enabled availability support at system level for all tests. Some background: This change does not affect the logic about whether users are permitted to access/see activities, which was always based on time values in seconds. The change only affects how the settings are edited and displayed. That's why this test does not include 'can the user access...' type steps. Test upgrade step: 1. Before running the system upgrade, ensure that you have some activities with an 'available until' date set, for example to 14 October. (Which means they will be available until 14 October at 23:59:59.) 2. Run the system upgrade and go back to the course Verify that that the activity still displays as available until 14 October. 3. Edit the activity. Verify that the 'until' date now shows as 15 October 00:00 Editing change 4. Add a new activity (any kind) on the course. Verify that the available from/until dates are both disabled. Verify that the value for these dates is 0:00 on current day. (This allows users to more easily take advantage of the 'shorthand' date-only display.) Test display change 5. Add a number of activities with the following from/to dates and verify that the text is the same as given here. I have written them in the format [from date] to [to date] = [expected text] . The result may vary in specific details based on your time format - this is the spectacularly horrible format that, I think, is Moodle default. (01:05 PM? Really? I think you mean 1.05 pm, if you must insist in not using 24-hour clock... anyhow, separate issue.) a. 14 Oct 13:05 to 17 Oct 12:10 = Available from 14 October 2011, 01:05 PM to 17 October 2011, 12:10 PM. b. 14 Oct 0:00 to 17 Oct 12:10 = Available from 14 October 2011 to 17 October 2011, 12:10 PM. c.14 Oct 13:05 to 18 Oct 0:00 = Available from 14 October 2011, 01:05 PM to 17 October 2011.' d. 14 Oct 0:00 to 18 Oct 0:00 = Available from 14 October 2011 to 17 October 2011. e. 14 Oct 0:00 to 15 Oct 0:00 = Available on 14 October 2011. f. 14 Oct 13:05 to 15 Oct 0:00 = Available from 14 October 2011, 01:05 PM to 15 October 2011, 12:00 AM. g. 14 Oct 0:00 to 14 Oct 12:05 = Available from 14 October 2011, 12:00 AM to 14 October 2011, 12:05 PM. h. 14 Oct 13:05 to [disabled] = Available from 14 October 2011, 01:05 PM. i. 14 Oct 0:00 to [disabled] = Available from 14 October 2011. j. [disabled] to 14 Oct 13:05 = Available until 14 October 2011, 01:05 PM. k [disabled] to 15 Oct 0:00 = Available until 14 October 2011. (yes I did this during development - I found it quickest to add labels.)
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE
    • Pull Master Branch:
      MDL-27242-master
    • Rank:
      16922

      Description

      Several users have requested that the Restrict Access allow both a day and a time to be specified, rather than just a day, for both Allow Access From and Allow Access Until, for all resources and activities.

        Issue Links

          Activity

          Hide
          Sam Marshall added a comment -

          Yes this would be nice. As a proviso, I would add that the system must remain capable of displaying only the date and not the full time, for users that prefer not to use time.

          For example it currently says something like, 'Not available until 22 July 2011' - it must remain able to do this rather than saying 'Not available until 00:00 on 22 July 2010' or something.

          Probably this could be achieved by detecting midnight (or 23:59 or whatever it uses for 'until' dates) and not displaying the time in that case.

          I don't have any development time to implement this but am willing to review patches from contributors and submit PULL request to get it included in core once there is a correct patch.

          Show
          Sam Marshall added a comment - Yes this would be nice. As a proviso, I would add that the system must remain capable of displaying only the date and not the full time, for users that prefer not to use time. For example it currently says something like, 'Not available until 22 July 2011' - it must remain able to do this rather than saying 'Not available until 00:00 on 22 July 2010' or something. Probably this could be achieved by detecting midnight (or 23:59 or whatever it uses for 'until' dates) and not displaying the time in that case. I don't have any development time to implement this but am willing to review patches from contributors and submit PULL request to get it included in core once there is a correct patch.
          Hide
          Charles Fulton added a comment -

          Here's a patch against 2.1 which does away with the entire 23:59 business: https://github.com/mackensen/moodle/compare/master...mdl-27242. Times are still suppressed at midnight.

          Show
          Charles Fulton added a comment - Here's a patch against 2.1 which does away with the entire 23:59 business: https://github.com/mackensen/moodle/compare/master...mdl-27242 . Times are still suppressed at midnight.
          Hide
          Sam Marshall added a comment -

          Charles, this is good code. Thanks! From my point of view there are two problems with it, one complicated one and one simple.

          COMPLICATED PROBLEM

          Start time is fine, but supposing you set the 'end time' to, say, 13 July 00:00. Unless I am missing something, your code will show 'available until 13 July'.

          Unfortunately as I understand it, in this case it should actually show 'available until 12 July'. Or to be more explicit, 'available until end 12 July'.

          I had a discussion about this with our assessment people way back (b/c this feature is sometimes used for assessed material of some kind). We standardised on doing it that way because if you do it the other way you get complaints; even if only a small proportion of people read 'available until 13 July' as meaning that they could do it on the afternoon of that day, those are the small proportion of people who are going to complain and challenge their grades and generally be a pain. Doing it the other way around is much safer.

          That was the reason for the 23:59 malarkey.

          Maybe it is feasible to solve this in a way that's clear to everyone - I think this would involve:

          1) adding a new language string that says 'until end'.
          2) when $dateonly and if this is the 'end' value (probably means that boolean has to go back), display the previous day's date.

          Maybe that show date function needs to be changed to return an array of ($date, $untilend) or something... I dunno.

          The other question is from the point of view of people setting it up - again it can be a bit simpler to people if they see the inclusive deadline, in other words if they can choose a '23:59' type date and have this show up as the day-only value. Obviously this is only helpful if the date defaults to 23:59 as below and obviously in that case we would probably have to somehow bodge the date to 23:59:59 to avoid other complaints (we can get away with cutting off one second but not a whole minute). I can't remember if Moodle time selector is actually minute-accurate or less... HOWEVER the setup is a lot less important than the student view so I think we could go with people selecting 'next day 0:00' if needed.

          What do you think?

          SIMPLE PROBLEM

          Can we make it so the dates in the form default to suitable times (e.g. current day 00:00 and then either tomorrow 00:00 or today 23:59 depending on the above) so that the 'day only' feature kicks in automatically if people don't choose a specific time. I didn't test it but off the top of my head I think those fields default to the current time.

          (Note: Your patch will also change behaviour in different timezones but to be honest I think that was pretty much broken anyway and this version is better.)

          If we can resolve these issues I will certainly be happy to submit the patch for integration!

          Show
          Sam Marshall added a comment - Charles, this is good code. Thanks! From my point of view there are two problems with it, one complicated one and one simple. COMPLICATED PROBLEM Start time is fine, but supposing you set the 'end time' to, say, 13 July 00:00. Unless I am missing something, your code will show 'available until 13 July'. Unfortunately as I understand it, in this case it should actually show 'available until 12 July'. Or to be more explicit, 'available until end 12 July'. I had a discussion about this with our assessment people way back (b/c this feature is sometimes used for assessed material of some kind). We standardised on doing it that way because if you do it the other way you get complaints; even if only a small proportion of people read 'available until 13 July' as meaning that they could do it on the afternoon of that day, those are the small proportion of people who are going to complain and challenge their grades and generally be a pain. Doing it the other way around is much safer. That was the reason for the 23:59 malarkey. Maybe it is feasible to solve this in a way that's clear to everyone - I think this would involve: 1) adding a new language string that says 'until end'. 2) when $dateonly and if this is the 'end' value (probably means that boolean has to go back), display the previous day's date. Maybe that show date function needs to be changed to return an array of ($date, $untilend) or something... I dunno. The other question is from the point of view of people setting it up - again it can be a bit simpler to people if they see the inclusive deadline, in other words if they can choose a '23:59' type date and have this show up as the day-only value. Obviously this is only helpful if the date defaults to 23:59 as below and obviously in that case we would probably have to somehow bodge the date to 23:59:59 to avoid other complaints (we can get away with cutting off one second but not a whole minute). I can't remember if Moodle time selector is actually minute-accurate or less... HOWEVER the setup is a lot less important than the student view so I think we could go with people selecting 'next day 0:00' if needed. What do you think? SIMPLE PROBLEM Can we make it so the dates in the form default to suitable times (e.g. current day 00:00 and then either tomorrow 00:00 or today 23:59 depending on the above) so that the 'day only' feature kicks in automatically if people don't choose a specific time. I didn't test it but off the top of my head I think those fields default to the current time. (Note: Your patch will also change behaviour in different timezones but to be honest I think that was pretty much broken anyway and this version is better.) If we can resolve these issues I will certainly be happy to submit the patch for integration!
          Hide
          Charles Fulton added a comment -

          Sam, thanks for your input. I've been on the road a few days so I'm only now getting back to this. I've committed some new changes which address the complicated problem only. I did a rewrite with usergetmidnight() to detect days being specified (instead of times), and there's a new string "Available on X" to deal with the case you mentioned. It's still branched off the 2.1beta; I haven't had time to look at that.

          As far as the simple problem goes, I think the use of usergetmidnight() address it, and if it doesn't it was just as broken before .

          Show
          Charles Fulton added a comment - Sam, thanks for your input. I've been on the road a few days so I'm only now getting back to this. I've committed some new changes which address the complicated problem only. I did a rewrite with usergetmidnight() to detect days being specified (instead of times), and there's a new string "Available on X" to deal with the case you mentioned. It's still branched off the 2.1beta; I haven't had time to look at that. As far as the simple problem goes, I think the use of usergetmidnight() address it, and if it doesn't it was just as broken before .
          Hide
          Sam Marshall added a comment -

          Thanks, this version looks great. One possible problem and a few very minor issues:

          1) Changing $cm->availableuntil seems like a really bad idea. Isn't it possible that, being an object and therefore a reference, $cm may be shared by other places in the code not just this function? Why not just set a new local variable $availableuntil?

          2) Whitespace...

          a) line 344 has wrong indent (2 spaces instead of 4)
          b) line 338, 339 try to 'line up' when they should be 8 space indent. (By coincidence, I wrote a rant about this recently, http://learn.open.ac.uk/mod/oublog/view.php?user=11 - I don't actually think moodle code guidelines specifically prohibit it, but the 8 spaces for wrap rule is there, so...)
          c) 'git diff --check' shows 2 other errors.

          3) When this is finished, could you rebase the changes into a single commit please.

          Re the simple problem - didn't quite understand what you said but it may become clear when I can run the actual code. I'm having a technical problem with my 'core moodle' dev server at the moment, need to wait for somebody to sort it out... will write another comment after I've got that to work.

          Show
          Sam Marshall added a comment - Thanks, this version looks great. One possible problem and a few very minor issues: 1) Changing $cm->availableuntil seems like a really bad idea. Isn't it possible that, being an object and therefore a reference, $cm may be shared by other places in the code not just this function? Why not just set a new local variable $availableuntil? 2) Whitespace... a) line 344 has wrong indent (2 spaces instead of 4) b) line 338, 339 try to 'line up' when they should be 8 space indent. (By coincidence, I wrote a rant about this recently, http://learn.open.ac.uk/mod/oublog/view.php?user=11 - I don't actually think moodle code guidelines specifically prohibit it, but the 8 spaces for wrap rule is there, so...) c) 'git diff --check' shows 2 other errors. 3) When this is finished, could you rebase the changes into a single commit please. Re the simple problem - didn't quite understand what you said but it may become clear when I can run the actual code. I'm having a technical problem with my 'core moodle' dev server at the moment, need to wait for somebody to sort it out... will write another comment after I've got that to work.
          Hide
          Sam Marshall added a comment -

          OK, I have now tested briefly and found a few more issues:

          4) The code for moving the 'until' date to previous day doesn't work unless the 'from' date is also set. It should allow from date to be zero.

          5) In fact I don't think it should have a condition on the 'from' date being an exact midnight for that, at all. I think it should happen any time we omit the time.

          6) (I think as you mention this is just not done yet, rather than a bug) When the current date is not set - when creating a new activity or editing one that has the date zero - then the date/times default to current time. The time part of both dates should default to midnight so that users can easily access the 'show only date' behaviour.

          That's all. Thanks for your work on this.

          Show
          Sam Marshall added a comment - OK, I have now tested briefly and found a few more issues: 4) The code for moving the 'until' date to previous day doesn't work unless the 'from' date is also set. It should allow from date to be zero. 5) In fact I don't think it should have a condition on the 'from' date being an exact midnight for that, at all. I think it should happen any time we omit the time. 6) (I think as you mention this is just not done yet, rather than a bug) When the current date is not set - when creating a new activity or editing one that has the date zero - then the date/times default to current time. The time part of both dates should default to midnight so that users can easily access the 'show only date' behaviour. That's all. Thanks for your work on this.
          Hide
          Neill Magill added a comment -

          I had a poke around the code Charles wrote and made some of the changes Sam suggested:

          1) A local variable is now used
          4) is corrected
          6) Is changed, although the change will affect all intances of the datetime select (not just ones in activity conditions form) in all forms, so it might not be that great. Basically the datetime selector is given a time of the users local midnight when no value is already there.

          https://github.com/NeillM/moodle/compare/moodle%3Amaster...mdl-27242-test

          It should be rebased against 2.2 now as well

          Show
          Neill Magill added a comment - I had a poke around the code Charles wrote and made some of the changes Sam suggested: 1) A local variable is now used 4) is corrected 6) Is changed, although the change will affect all intances of the datetime select (not just ones in activity conditions form) in all forms, so it might not be that great. Basically the datetime selector is given a time of the users local midnight when no value is already there. https://github.com/NeillM/moodle/compare/moodle%3Amaster...mdl-27242-test It should be rebased against 2.2 now as well
          Hide
          Sam Marshall added a comment -

          (Neill - sorry it took me a month to reply to this but I have had to drop everything else and concentrate on critical bugs for the OU launch of Moodle 2. I hope it won't be another month before next time I look at Moodle issues, but can't promise that...)

          Thanks for your contributions to this. This looks to address my points 1, 4, 5 (and for those following along at home, 2 and 3 are trivial - 2 is whitespace and 3 is rebasing to single commit once finished, which it clearly isn't yet).

          Regarding point 6 I don't think this is quite good enough yet. Basically nobody is going to let us commit that There are two possibilities for a correct fix for 6:

          a) When initialising the form, set the initial value for those fields (to 0:00 on the current day) rather than leaving it 0 and letting the field deal with it. This would mean there is no need for a change to datetimeselector. If possible, I would most likely prefer this solution as it reduces the scope of the change.

          b) Add an option to datetimeselector (there's an options array right?) which controls whether to use the current time or midnight.

          If anybody wants to make that change (& the whitespace fixes etc), I think we'd be done (?!) and I can probably submit for integration finally...

          Show
          Sam Marshall added a comment - (Neill - sorry it took me a month to reply to this but I have had to drop everything else and concentrate on critical bugs for the OU launch of Moodle 2. I hope it won't be another month before next time I look at Moodle issues, but can't promise that...) Thanks for your contributions to this. This looks to address my points 1, 4, 5 (and for those following along at home, 2 and 3 are trivial - 2 is whitespace and 3 is rebasing to single commit once finished, which it clearly isn't yet). Regarding point 6 I don't think this is quite good enough yet. Basically nobody is going to let us commit that There are two possibilities for a correct fix for 6: a) When initialising the form, set the initial value for those fields (to 0:00 on the current day) rather than leaving it 0 and letting the field deal with it. This would mean there is no need for a change to datetimeselector. If possible, I would most likely prefer this solution as it reduces the scope of the change. b) Add an option to datetimeselector (there's an options array right?) which controls whether to use the current time or midnight. If anybody wants to make that change (& the whitespace fixes etc), I think we'd be done (?!) and I can probably submit for integration finally...
          Hide
          Sam Marshall added a comment -

          actually you know what? I just got duplicate bugs filed that will be resolved by this... I'll probably finish it myself. Hold on.

          Show
          Sam Marshall added a comment - actually you know what? I just got duplicate bugs filed that will be resolved by this... I'll probably finish it myself. Hold on.
          Hide
          Sam Marshall added a comment -

          realised that my option (a) above won't work; it would make the options default to on (that sucks!). Will look at option (b) instead.

          Show
          Sam Marshall added a comment - realised that my option (a) above won't work; it would make the options default to on (that sucks!). Will look at option (b) instead.
          Hide
          Sam Marshall added a comment -

          Here is my work on it:

          https://github.com/sammarshallou/moodle/compare/master...MDL-27242-progress

          In addition to above problem I fixed the way it checks if you specify date the same.

          If anyone has a chance to review my changes that would be good. Once everyone's satisfied (or if nobody reviews it... and I remember!) I will combine these into a single commit and submit for integration.

          Note about credit: If I am clever enough I will try to make that commit have multiple author lines or whatever you can do in git in that regard, otherwise I'll leave it with me as author and credit both others in the comment.

          Show
          Sam Marshall added a comment - Here is my work on it: https://github.com/sammarshallou/moodle/compare/master...MDL-27242-progress In addition to above problem I fixed the way it checks if you specify date the same. If anyone has a chance to review my changes that would be good. Once everyone's satisfied (or if nobody reviews it... and I remember!) I will combine these into a single commit and submit for integration. Note about credit: If I am clever enough I will try to make that commit have multiple author lines or whatever you can do in git in that regard, otherwise I'll leave it with me as author and credit both others in the comment.
          Hide
          Neill Magill added a comment -

          I have noticed somethings:

          Line 340 of conditionlib.php should be using == rather than >, or it will only trigger when $this->cm->availableuntil is midnight and $this->cm->availablefrom is after midnight on the day before, i.e.

          $this->cm->availableuntil = 2nd Octomber 2011 00:00:00
          $this->cm->availablefrom = 1st October 2011 12:00:00

          The restriction text will show up as "Available on 1st October", which is incorrect.

          The $this->cm->availablefrom > $availableuntil will still need to be checked for though but it will need to set:

          $information .= get_string('requires_date_both', 'condition', (object)array(
          'from' => self::show_time($this->cm->availablefrom),
          'until' => self::show_time($this->cm->$availableuntil)));

          or Restriction text will show as: "Available from 1st October 2011, 12:00 PM to 1st October 2011."

          Show
          Neill Magill added a comment - I have noticed somethings: Line 340 of conditionlib.php should be using == rather than >, or it will only trigger when $this->cm->availableuntil is midnight and $this->cm->availablefrom is after midnight on the day before, i.e. $this->cm->availableuntil = 2nd Octomber 2011 00:00:00 $this->cm->availablefrom = 1st October 2011 12:00:00 The restriction text will show up as "Available on 1st October", which is incorrect. The $this->cm->availablefrom > $availableuntil will still need to be checked for though but it will need to set: $information .= get_string('requires_date_both', 'condition', (object)array( 'from' => self::show_time($this->cm->availablefrom), 'until' => self::show_time($this->cm->$availableuntil))); or Restriction text will show as: "Available from 1st October 2011, 12:00 PM to 1st October 2011."
          Hide
          Sam Marshall added a comment -

          Hm, complicated.

          Thanks for that, will look into it.

          I also realised last night that this change needs a database upgrade so I have just coded that (it's on github now).

          Show
          Sam Marshall added a comment - Hm, complicated. Thanks for that, will look into it. I also realised last night that this change needs a database upgrade so I have just coded that (it's on github now).
          Hide
          Neill Magill added a comment -

          For some reason the restriction dates seem to be defaulting to 2010 rather than 2011 as well...

          Show
          Neill Magill added a comment - For some reason the restriction dates seem to be defaulting to 2010 rather than 2011 as well...
          Hide
          Neill Magill added a comment -

          Even stranger the month is December rather than October as well

          Show
          Neill Magill added a comment - Even stranger the month is December rather than October as well
          Hide
          Neill Magill added a comment -

          Found out the issue with the default dates:

          Line 437 of moodlefor_mod.php needs to be: $midnight = make_timestamp($date['year'], $date['mon'], $date['mday']);

          $date['mon'] returns the integer version of the month that make_timestamp needs, rather than the textual representation of $date['month']

          Show
          Neill Magill added a comment - Found out the issue with the default dates: Line 437 of moodlefor_mod.php needs to be: $midnight = make_timestamp($date ['year'] , $date ['mon'] , $date ['mday'] ); $date ['mon'] returns the integer version of the month that make_timestamp needs, rather than the textual representation of $date ['month']
          Hide
          Sam Marshall added a comment -

          I decided to rewrite much of the code around that area to make it clearer, including a large comment that contains all possible examples (which I intend to use in the test instructions in this issue). Also fixed other stupid bug I introduced. New commits on github now.

          Anyone have more comments?

          Show
          Sam Marshall added a comment - I decided to rewrite much of the code around that area to make it clearer, including a large comment that contains all possible examples (which I intend to use in the test instructions in this issue). Also fixed other stupid bug I introduced. New commits on github now. Anyone have more comments?
          Hide
          Neill Magill added a comment -

          I cannot see any issues now.

          Show
          Neill Magill added a comment - I cannot see any issues now.
          Hide
          Sam Marshall added a comment -

          Thanks Neil. I think that's good enough for now - I'm submitting this minor but important new feature for integration into Moodle 2.2.

          About author credit, apparently it isn't possible to have multiple authors in a Git commit, so I had to just add names in the commit description, sorry about that.

          Show
          Sam Marshall added a comment - Thanks Neil. I think that's good enough for now - I'm submitting this minor but important new feature for integration into Moodle 2.2. About author credit, apparently it isn't possible to have multiple authors in a Git commit, so I had to just add names in the commit description, sorry about that.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Sam Marshall added a comment -

          Rebased to this week (was conflict only because of db version change, sigh).

          Show
          Sam Marshall added a comment - Rebased to this week (was conflict only because of db version change, sigh).
          Hide
          Sam Hemelryk added a comment -

          Thanks everyone involved - this has been integrated now.
          Thank you very much - the code was spot on!

          Show
          Sam Hemelryk added a comment - Thanks everyone involved - this has been integrated now. Thank you very much - the code was spot on!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Many thanks for all the hard work. This is now part of Moodle, your favorite LMS.

          Closing as fixed, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Many thanks for all the hard work. This is now part of Moodle, your favorite LMS. Closing as fixed, ciao

            People

            • Votes:
              38 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: