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-)

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

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]

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

-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

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

• 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.

• 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

PHP removed and help file reworded.

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?

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

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.