Unlike views, regular data records don't have an XML arch structure and can't be extended using XPath expressions. But they can still be modified to replace values in their fields.
The <record id="x" model="y"> element is actually performing an insert or update operation on the model: if x does not exist, it is created; otherwise, it is updated/written over.
Since records in other modules can be accessed using a <model>.<identifier> identifier, it's perfectly legal for our module to overwrite something that was written before by another module.
As an example, let's change the menu option created by the todo_app module to into My To Do. For that we could add the following to the todo_user/todo_view.xml file:
<!-- Modify menu item -->
<record id="todo_app.menu_todo_task" model="ir.ui.menu">
<field name="name">My To-Do</field>
</record>
<!-- Action to open To-Do Task list -->
<record model="ir.actions.act_window" id="todo_app.action_todo_task">
<field name="context">
{'search_default_filter_my_tasks': True}
</field>
</record>The To-Do application included a record rule to ensure that each task would only be visible to the user that created it. But now, with the addition of the social features, we need the task followers to also have access to them. The social network module does not handle this by itself.
Also, now tasks can have users assigned to them, so it makes more sense to have the access rules to work on the responsible user instead of the user who created the task.
The plan would be the same as we did for the menu item: overwrite the todo_app.todo_task_user_rule to modify the domain_force field to a new value.
Unfortunately this won't work this time. Remember the <data no_update="1"> we used in the security rules XML file: it prevents later write operations on it.
Since updates on that record are being prevented, we need a workaround. That will be to delete that record and add a replacement for it in our module.
To keep things organized, we will create a security/todo_access_rules.xml file and add the following content to it:
<?xml version="1.0" encoding="utf-8"?>
<openerp>
<data noupdate="1">
<delete model="ir.rule" search="[('id', '=',
ref('todo_app.todo_task_user_rule'))]" />
<record id="todo_task_per_user_rule" model="ir.rule">
<field name="name">ToDo Tasks only for owner</field>
<field name="model_id" ref="model_todo_task"/>
<field name="groups" eval="[(4, ref('base.group_user'))]"/>
<field name="domain_force">
['|',('user_id','in', [user.id,False]),
('message_follower_ids','in',[user.partner_id.id])]
</field>
</record>
</data>
</openerp>This finds and deletes the todo_task_user_rule record rule from the todo_app module, and then creates a new todo_task_per_user_rule record rule. The domain filter we will now use makes a task visible to the responsible user user_id, to everyone if the responsible user is not set (equals False), and to all followers. The rule will run in a context where user is available and represents the current session user. The followers are partners, not User objects, so instead of user.id, we need to use user.partner_id.id.
As usual, we must not forget to add the new file to the __openerp__.py descriptor file in the data attribute:
'data': ['todo_view.xml', 'security/todo_access_rules.xml'],
Notice that on module upgrade, the <delete> element will produce an ugly warning message, because the record to delete does not exist anymore. It is not an error and the upgrade will be successful, so we don't need to worry about it.