ir.model.access.csv overwriting set permissions

[jordg]

After setting permissions for groups and users etc. via the client and then updating a module the permissions are overwritten.
This is correct behaviour. However this creates a security issue.

1, Set up company specific permissions via UI.
2, Upgrade module eg. openerp-server -u all
3, Permissions are set back to default
4, Users can access parts of the system that they should not, based on company specific requirements

There seems to be no easy way of retaining these set permissions.
1, We could export to CSV and reload after modules have been updated. This is a bit of work that might get missed on a module upgrade. Who would think to do it?

2, We could create our own module and override the ir.model.access.csv items required. This does not work. There seems to be no mechanism for overriding ir.model.access.csv. What happens is that another identically named line is added to the ir_model_access table. It would be a matter of luck for the new permissions to be parsed before or after the duplicate named permissions.

3, Set all fields and groups of interest by hand in custom module

A solution for this could be to add a mechanism to override the permissions via a module. This will not solve the issue for changes made via the UI. If you updated the modules before you save the permissions you are in an embarrassing situation.
Maybe there could be a flag in configuration (set by default to False) that controls weather permissions are reset or not?

[Olivier Dony (Odoo) (odo-openerp)]

Hi,

You are right when you say that updating a module may reset the permissions that are granted to certain groups.
However this is not very different from what happens with other kind of OpenERP data, such as menus and views:
 - each item (menu, view, access right, ..) is given a unique ID upon creation (the @id attribute in XML), stored in the database too
 - upon module update, all items that were created by a module will be updated to match their new definition, as taken from the module source files, to keep a consistent set of items (even if you had changed them, the new module definition may make your change obsolete)
 - one exception to the previous rule is items that were marked as "noupdate" (e.g. declared in a XML <data noupdate=1> block), and CSV files that were listed in the 'init' or 'init_xml' section of the module manifest (as opposed to those in the 'data' or 'update_xml' sections)
 - it is possible to override any item by defining an item with the same @id attribute in another model (if the @id is different you would simply create another record, as you noticed)

Based on the above, it is perfectly possible to manage permissions in a predictable way:
 - for extra permission, you can simply create new permission lines in the system, they won't be touched during updates (don't check more rights on the same line, you need to add an extra line!)
 - all ir.model.access.csv files that are in the 'init' section of their module manifest will not be reset during an update, so it is relatively safe to update these in the database directly
 - for the rest, you always have the option of overriding the definition of the access right in your own module, simply by using the same "id" value. For example if the 'base' module defines a 'access_ir_cron_user' permission, you can override it in another module by re-defining the same access right with "base.access_ir_cron_user" as the ID.

Some OpenERP modules do declare their access rights in the 'update_xml' or 'data' section of the manifest, because they would like the permissions to be reset upon update. If you think this is an error and don't like to override them in another module, you may report a specific bug report for these cases.

I hope this helps...