I want to restrict some users to only update a few fields in a model and only for certain records. The last part is fixed by adding a record_rule. In this case only the records where the user is added to are shown. The first part is more tricky. For that I created a new group, added the user to it and started testing. So far I was able to make the whole model readonly. The user is also allowed to click on some buttons which I also get working. The only problem I’m facing is that I want to allow the user to fill a comments field. But the whole model is readonly, so I thought maybe I can use the Access Field to add the field to it with read / write properties, but that was too easy and didn’t work.
You should allow the group to write to the model but you should create an write access rule for the fields that you want to restrict updating. With this setup only the users from the group will be allowed to write on that fields.
But if it is only about adding comments, why not use a different model to store comments?
Or use a wizard to append a comment without having access to the model.
After I created this topic I gave the opposite a try. So adding write access to the model and then add all the fields which should be readonly in to the access field made it work.
Personally I find this a bit strange, because in my mind you should restrict the complete model as much as possible and then allow certain fields to have rights which are more loose. This idea is also more in line with the buttons. Because, now my workflow buttons are all available to the user and the user get warnings about it. In my first situations only the button allowed were available the rest was greyed out. And yes I know, you can hide the buttons in the code, so no big deal, but … imagine that somebody else installs your module and want to restrict access.
There are more fields and I want to keep things simple and IMO this can be done by access rights (almost there).
So in all, I expected that the Access Field was higher in the ‘rights-hierarchy’ then the Model Access which means that Access Field can override the Model Access.
You’re right, didn’t think that way. From that standpoint it is obvious.
If you are the developer of the model you can redesign things, but what if you aren’t? Then you have to do it with access rights. Also different companies have different needs for access. Some want to restrict everything, others don’t care. And why have Tryton the possibility to make complex access rights but I’m discouraged to do that
That said, It makes completely sense to me now and the access rights are not complex. So I’m staying with my model design and use the access rights.
