This was added in Tiki18 and it was a massive amount of work. Many improvements had to be made for this work.
--
Similar to Save current configuration as a profile, profile rollback/undo/restore is a common feature request.
Xavier de Pedro wrote:
- There needs to be a rollback or undo feature for profiles. It's a huge usability problem that this isn't easily possible. A solution, as discussed in TikiFestBarcelona could be that Tiki saves the current feature settings and permissions in a log (syslog?, action log?), which allows to reset them back to that state later on, after the profile was installed. If there are some extra manual changes in the tiki site between profile install and reverting to a previous state, those changes would be lost, or some algorithm should be implemented to handle it wisely.
These system wouldn't handle deleting objects, maybe, in the first implementation phase, but ideally, on a second phase, it would allow the user to select also the option to delete the objects created initially by the profile.
Opinion by marclaporte
While I acknowledge that it can be desirable, people are very surprised when I tell them it's not a high priority for me at this time. I will attempt to explain here. I am not saying no or never. I am saying I see many more things on the list ahead of that. I am not preventing anyone to give it a shot, but if you do, I suspect you'll find it's a lot more work than you would first think. And you'll soon give up the goal of a full undo system, in favor of a more targeted approach.
- The system/concept is still quite young and we don't really know how it's going to be used yet. I expect that we will find ways to use it that we hadn't anticipated. So automating that part of it seems premature. Will people use it more to distribute content? settings? etc. So let's find out more what people are using it for to know where further automation would be most useful.
- It would take coding time and I prefer to have that coding time to debug/improve what we already have.
- This is very complex and risky. If the feature exists, people will expect it to work.
- We don't have the human and technical infrastructure to test
- The profile restore system would have to remember the previous value and restore it.
- This (version history for prefs) doesn't exist in Tiki.
- Some things could have changed since the profile was run, and thus we could run into merge issues.
- Profiles don't just change preferences, they also can create objects (tracker items, wiki pages) and containers (file gallery, trackers, etc). If we have an undo, people will expect that it will restore exactly as it was. Deleting objects is not something I feel profiles should do. I think it's better to let site Admins make that judgement. If we need tools to facilitate mass update/delete, this is something that should be dealt with by the normal Tiki interface.
- When important, it's possible to have inverse profiles like Debug_Mode_Enabled and Debug_Mode_Disabled.
- I disagree that it's a deal breaker. Most CMS systems don't have a system like this, where configurations can be applied on an existing install. They usually have a system at "install-only" like we used to have.
- Users can experiment profiles on fresh installs, and only apply on their real install when they are sure that's what they want.
Having an easy way to know what changed and to restore preferences and settings is a desirable thing. However, this is not the job of profiles. This is the job of the system log, as it could be manual configurations that we want to roll back. -> http://dev.tiki.org/wish2412
Once we have that, perhaps we could look into having options in profiles to "restore to Tiki default" or "restore to previous version".
System log could be improved to:
- have an easy "revert change button" next to each log entry.
- indicate which changes were done by which profile, to make it easy for someone to "check all" and revert.
But again, this is the job of system log, not profiles