Keep custom settings on server update

Registered by Joël Grand-Guillaume @ camptocamp

Updating the server (command line and from client side) override custom user settings, like translation, access right, views, and so on.

To avoid this, we purpose to implement new features to allow people choose what should be updated from new files, and what should not. This will make the customization made through the interface as good as those made into a module. This blueprint is a result of a discussion between jgrandguillaume and rvalyi, started in the IRC channel, every idea is welcome !

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Joël Grand-Guillaume @ camptocamp
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Not started
Milestone target:
None

Whiteboard

The problematic
============

When you make an update of the server, he will update your data model, your settings trough the XML files (like views, parameters, etc..), your translation and your access right, according to the last definitions present in the new version.

For some reasons, sometimes it's exactly what you want, but sometimes it just destroy everything you made through the web or GTK interface. What we want is being able to choose what we wanna keep, and what we wanna reset according to the new version.

Technical details
============

Every ressources (like views, settings,....) loaded from XML files have an "XML ID" stored into the table ir_model_data with create and write date. Each of this resources could be updated according to that "XML ID", and that's what happen when you update your
server (with update=all for example).

According to that, we can identify which resource has been modified till his creation if write_date > create_date into ir_model_data. From that point, we can detect every modification made from the Web or GTK interface, and we'll be able to decide if we want to keep custom setting or reload them from new version.

The translation are a bit more particular, because they don't have a "XML ID", neither a create or a write date. We'll probably need to add at least a create and a write date on the ir_translation data model.

The solution to discuss
=================

According to the discussion between me and rvalyi, I expose my point of view about how to handle this problematic. Please make your comments !

From my point of view, there are different kind of model which has to be handled differently by default, but at the end, the user must be able to choose everything (what to keep and what to reload). We have "special model" which are known and could be handled with given rules and all other models which are all handled the same way. Here a list of models and what I suggest for them by default:

Translation : ir_translation
---------------------------------

 * By default, keep user settings for terms which has been changed by the end user. For all other terms (not modified by the user), load the new term from new version.
* Add an option or a way to reload a language from files (server option like --reset-lang=LANG, or a wizard to do that)

Access right and rules : ir_model_access, ir_rules
---------------------------------------------------------------

 * By default, keep user settings : if I say this guy don't have right for that resource, I don't want the system to change that on my next update. If there is new access right in the new version (which are not present into the DB), like on a new object or adding right on a existing object, load it.
 * Add an option or a way to reload all access right from files

Views : ir_ui_view
-----------------------

 * By default, override view custom settings with an "XML ID" from file. This is because you can make an inherit of the view if you want to ensure that this will stay on next update. If you have modified directly the original view, so you accept that it will be reset on the next update.

Workflows : workflow*
-------------------------

 * For that point, I don't know. I think we should keep user settings, but in another hand, if the workflow change, there are probably good reason, so I don't know what is the good solution here.

Others (all other models):
--------------------------------
 * Keep or override user settings according to the "noupdate" tag. In other words, don't change the comportment for those ones.

For all of that, add a way to export all custom settings, selected by model, into a module. This will allow people to export their settings in case they want to reset everything, but want to choose some which need to be kept. We already have a wizard to export custom settings, we may have to improve it a bit.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.