[7.0] When create Note. Access check for read, before write.

I am tested on http://7-0-26703.runbot.openerp.com/?db=7-0-26703-all it not work too if you login Demo Demo

In version openerp_7.0-20131125-002431 Note work right

Any workaround for that?

That bug does not occur when user does not have a single note category - when saving with undefined, it is working well.

Mariusz Mizgier (mariusz-mizgier) you absolute right.

Module note, note.py, line~ 82.

If your create Note with stage, function _get_default_stage_id return first stage.
But note not create yet and access rule say "access denied".

Why get first stage? Because before if you add new note and you have some stages but you not set stage manual when create note, system put note to "undefined" stage. And it way to can't show Note.
After sometime, add new futures - it possible show new note with "undefined" stage in first stage.
It works. Onetime it stop working.
But you remember we have possible show note with "undefined" stage.

If some change
    def _get_default_stage_id(self,cr,uid,context=None):
        ids = self.pool.get('note.stage').search(cr,uid,[('user_id','=',uid)], context=context)
        #return ids and ids[0] or False
        return False
 Now create new note with "undefined" stage, save that. After you can change stage what you wont.

Second part.

When note create some function from email check followers, but we have access rule

  <record id="note_note_rule_global" model="ir.rule">
    <field name="name">Only followers can access a sticky notes</field>
    <field model="ir.model" ref="model_note_note" name="model_id"/>
    <field name="domain_force">[('message_follower_ids','=',user.partner_id.id)]</field>
    <field eval="True" name="global"/>
    <field eval="1" name="perm_unlink"/>
    <field eval="0" name="perm_write"/>
    <field eval="1" name="perm_read"/>
    <field eval="0" name="perm_create"/>
  </record>

it can't add note without error Access check.
What need.
Need add create. It add follower for new note before system check follower for new note.

note.py for class note_note(osv.osv):

    def create(self, cr, uid, vals, context=None):

        new_id = super(note_note, self).create(cr, uid, vals, context=context)

        res_users_obj = self.pool.get('res.users')
        res_users_ids = res_users_obj.read(cr, uid, uid, ['partner_id'], context=None)

        if res_users_ids:

            partner_id_print = res_users_ids['partner_id'][0]
            res_follower_obj = self.pool.get('mail.followers')

            res_follower_id = res_follower_obj.create(cr, uid,
            { 'res_model': 'note.note',
              'res_id' : new_id,
              'partner_id': partner_id_print ,
            })

        return new_id

But now we have problem with access to mail.follower. Temporary need grand access for creat to ( mail.followers.al , mail.followers.user)

Hello,

This issue was created because we have restricted the permissions to subscribe on a mail.thread object (cf revision 9733 addons 7.0) to add the access_rules.

The problem with this behaviour is that note.note has a record.rule based on followers. When subscribing the author to the note, the read access rules are checked (and not met yet).

To avoid this we now make sure the subscribers are added before the verification of rules and make sure we trigger the create access rule and not the read rule when subscribing.

We are not happy about the context hack but as long as we do not have a proper way to see the operations we have no other choices if we want to keep a security verification at the record level (which is better than the previous one at the model level).

Regards

revno: 9812 [merge]
revision-id: <email address hidden>

This fix doesn't work (at least for us) - still getting a (Document type: Note, Operation: read) error.

Sorry, I meant (Document type: Note, Operation: write)

Hello,

The write rule should not be triggered at creation (read and create only).
Could you give us a way to reproduce your issue ? It seems to work fine on my side.

User which is not a superuser tries to create a new note - no matter if the stage for the note is defined or not. After trying to add from kanban view, new window is opened with Create:undefined - after trying to save he is receiving a message which was posted earlier. Full error stack:
2014-02-06 13:00:33,621 9626 WARNING currenda openerp.osv.orm: Access Denied by record rules for operation: write, uid: 119, model: note.note
2014-02-06 13:00:33,622 9626 ERROR currenda openerp.netsvc: Access Denied
The requested operation cannot be completed due to security restrictions. Please contact your system administrator.

(Document type: Note, Operation: write)
Traceback (most recent call last):
  File "/opt/openerp/server/openerp/netsvc.py", line 292, in dispatch_rpc
    result = ExportService.getService(service_name).dispatch(method, params)
  File "/opt/openerp/server/openerp/service/web_services.py", line 626, in dispatch
    res = fn(db, uid, *params)
  File "/opt/openerp/server/openerp/osv/osv.py", line 188, in execute_kw
    return self.execute(db, uid, obj, method, *args, **kw or {})
  File "/opt/openerp/server/openerp/osv/osv.py", line 144, in wrapper
    raise except_osv(inst.name, inst.value)
except_osv: (u'Access Denied', u'The requested operation cannot be completed due to security restrictions. Please contact your system administrator.\n\n(Document type: Note, Operation: write)')

I've tried removing checking rule for note.note at write - that gives Operation: create. After removing validation on create, it is coming back to Operation: read.

I am sorry but I don't have this behaviour. Already the step "After trying to add from kanban view, new window is opened with Create:undefined" (when creating from kanban view, I don't have this Create:undefined).

Moreover record rules for the write operation do not apply for note.note (only ir.mode.access where it is allowed for Human Resources / Employee).

Have you done some customisation in the rules ? Can you reproduce this on runbot.openerp.com ?
Don't forget to use an up to date version of openerp as well (we have recently changed the osv/osv.py file to give a more informative traceback)

If you have changed the record rule to be verified for write operation, please try to apply the following patch.

I guess my installation might be broken somehow - I need to restore my production database onto other server, as I can't check it during working hours there. After applying your patch though, I got an error of:
2014-02-06 14:02:53,009 10582 WARNING currenda openerp.osv.orm: Access Denied by record rules for operation: create, uid: 119, model: note.note
2014-02-06 14:02:53,014 10582 WARNING currenda openerp.osv.orm: Access Denied by record rules for operation: read, uid: 119, model: note.note
2014-02-06 14:02:53,014 10582 ERROR currenda openerp.netsvc: Access Denied
The requested operation cannot be completed due to security restrictions. Please contact your system administrator.

(Document type: Note, Operation: read)
Traceback (most recent call last):
  File "/opt/openerp/server/openerp/netsvc.py", line 292, in dispatch_rpc
    result = ExportService.getService(service_name).dispatch(method, params)
  File "/opt/openerp/server/openerp/service/web_services.py", line 626, in dispatch
    res = fn(db, uid, *params)
  File "/opt/openerp/server/openerp/osv/osv.py", line 188, in execute_kw
    return self.execute(db, uid, obj, method, *args, **kw or {})
  File "/opt/openerp/server/openerp/osv/osv.py", line 144, in wrapper
    raise except_osv(inst.name, inst.value)
except_osv: (u'Access Denied', u'The requested operation cannot be completed due to security restrictions. Please contact your system administrator.\n\n(Document type: Note, Operation: read)')

And on the users' side (Document type: Note, Operation: read)

Please check your security rules. As for the write operation, the create operation has no record rules applying and you should not get an Access Denied for this operation.

Also to know at which step you had the error, please update your server (at least revision 5192).

That's the most recent stack after upgrading the server:

2014-02-06 14:41:35,386 10952 WARNING currenda openerp.osv.orm: Access Denied by record rules for operation: create, uid: 119, model: note.note
2014-02-06 14:41:35,388 10952 WARNING currenda openerp.osv.orm: Access Denied by record rules for operation: read, uid: 119, model: note.note
2014-02-06 14:41:35,389 10952 ERROR currenda openerp.netsvc: Access Denied
The requested operation cannot be completed due to security restrictions. Please contact your system administrator.

(Document type: Note, Operation: read)
Traceback (most recent call last):
  File "/opt/openerp/server/openerp/netsvc.py", line 292, in dispatch_rpc
    result = ExportService.getService(service_name).dispatch(method, params)
  File "/opt/openerp/server/openerp/service/web_services.py", line 626, in dispatch
    res = fn(db, uid, *params)
  File "/opt/openerp/server/openerp/osv/osv.py", line 190, in execute_kw
    return self.execute(db, uid, obj, method, *args, **kw or {})
  File "/opt/openerp/server/openerp/osv/osv.py", line 132, in wrapper
    return f(self, dbname, *args, **kwargs)
  File "/opt/openerp/server/openerp/osv/osv.py", line 199, in execute
    res = self.execute_cr(cr, uid, obj, method, *args, **kw)
  File "/opt/openerp/addons/audittrail/audittrail.py", line 514, in execute_cr
    return fct_src(cr, uid, model, method, *args, **kw)
  File "/opt/openerp/server/openerp/osv/osv.py", line 187, in execute_cr
    return getattr(object, method)(cr, uid, *args, **kw)
  File "/opt/openerp/addons/mail/mail_thread.py", line 250, in create
    thread_id = super(mail_thread, self).create(cr, uid, values, context=context_operation)
  File "/opt/openerp/server/openerp/osv/orm.py", line 4492, in create
    result += self._columns[field].set(cr, self, id_new, field, vals[field], user, rel_context) or []
  File "/opt/openerp/server/openerp/osv/fields.py", line 1156, in set
    self._fnct_inv(obj, cr, user, id, name, value, self._fnct_inv_arg, context)
  File "/opt/openerp/addons/note/note.py", line 89, in _set_stage_per_user
    stage_ids = [value] + [stage.id for stage in note.stage_ids if stage.user_id.id != uid ]
  File "/opt/openerp/server/openerp/osv/orm.py", line 497, in __getattr__
    return self[name]
  File "/opt/openerp/server/openerp/osv/orm.py", line 405, in __getitem__
    field_values = self._table.read(self._cr, self._uid, ids, field_names, context=self._context, load="_classic_write")
  File "/opt/openerp/server/openerp/osv/orm.py", line 3625, in read
    result = self._read_flat(cr, user, select, fields, context, load)
  File "/opt/openerp/server/openerp/osv/orm.py", line 3683, in _read_flat
    self.check_access_rule(cr, user, ids, 'read', context=context)
  File "/opt/openerp/server/openerp/osv/orm.py", line 3935, in check_access_rule
    self._check_record_rules_result_count(cr, uid, sub_ids, returned_ids, operation, context=context)
  File "/opt/openerp/server/openerp/osv/orm.py", line 3884, in _check_record_rules_result_count
    (self._description, operation))
except_osv: (u'Access Denied', u'The requested operation cannot be completed due to security restrictions. Please contact your system admin...

Solved to me:

http://bazaar.launchpad.net/~openerp-dev/openobject-addons/7.0-opw-603482-msh/revision/9800

@Miguel: are you telling the merged patch does not solve your issue as well ?
We want to avoid using superuser_id if other choices.

After more research I may I find a reason why you would still get errors. The 'stage_id' had the same priority as 'message_follower_ids' field so could be executed after the first one. Setting a priority of -10 (lower the more important, default 0) makes sure it won't happen again,

revno: 9822
revision-id: <email address hidden>

If you still have issues after this merge, please provide a way to reproduce it on a clean database (or runbot).

Regards