Possible to have ACL's on specific purchase orders, quotes, etc? (i.e. restrict to own user or own group?)

Using my Dolibarr
1

It seems like in the permissions of the default Dolibarr (v13.0) ACL is all or none for Purchase Order?

That is, a user/group either has no access to view PO’s, or they have full access to view every PO?

Example… we may not want “Maintenance” department/group to see purchase order history of “Raw Materials” department/group since neither group needs access to view/update each others PO’s or purchasing history.

Is it possible to set up access like this with stock Dolibarr?

Or is there a plugin that would help?

Thanks

2

If you extended the access to third parties to all users in the permissions section, everyone can see all the purchase orders (or supplier orders, etc.) The only possibility is to revoque this permission and assign the third parties to the users you want to see their orders, and not to the other users of your company.

The problem is that Dolibarr cannot do this with user groups (or I have not idea to do so) and you have to assign the third parties manually to all the users you want to see their purchase orders.

3

I may have explained it wrong.

I want some users to be able to ONLY see their own PO’s which they’ve created.

In this view:
/fourn/commande/list.php?mainmenu=commercial&leftmenu=orders_suppliers

it will show the full list of Purchase Orders (if you have access)

  • We dont mind for all our users to see all of our 3rd parties / vendors
  • We only want to restrict Purchase Order view to users own created/initiated PO’s

I look a little around dolibarr code to see if I can just write a quick check to filter on users own PO’s or not (show all), but it is quite overwhelming at first… 250 tables with basic install. Only Thrid parties, contracts, vendors, commercial proposals and LDAP enabled.

4

Digging around code a little more… I think maybe it’s not too large of a task. I think good approach could be:

  • Create a GROUP called “RestrictedViews”
  • Add users to this group who we wish to only read document objects where they are the fk_user_author

Then for each type of document object (i.e. purchase order) in the function where the table rows are being SELECTED for listing/displaying the the user, we first perform a check if $this_user_id is member of $group_RestrictedViews then instead of pulling all of the rows from the table, we add WHERE fk_user_author = $this_user_id

This is basic concept of “easy” way.

Of course more things to consider and add ACL check wrapper around like functions where the restricted user can update, delete, etc. but seems straightforward.

If this were a module, I guess the module setup values would ask:

Group name of users restricted to their own objects/documents: [ select groupname ]
Document types/Objects to restrict:
[ ] Purchase Order Read
[ ] Purchase Order Update
[ ] Purchase Order Delete

[ ] Vendor Invoice Read
[ ] Vendor Invoice Update
[ ] Vendor Invoice Delete

It gets more tricky with vendor invoice, because I think typically an administrative/secretary person (with full unrestricted access to the Commerce and Billing/Payment modules) will be opening bills from vendors, and entering them into the system (so that person becomes $fk_user_author for the INVOICE object in dolibarr) but actually the PO linked to that invoice was authored by someone who is restrictedView and good for that person to see that invoice as well.

So with vendor invoices ACL check it is probably good to use the linked PO $fk_user_author for the ACL actions rather than the $fk_user_author on the invoice itself.

Very impressed with the Dolibarr documentation. This helps point someone in right direction to create such a module:

This shows the purchase order list… where fk_user_author is user id# of original creator:

doli-acl1
doli-acl11489×233 24 KB

This shows the invoice list, also fk_user_author also exists here, but as mentioned above, because a 3rd person who is opening bills, scanning documents, and making (authoring) invoice records… maybe it is better we look at the linked fk_user_author of the linked PO to determine if invoice(s) will be able to be shown to user or not…
doli-acl2

5

But what is best approach to hack / add-on to a default dolibarr module like this? Probably can modify the code directly @
htdocs/fourn/class/fournisseur.commande.class.php for purchase orders
and
htdocs/fourn/class/fournisseur.facture.class.php for invoices

but then it is difficult to maintain and needs to be reapplied every update.

6

After this thread and due to lack of responses over 1 month, I have decided to try a different ERP which can handle these things “easily”, but the configuration becomes inifnitly more complex – it is not an easy alternative at all and has many complexities which we dont need and get in way of what we do need. I really wanted to use Dolibarr because it’s written in PHP and clean/easy compared to other open source ERP solutions out there. The UI is great, the software is very fast. Really like it.

Lack of this ACL function/feature is just a dealbreaker for us unfortunately. The business does not want every user who can draft a PO (i.e. a maintenance person ordering batteries) to be able to see every purchase made within the organization (i.e. quantities, part numbers, and suppliers of all of our raw materials) as those are protected trade secrets which could be used to figure out formulas and such.

Hopefully Dolibarr will consider this thread and the feasability of implementing some variation of the suggestions above. I think there is probably some way to do it fairly easily if we are restricting views only to users own and/or their own group.

Unfortunately for me, switching between ERP’s is not as easy as something like switching between Netflix and Hulu. I’m sure everyone knows a huge investment of time can be involved in initial implementations and configuration – and migrations to different software/systems are not something to be taken lightly or on a whim. Sad to have to give up on Dolibarr. Good luck.

7

Hello Jays, Your approach of checking fk_user = current user look like a nice approach. There are developers available for diffent country’s. Check here: List of Dolibarr partners and providers - Dolibarr ERP CRM Wiki

Or you can do it yourself and update this piece of sourcecode every update until your proposal have been implemented.
Wouldn’t be nice if this is a dealbreaker.

1 Like