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