Hi, I’m struggling a lot trying to set up record access permissions in Tryton. I need to allow users to create private purchases, this is needed for situations where employees request some personal stuff, such as office material, phones, PCs… And also some sensible operations which can create a big impact on the company, sometimes those records must only be available for the user requesting such material, and the users in charge of managing such purchase/project.
So, by setting record rules on purchases, I’ve noticed that if you open a list view with a Many2One, to purchase.purchase, and any of those purchases are not meant to be seen by this user, the entire view crashes showing #ERROR on each record, so I added record permissions also for those kind of models, like purchase.line, but then, as some purchase lines are now private, the same happens with stock moves. So now I have so many models, standard and custom ones, which I have to control when they have any kind of relation to purchases, lines, moves… and any of them can also add more models to the list.
Has anyone set up a properly working record access permission in Tryton? I’m unable to create a simple working design without breaking any part of the program, and maybe, is there any better solutions for this need?
What you describe is far from being a simple design.
Record rules are always complexe to setup. It is better to implement requirements without relying on it.
When ever possible it is simpler to implement such limitation with validation workflow and access per group.
Well, thats right. The main issue is that it was a simple design at first, as I clearly didn’t think about everything which should be done, then I started applying some workarounds for a few problems but I wanted to re-design everything without complicating it so much
Sorry, I don’t understand what do you mean by this, do you mean that it is better to create something like a different model for this situations and just setting up model permissions?
I did not mention it but that is exactly what we use, in the purchase.requisition model is where I let the user decide if this record should be private, if so, the record can only be seen by this users from this user department, and the purchasing department, then the restriction is extended to the generated purchase requests, purchases….
Do you think it’s a good idea to set up a different company, config some users to use both companies, and create the private records on the second company?
I do not see why “Purchase Requisition” would not work out of the box for your needs.
It has already rules to let employees only see their own requisitions and the requisition/purchase group to access all of them.
As I said before, I already use that module, and yes, requisitions are fine, but what about all the other records that comes after a requisition? I have given read access to purchases to many groups, for a few reasons like an approval workflow that I have set, so sometimes I need to restrict the access for all the users which are not from “Purchase”, “Account” or “Stock” groups.
At first I only cared about restricting the access to purchases, but then I got asked to hide every single record related to those cases (lines, moves…).
I really do not understand your problem. I think the requirements are not clearly defined.
But in general restricting read access to something force to remove also the access to any other things that may be linked to it. So you must clearly define sets that can never overlap.
Good luck because I think your requirements are over engineered for no good reasons.
Even if a requisition is private, it their purchase should be managed by someone else (the purchase user) and the invoice should be managed by the accounting users.
You can not hide such details to other grups as they will need to work on them. Otherwise, you need to create a group that manages “Private Purchases” and another that manages “Non private purchases”. But again, you can not hide such purchases for accouting groups, because the user receiving the supplier invoice will never know if the purchase is private or not. So the accounting user needs to see all purchases. Same for stock user, when you receive the product in the warehouse you do not now if this is something “private” or “non-private”.
I already have 2 layers of permissions, users from groups like Purchase, Account, Stock… can always see every record even if it has been marked as private, because of course they will need to work on it, but there is also other groups, for example engineers, which I have given access to purchases, because they actually need it, but only in certain cases, they do not.
Probably I did not explain it the best way. The root of the problem is: some users told me that they don’t want other users to see what are they requesting, and what’s being bought for them, after explaining that there is already some privacity on the requisitions, and it should not matter if other people can see the purchase, the answer was “No”, because they had some kind of conflicts watching eachother stuff, and there is also situations where one purchase by itself is sensible data for the company. So I need the solve this problem, and the record access was my choice.
Indeed I already have it working before creating this post, but I had to apply many fixes after deploying it, and after reaching a stable point, I’ve started thinking that my design was way more complex than it should be, but couldn’t find a simpler solution, that’s the reason I decided to ask.
not in any case. The GDPR and the national labour laws define rules for privacy of employees. E.g. in companies with many employees we have usually the requirement, that the home address, personal phone number, email of employees should not be shown to any user of the system, but only the management / HR.
I think you may solve the problem by just removing the access to other groups to the menu purchase entry but keeping the access to the purchases (and normally beeing just readonly).
This way the user may see the details of his purchases from the requsition menu (where the filter is already applied) and does not have any access to other purhcases.
For me that is a good idea, that we actually discussed, it got discarded because there was still some other ways like to see “private” records like the purchase line relate from products, but I’m still wondering if I should care about leaving some “open doors”.
From everything that has been said in this topic I already got that it is almost impossible to make the privacity 100% reliable in the software without adding much complexity, and as we are not talking about legal stuff, the proper approach must be a 50/50 between the system no letting you see some things, and the user being responsible of not trying to find ways to avoid the restrictions.
You can close as much doors as you want. For example if you do want to hide the relates for users that are not for the purchase group just restrict the action to those groups to close the doors.
This is a little more of work because tryton by default relies on model access to filter which actions are available but you can customize that if really needed.