|
History
| Log In
|
|
|
|
> 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 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] 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 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 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 :-) 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. 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. 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 Helen, could you please tweak the docs so that there is no PHP code in it, thanks!
Thanks for everyone's work on this :-)
PHP removed and help file reworded. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Major
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-)