Moodle
  1. Moodle
  2. MDL-13847 backup/restore issues meta
  3. MDL-2674

backup always backsup/restores groups regardless of user settings

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.2, 1.9
    • Fix Version/s: 1.9.1
    • Component/s: Backup, Groups
    • Labels:
      None
    • Environment:
      All
    • Database:
      Any
    • Affected Branches:
      MOODLE_15_STABLE, MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      32968

      Description

      It seems to me that backup and restore will always include groups and group memberships, regardless of whether user info is selected or not.

      I think the correct behaviour would be to always backup/restore group names, but only backup/restore the group memberships if user info has been selected.

      Thoughts?

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          From (penny at catalyst.net.nz) Friday, 4 March 2005, 09:33 AM:

          Also, perhaps there should actually be a setting for groups names.

          In looking at the code it seems like scales and events always get backed up/restored without asking for a preference as well.

          From (penny at catalyst.net.nz) Friday, 4 March 2005, 12:28 PM:

          Also, group images don't seem to be backed up/restored?

          From Eloy Lafuente (stronk7 at moodle.org) Saturday, 5 March 2005, 08:54 AM:

          Groups are always saved but group members only if you select to backup users.

          Only used scales (course_scale_used() function) are included automatically, and course events too. Here it's an ordered list of my opinions:

          1-Having a setting for groups could be a nightmare because modules running under groups in the original course have to be modified to take care of this setting to delete their group info (and group mode). It's possible to implement it but perhaps it's too late for 1.5...

          2-About groups too, yes, images should be included in backup and restore! I've added it to my todo list (backup/CHANGES_14_15.txt). My fault!

          3-Having a setting for scales it's really a wrong idea and I think that the current approach (export used scales) is the correct one. We can, anyway, improve it a bit to detect only scales used by modules being exported (currently all scales in any module in the course are being included). This involves creating a new function in backup/lib.php called backup_scale_used() really similar to the course based but skipping not selected modules. For 1.5?

          4.-And finally, events. A setting for this could be really nice and easy to implement. As such info in not related to the rest of the backup (like groups or scales) having a check to decide it is really a good idea. For 1.5?

          Ciao

          From (penny at catalyst.net.nz) Monday, 7 March 2005, 04:29 AM:

          Sorry, my bad, I just did cvs annotate on restorelib.php and saw that the check for backup->users for group members was added after our last merge. Should have checked that before posting the bug report.

          From Eloy Lafuente (stronk7 at moodle.org) Tuesday, 8 March 2005, 01:38 AM:

          NP!

          Anyway, we have to decide about points 3 and 4 (Martin D added to the discussion).

          Are my theories correct? Must I include them in my CHANGES_14_15 list?

          Ciao

          From (penny at catalyst.net.nz) Thursday, 10 March 2005, 04:18 AM:

          > 1-Having a setting for groups could be a nightmare because modules running

          > under groups in the original course have to be modified to take care of this

          > setting to delete their group info (and group mode). It's possible to implement it

          > but perhaps it's too late for 1.5...

          I agree that it would be a nightmare, because of all the modules and how they work with groups. Maybe for 1.6? I mean, I'd love it for 1.5 but it may be unrealistic.

          > 3-Having a setting for scales it's really a wrong idea and I think that the current

          > approach (export used scales) is the correct one. We can, anyway, improve it a bit

          > to detect only scales used by modules being exported (currently all scales in any

          > module in the course are being included). This involves creating a new function in

          > backup/lib.php called backup_scale_used() really similar to the course based but

          > skipping not selected modules. For 1.5?

          +1, but with a setting for it, like:

          there are scales, but they're not used anywhere. Do you still want to export them?

          > 4.-And finally, events. A setting for this could be really nice and easy to

          > implement. As such info in not related to the rest of the backup (like groups or

          > scales) having a check to decide it is really a good idea. For 1.5?

          Yup! Sounds good. +1

          From (penny at catalyst.net.nz) Wednesday, 12 October 2005, 10:44 AM:

          bump! anything happened on this one?

          From Eloy Lafuente (stronk7 at moodle.org) Friday, 14 October 2005, 03:52 AM:

          Hey,

          this was lost in the abyss of my bugs...

          Should I try to do it or, perhaps, you have intentions to do so?

          About 3, perhaps the setting should be a popup between:

          • Needed Scales (all those being used by selected activities).
          • All Scales (all those being used by any activity in the course, like it's now).

          About 4, a simple Y/N will be enough, I think.

          From Eloy Lafuente (stronk7 at moodle.org) Wednesday, 3 May 2006, 03:48 AM:

          Hehe,

          what if....we postpone this some more months? :-P

          ...orr perhaps somebody else could try it after 1.6 branch... I estimate that my time availability next 5-6 moths is going to be really short! But moodling, of course! B-)

          Show
          Martin Dougiamas added a comment - From (penny at catalyst.net.nz) Friday, 4 March 2005, 09:33 AM: Also, perhaps there should actually be a setting for groups names. In looking at the code it seems like scales and events always get backed up/restored without asking for a preference as well. From (penny at catalyst.net.nz) Friday, 4 March 2005, 12:28 PM: Also, group images don't seem to be backed up/restored? From Eloy Lafuente (stronk7 at moodle.org) Saturday, 5 March 2005, 08:54 AM: Groups are always saved but group members only if you select to backup users. Only used scales (course_scale_used() function) are included automatically, and course events too. Here it's an ordered list of my opinions: 1-Having a setting for groups could be a nightmare because modules running under groups in the original course have to be modified to take care of this setting to delete their group info (and group mode). It's possible to implement it but perhaps it's too late for 1.5... 2-About groups too, yes, images should be included in backup and restore! I've added it to my todo list (backup/CHANGES_14_15.txt). My fault! 3-Having a setting for scales it's really a wrong idea and I think that the current approach (export used scales) is the correct one. We can, anyway, improve it a bit to detect only scales used by modules being exported (currently all scales in any module in the course are being included). This involves creating a new function in backup/lib.php called backup_scale_used() really similar to the course based but skipping not selected modules. For 1.5? 4.-And finally, events. A setting for this could be really nice and easy to implement. As such info in not related to the rest of the backup (like groups or scales) having a check to decide it is really a good idea. For 1.5? Ciao From (penny at catalyst.net.nz) Monday, 7 March 2005, 04:29 AM: Sorry, my bad, I just did cvs annotate on restorelib.php and saw that the check for backup->users for group members was added after our last merge. Should have checked that before posting the bug report. From Eloy Lafuente (stronk7 at moodle.org) Tuesday, 8 March 2005, 01:38 AM: NP! Anyway, we have to decide about points 3 and 4 (Martin D added to the discussion). Are my theories correct? Must I include them in my CHANGES_14_15 list? Ciao From (penny at catalyst.net.nz) Thursday, 10 March 2005, 04:18 AM: > 1-Having a setting for groups could be a nightmare because modules running > under groups in the original course have to be modified to take care of this > setting to delete their group info (and group mode). It's possible to implement it > but perhaps it's too late for 1.5... I agree that it would be a nightmare, because of all the modules and how they work with groups. Maybe for 1.6? I mean, I'd love it for 1.5 but it may be unrealistic. > 3-Having a setting for scales it's really a wrong idea and I think that the current > approach (export used scales) is the correct one. We can, anyway, improve it a bit > to detect only scales used by modules being exported (currently all scales in any > module in the course are being included). This involves creating a new function in > backup/lib.php called backup_scale_used() really similar to the course based but > skipping not selected modules. For 1.5? +1, but with a setting for it, like: there are scales, but they're not used anywhere. Do you still want to export them? > 4.-And finally, events. A setting for this could be really nice and easy to > implement. As such info in not related to the rest of the backup (like groups or > scales) having a check to decide it is really a good idea. For 1.5? Yup! Sounds good. +1 From (penny at catalyst.net.nz) Wednesday, 12 October 2005, 10:44 AM: bump! anything happened on this one? From Eloy Lafuente (stronk7 at moodle.org) Friday, 14 October 2005, 03:52 AM: Hey, this was lost in the abyss of my bugs... Should I try to do it or, perhaps, you have intentions to do so? About 3, perhaps the setting should be a popup between: Needed Scales (all those being used by selected activities). All Scales (all those being used by any activity in the course, like it's now). About 4, a simple Y/N will be enough, I think. From Eloy Lafuente (stronk7 at moodle.org) Wednesday, 3 May 2006, 03:48 AM: Hehe, what if....we postpone this some more months? :-P ...orr perhaps somebody else could try it after 1.6 branch... I estimate that my time availability next 5-6 moths is going to be really short! But moodling, of course! B-)
          Hide
          Timothy Takemoto added a comment -

          > From (penny at catalyst.net.nz) Thursday, 10 March 2005, 04:18 AM:
          > 1-Having a setting for groups could be a nightmare because modules running
          > under groups in the original course have to be modified to take care of this
          > setting to delete their group info (and group mode). It's possible to implement it
          > but perhaps it's too late for 1.5...
          Eloy wrote
          > I agree that it would be a nightmare, because of all the modules and how they work
          > with groups. Maybe for 1.6? I mean, I'd love it for 1.5 but it may be unrealistic.

          I would like the ability to turn off backup/restore groups.

          Especially in the case when the course contains no group settings. In other words initially the setting could be quite, violent.
          It could throw away all group associated data.

          Tim

          Show
          Timothy Takemoto added a comment - > From (penny at catalyst.net.nz) Thursday, 10 March 2005, 04:18 AM: > 1-Having a setting for groups could be a nightmare because modules running > under groups in the original course have to be modified to take care of this > setting to delete their group info (and group mode). It's possible to implement it > but perhaps it's too late for 1.5... Eloy wrote > I agree that it would be a nightmare, because of all the modules and how they work > with groups. Maybe for 1.6? I mean, I'd love it for 1.5 but it may be unrealistic. I would like the ability to turn off backup/restore groups. Especially in the case when the course contains no group settings. In other words initially the setting could be quite, violent. It could throw away all group associated data. Tim
          Hide
          Nick Freear added a comment -

          Hi,
          Just found this bug, and the option to include/exclude groups (and groupings?) on backup/restore is something we'd very much like at the OU. I agree we need to define what happens for activities in group mode.

          I'm not sure it can be done for 1.9, but I took the liberty of updating the "Affects versions" and Components information.
          Many thanks

          Nick

          [OU Bug 3132 "groups are copied from previous course presentations on backup/restore" - Sophie]

          Show
          Nick Freear added a comment - Hi, Just found this bug, and the option to include/exclude groups (and groupings?) on backup/restore is something we'd very much like at the OU. I agree we need to define what happens for activities in group mode. I'm not sure it can be done for 1.9, but I took the liberty of updating the "Affects versions" and Components information. Many thanks Nick [OU Bug 3132 "groups are copied from previous course presentations on backup/restore" - Sophie]
          Hide
          Nick Freear added a comment -

          Penny & Eloy,
          I'm looking at a potential fix for this bug for HEAD/2.0, see the Moodle Wiki,
          http://docs.moodle.org/en/Development:Groupings_OU#Groups_optional_backup.2Frestore

          I'm investigating just giving the user an option on restore initially. This should be quicker to implement - I'm on a tight schedule to do this for the OU.
          Hopefully have a patch soon. Comments welcome!
          Thanks

          Nick

          Show
          Nick Freear added a comment - Penny & Eloy, I'm looking at a potential fix for this bug for HEAD/2.0, see the Moodle Wiki, http://docs.moodle.org/en/Development:Groupings_OU#Groups_optional_backup.2Frestore I'm investigating just giving the user an option on restore initially. This should be quicker to implement - I'm on a tight schedule to do this for the OU. Hopefully have a patch soon. Comments welcome! Thanks Nick
          Hide
          Nick Freear added a comment -

          Finally a patch. It affects 9 files:

          -backup/restore_form.html
          -backup/restorelib.php - 3 constants defined, new function restore_group_getid
          + other mods.
          -backup/restore_check.html

          -lang/en_utf8/group.php
          -lang/en_utf8/moodle.php - missing backup string 'writinggroupingsgroupsinfo'.

          -mod/chat/restorelib.php
          -mod/data/restorelib.php
          -mod/forum/restorelib.php
          -mod/wiki/restorelib.php

          I would like to commit to HEAD in the next day or so, and possibly back port to 1.9 - definitely Skype beforehand!
          (Petr, hope you don't mind me adding you as a watcher.)

          Comments welcome! Thanks
          Nick

          Show
          Nick Freear added a comment - Finally a patch. It affects 9 files: -backup/restore_form.html -backup/restorelib.php - 3 constants defined, new function restore_group_getid + other mods. -backup/restore_check.html -lang/en_utf8/group.php -lang/en_utf8/moodle.php - missing backup string 'writinggroupingsgroupsinfo'. -mod/chat/restorelib.php -mod/data/restorelib.php -mod/forum/restorelib.php -mod/wiki/restorelib.php I would like to commit to HEAD in the next day or so, and possibly back port to 1.9 - definitely Skype beforehand! (Petr, hope you don't mind me adding you as a watcher.) Comments welcome! Thanks Nick
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Looks correct. Cool!

          Only 1thought (not critical) that have arrived while reviewing the code:

          Shouldn't activity group mode be "reseted" acordingly with the "reset" that code performs in discussions /entries.... ? not 100% sure, just one thought about what is more "logical".

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Looks correct. Cool! Only 1thought (not critical) that have arrived while reviewing the code: Shouldn't activity group mode be "reseted" acordingly with the "reset" that code performs in discussions /entries.... ? not 100% sure, just one thought about what is more "logical". Ciao
          Hide
          Nick Freear added a comment -

          Version 8 core of the patch - 1 extra file + modifications:

          • lang/en_utf8/help/grouprestore.html
          • backup/restorelib.php - added the 4th RESTORE_GROUPS_NONE constant - now a full set!

          In response to Eloy - it may be logical to reset group mode, but for us (OU) and hopefully others, it seems more useful to maintain activity group mode so that groups can be recreated. The new help file hopefully explains this, and the group restore options generally.

          Comments welcome! I'd like to commit this Monday 10th to HEAD, and maybe 1.9 - if I get the nod
          Ciao.

          Show
          Nick Freear added a comment - Version 8 core of the patch - 1 extra file + modifications: lang/en_utf8/help/grouprestore.html backup/restorelib.php - added the 4th RESTORE_GROUPS_NONE constant - now a full set! In response to Eloy - it may be logical to reset group mode, but for us (OU) and hopefully others, it seems more useful to maintain activity group mode so that groups can be recreated. The new help file hopefully explains this, and the group restore options generally. Comments welcome! I'd like to commit this Monday 10th to HEAD, and maybe 1.9 - if I get the nod Ciao.
          Hide
          Nick Freear added a comment -

          Hi, I've committed revision 8 of the patch (affecting 10 files, see previous comments) to Moodle HEAD. Can I backport this to 1.9 branch now?
          Thanks, Nick.

          Show
          Nick Freear added a comment - Hi, I've committed revision 8 of the patch (affecting 10 files, see previous comments) to Moodle HEAD. Can I backport this to 1.9 branch now? Thanks, Nick.
          Hide
          Petr Škoda added a comment - - edited

          taking over this one:

          • backporting for 1.9.1
          • adding restore_grouping_getid() - we need to fix cm->groupingid if groupings not restored
          • adding option to restore groups only without groupings
          • perf improvements
          • I do not think there should be PHP "ifs" in help files, we should be able to describe both functions without/with groupings
          Show
          Petr Škoda added a comment - - edited taking over this one: backporting for 1.9.1 adding restore_grouping_getid() - we need to fix cm->groupingid if groupings not restored adding option to restore groups only without groupings perf improvements I do not think there should be PHP "ifs" in help files, we should be able to describe both functions without/with groupings
          Hide
          Petr Škoda added a comment -

          Helen, could you please tweak the docs so that there is no PHP code in it, thanks!

          Show
          Petr Škoda added a comment - Helen, could you please tweak the docs so that there is no PHP code in it, thanks!
          Hide
          Petr Škoda added a comment -

          ...and close this when done, thanks

          Show
          Petr Škoda added a comment - ...and close this when done, thanks
          Hide
          Helen Foster added a comment -

          Thanks for everyone's work on this

          PHP removed and help file reworded.

          Show
          Helen Foster added a comment - Thanks for everyone's work on this PHP removed and help file reworded.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Closing as requested. Thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Closing as requested. Thanks!
          Hide
          Timothy Takemoto added a comment -

          I see that his is only for 1.9 and above.

          I still use 1.6

          Does anyone have any suggestions on a hack for 1.6 to just ignore all backup and restore of groups?

          Show
          Timothy Takemoto added a comment - I see that his is only for 1.9 and above. I still use 1.6 Does anyone have any suggestions on a hack for 1.6 to just ignore all backup and restore of groups?
          Hide
          David Mudrak added a comment -

          Timothy, Moodle 1.6 is not supported version any more (and we are going to stop supporting 1.7 on October 31). You should upgrade your server anyway as using 1.6 may be considered as a sort of hazard...

          Show
          David Mudrak added a comment - Timothy, Moodle 1.6 is not supported version any more (and we are going to stop supporting 1.7 on October 31). You should upgrade your server anyway as using 1.6 may be considered as a sort of hazard...
          Hide
          Timothy Takemoto added a comment -

          I don't think that I have that luxury. I would like to avoid the hazard.

          The first of the two diffs looked like it was going to work since it is for 1.6.3
          (I am using that on one site..) but mine is now 1.6.2+ and there were no references
          to groupingid in my restorelib.php. Drat.

          Tim

          Show
          Timothy Takemoto added a comment - I don't think that I have that luxury. I would like to avoid the hazard. The first of the two diffs looked like it was going to work since it is for 1.6.3 (I am using that on one site..) but mine is now 1.6.2+ and there were no references to groupingid in my restorelib.php. Drat. Tim
          Hide
          Petr Škoda added a comment -

          1.6.2+ - is that a joke? I hope it is not accessible from internet, is it?!

          Show
          Petr Škoda added a comment - 1.6.2+ - is that a joke? I hope it is not accessible from internet, is it?!
          Hide
          Timothy Takemoto added a comment -

          Ha ha!
          It is accessible from the internet. The only thing that is accessible is the login page, to a IMAP server, and I trust my students not to hack, but maybe the loging is no longer secure.
          I wish that there were security patches available.
          I may upgrade to 1.6.3 but that is the limit of my TUI module, which cost me 2000 dollars, that I like.
          If I upgrade to 1.6.3 then then I can apply the patch above. I am not aware of other things that I want from moodle. Roles!?
          But I do need to fix this bug.

          Show
          Timothy Takemoto added a comment - Ha ha! It is accessible from the internet. The only thing that is accessible is the login page, to a IMAP server, and I trust my students not to hack, but maybe the loging is no longer secure. I wish that there were security patches available. I may upgrade to 1.6.3 but that is the limit of my TUI module, which cost me 2000 dollars, that I like. If I upgrade to 1.6.3 then then I can apply the patch above. I am not aware of other things that I want from moodle. Roles!? But I do need to fix this bug.
          Hide
          Petr Škoda added a comment -

          There is nothing like "only login page is accessible" - you do not need any login in order to exploit some bugs. Upgrading to 1.6.3 does not solve anything, you must upgrade to latest MOODLE_16_STABLE cvs branch at least, but even that is not enough because 1.6.x is not maintained - no more bug&security fixes there

          Show
          Petr Škoda added a comment - There is nothing like "only login page is accessible" - you do not need any login in order to exploit some bugs. Upgrading to 1.6.3 does not solve anything, you must upgrade to latest MOODLE_16_STABLE cvs branch at least, but even that is not enough because 1.6.x is not maintained - no more bug&security fixes there
          Hide
          Timothy Takemoto added a comment -

          Well, as I have said in conversation before, I wish that would would tell us about the bug fixes rather than encourage us to upgrade.

          Show
          Timothy Takemoto added a comment - Well, as I have said in conversation before, I wish that would would tell us about the bug fixes rather than encourage us to upgrade.
          Hide
          Petr Škoda added a comment -

          I just looked at the TUI code available from the module database - it is very old code from 1.5.x times that is still relying on register globals, no new param cleaning, etc. - this module alone has probably many security issues itself.

          Show
          Petr Škoda added a comment - I just looked at the TUI code available from the module database - it is very old code from 1.5.x times that is still relying on register globals, no new param cleaning, etc. - this module alone has probably many security issues itself.
          Hide
          Timothy Takemoto added a comment -

          I hacked TUI to work with 1.6. Register globals...when was that turned off?
          Can people access TUI without login?

          Anyway, anyway, tell us the issues. I bet that there are very few. 5? 10? patchable.

          Please share the patches. I do not want to be on a windows-like bloatware upgrade escalator.
          Moodle is enough for me (the contents are the problem) at 1.6.

          Last time we had this conversation I looked through the security issues and it seemed to
          me that all of them were relevant to those that used blogs or ... modules that I was not using.

          But I need this. Groups restoring even though you don't want them to, is a real pain.

          Show
          Timothy Takemoto added a comment - I hacked TUI to work with 1.6. Register globals...when was that turned off? Can people access TUI without login? Anyway, anyway, tell us the issues. I bet that there are very few. 5? 10? patchable. Please share the patches. I do not want to be on a windows-like bloatware upgrade escalator. Moodle is enough for me (the contents are the problem ) at 1.6. Last time we had this conversation I looked through the security issues and it seemed to me that all of them were relevant to those that used blogs or ... modules that I was not using. But I need this. Groups restoring even though you don't want them to, is a real pain.
          Hide
          Petr Škoda added a comment - - edited

          I am sorry, I am not going to review/fix dead code - I have to concentrate on 1.9.6 and 2.0 right now

          Show
          Petr Škoda added a comment - - edited I am sorry, I am not going to review/fix dead code - I have to concentrate on 1.9.6 and 2.0 right now
          Hide
          Timothy Takemoto added a comment -

          It is kind of you to even consider it. Good luck with 2.0.
          I will look into moving to 1.6 stable, and then applying the first of the two patches above.
          Tim

          Show
          Timothy Takemoto added a comment - It is kind of you to even consider it. Good luck with 2.0. I will look into moving to 1.6 stable, and then applying the first of the two patches above. Tim

            People

            • Votes:
              7 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: