You cannot attach a file to a register although you have write permission over the register model, unless you also have create permission.
Yes this is the design. The resource check the access right of the linked model for the same operation.
Yes, it’s the current design but as I see it we could think of attachments (and notes) as a one2many field that would be part of the current record. If that was the case, what we would expect is that the user would be able to add new records to that o2m if he has write permissions to the record.
Well, it would be a less powerful and flexible design and any way this can be customized.
I agree with Albert: I think that the user usually expects the same behaviour as for one2many fields so it had to be the standard implementation (not a customized one). Why it would be less powerful and flexible design?
Because instead of 3 access rights, there will be only one.
On a second though, I think it is probably the less astonishing behavior to check for ‘write’ access of resource on create and delete. But also that we need an easy way to modify one type of check into another (see Permisos de usuario para archivos adjuntos (GNU Health)).
So I propose that in
Resource.check_access we have a method to convert the
mode per model_name. This method by default will convert
So, the change in http://hg.tryton.org/trytond/file/32cea659fb4e/trytond/ir/resource.py#l74 could be something like this (see the line inserted after #)?
@classmethod def check_access(cls, ids, mode='read'): pool = Pool() ModelAccess = pool.get('ir.model.access') if ((Transaction().user == 0) or not Transaction().context.get('_check_access')): return model_names = set() with Transaction().set_context(_check_access=False): for record in cls.browse(ids): if record.resource: model_names.add(str(record.resource).split(',')) # Check whether model_names have write access to 'write', 'create' or 'delete' an attachment mode = 'write' if mode in ('delete', 'create') else mode for model_name in model_names: ModelAccess.check(model_name, mode=mode)
For me, it should be done via a method that takes also the model_name so it can be easy to extend it and add custom behavior per model.
@ced Hi Cedric, Is there any update on this issue. I am not able to find the code in the review patch on the main branch of v5.0. Please update this at the earliest possible as it is causing lot of problems to us in go-live of our modules.
This is against the stable branch rules. We do not back-port behavior changes on released series.