Item10304: TopicUserMappingContrib resets AdminGroup

If you re-install TopicUserMappingContrib using configure, your AdminGroup is overwritten. Your customisations are lost, AdminGroup has no members anymore. I suspect the same will happen in case of updating TopicUserMappingContrib.

-- KerstinPuschke - 31 Jan 2011

Was the file overwritten or "checked in" as a new revision? On 1.1.x, configure should have checked in the changes into a new rev, preserving your local changes in the older revision. Also configure should have backed up the previous version into a tar/zip file in working/configure/backups. The message during installation should have included:

...
Archived as /your/path/working/configure/backup/TopicUserMappingContrib-backup-20110131-140555.tgz
...
Checked in: data/Main/AdminGroup.txt  as Main.AdminGroup     

If the message said "Installed .." instead of "Checked in .." then your original was overwritten. If checked in, you should be able to use your super admin login to revert to the older version without loosing your changes.

-- GeorgeClark - 31 Jan 2011

Further testing this, restoring an old revision puts back local customizations to the topic text, but it doesn't restore the metadata, so the group members are indeed lost.

... Well not quite. The original settings can be found by viewing the raw debug version. http://your.site/Main/AdminGroup?raw=all;rev=6 This could be saved to a new txt file to replace the corrupted topic.

-- GeorgeClark - 31 Jan 2011

imo, restore topic should restore all components of a revision - otherwise we're surprising everyone

-- SvenDowideit - 01 Feb 2011

+1 - except, of course, the TOPICINFO

-- CrawfordCurrie - 01 Feb 2011

+1 to restore META data along with the topic text

-- KerstinPuschke - 01 Feb 2011

Back to TopicUserMappingContrib.

The backup is written and the file is checked in. Yes, you can restore the previous version if you have access to the file system or, as George points out, with the help of the raw=all parameter.

Being able to restore the previous version, of course, is much better than loosing the previous version completely. Nevertheless, the situation is a bit unsatisfying. If you update a contrib, you are probably not aware that you have to fix things manually afterwards. You might not notice until you or your fellow AdminGroup-members find themselves locked out of something they want to read or use. Even if you remember that you have to do something after a TopicUserMappingContrib update, it is quite uncomfortable. Imo, whenever possible, extension updates should not touch customizations, esp. if we are talking about common and important customizations like AdminGroup.

Foswiki already uses some mechanisms to handle these things. Main.WikiUsers does not exist in the first place and is created from a template if necessary. Main.UserRegistration also does not exist in the first place and as long as you do not create it, System.UserRegristration is used. Extension updates and even foswiki updates do not need to provide Main.UserRegistration or Main.WikiUsers. Maybe something like this can be applied here as well.

-- KerstinPuschke - 01 Feb 2011

Unfortunately for most of the commonly tailored topics, there is a manual effort to remove and re-package the "upgrade" version of the packages. Many files are removed, and it's been a slow process to change to templates, includes, or dynamically created topics. There are several feature proposals looking to address this issue.

For extensions, I propose that we add a !norep option to the MANIFEST. Any files tagged as !norep would only be installed if missing. I suspect that there are only a couple of files that would use this option. This probably needs a feature proposal to go through the approval process.

-- GeorgeClark - 01 Feb 2011

Thinking about this a bit, using a norep flag, could we automate the building of the update packages. Any file flagged norep would be excluded from the update version of the tar/zip files.

-- GeorgeClark - 01 Feb 2011

As a 1.1 fix I would propose that the AdminGroup topic is moved from the contrib and into core. Upgrade packages do not include this topic. And updating the contrib will then not overwrite AdminGroup.

There are many of us that upgrade extensions the manual way by throwing the zip on top of the foswiki tree and then no norep flag will save you.

It is a good idea with a norep flag though for both core and extensions. But for a 1.1.x context moving the file from the contrib to core is a safe way to fix this.

I personally never understood why this feature was separated out in a contrib anyway.

-- KennethLavrsen - 02 Feb 2011

The AdminGroup topic has been moved into core.

-- GeorgeClark - 03 Feb 2011

Kenneth, This was fixed in 1.1.3 but didn't get picked up in the release notes, It was set to Minor instead of Patch release, so it was stuck in Waiting for Release. How do we handle it, update the release notes or just close?

-- GeorgeClark - 19 Apr 2011

Add it to the release note table under the 1.1.3 section and close the task

When we release 1.1.4 it will be in the table. Not a big deal that this one is missing in the 1.1.3 release note.

-- KennethLavrsen - 19 Apr 2011

Commenting is disabled while not logged in