Some tips about user rights

Shenpen

Actually I cannot post a 200% working a wholeheartedly recommended hint here, just some experiences - but I hope it helps.

1) Standards roles are not very useful. For example, you have a role to post sales documents - it means you can post both Shipment and Invoice - it is of course ridiculous. You will need to rethink it on projects. Basically, when projects usually run out of schedule, there will be no time to correctly set user rights as everybody is frantically hacking to make Navi at least work, and everybody forgets making some functions not work for some users. So the basic hint is to always plan at least a week for User Rights.

2) Another mistake is that I myself often commited was the "hubris mistake" - thinking as standard roles were not 100% correct we should not use standard roles at all but use the Client Monitor - based tool from mibuso to create roles from scratch. This is also wrong. Actually standard roles don't need so really much modification. Separate posting shipment and invoices, add some security filters to G/L Journals and Item Journals, basically that, not much more. Standards are not SO bad as it would seem.

3) A frequent problem is that standard roles have "0" rights to all objects (form, codeunit etc.) - it means access to all, and have definite roles only for TableData. This is of course not right. F.e. warehouse should use Item Reclass. Journal but in no occasion may use Item Reval. Journal. They both use table Item Journal Line so the only possibility is to take away rights for the specific forms.

A solution is to make a simple processing-only report that generates rights for a role for all objects one by one (just for form, table, codeunit, report, dataport, menusuite and xmlport, not TableData! Generating rights to tabledata is really, really tricky but you don't need to do that as it is covered in standard roles.) Then you can take away easyly the unneeded objects. In this example, the only thing you need to take away is Form Item Reclass. Journal, as everything else is managed by TableData rights in standard roles.

4) Standard roles do not work right in Cronus. F.e. with the basic sales roles you can't make an invoice, because it complains about not being able to read Service Invoice Lines. I think it is a statistical flowfield somewhere. But in a real application, if you don't use CRM - Service there is no problem. If you do use it, give roles with read rights to people who do invoicing.
So, don't test roles in Cronus, test it in the real database.

5) I planned on programming a solution to make Role Groups to easily assing 20-25 roles for 40 users doing the same job, but I found than plain simply copy-paste is doing well So yes, it sounds horrible to assign 20 roles to 40 users but you can copy-paste most of it.