← Back to team overview

openerp-india team mailing list archive

[Bug 944561] Re: ir.model.access.csv overwriting set permissions

 

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...

** Changed in: openobject-server
       Status: New => Invalid

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/944561

Title:
  ir.model.access.csv overwriting set permissions

Status in OpenERP Server:
  Invalid

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/944561/+subscriptions


Follow ups