Security - Can someone share ?

Okay - I’ve been charged with coming up wtih a “definitive” security model for our Navision Sales - this is a list of commonly used Roles and permissions (much like that which ships with Navision Currently). I’m resigned to use the “All-NO FORMS” method that Navision recommends. My request (partly out of laziness, partly out of not having a desire to reinvent the wheel) - does anyone have this security model set up already that they’d be willing to share? Obviously it will have to be tweeked to each individiaul clients needs, but it’d be great if someone already had form level security roles pre-definied and were willing to share it with me and probably many others out there. Thanks!

can’t you use the groups from navision. I think that they pretty much covers it. I know that there are a few. But I have seen places, where they wanted security groups based on department. But still then one or more need some extra, ending up with more groups in stead of fewer. //Henrik Helgesen -: KISS::Keep it Simple, Stupid :-

The following is what is suggested by Navision US and is the security model I’d like to follow. This is taken from a Navision US Help docuemnt: 8. For any user that is not assigned the SUPER Role, the Role called ALL should be assigned. The ALL Role has basic object access that every user must possess. Some level of Read access to the Setup Tables and Tabledata and other System areas are required for every Navision user, so the ALL Role is meant to provide this basic access. However, there will be some changes that may need to be made to the ALL Role before fully applying that Role to everyone. In particular, the ALL Role has a line established for “Form 0” with Execute rights set to Yes. The issue is that, in combination with the other Roles that give rights to POST transactions, such as “S&R-Q/O/I/C, POST” and “P&P-Q/O/I/C, POST”, a significant issue in security for some customers will exist. Particularly, out of the box, these “POST” Roles require a line for TableData Object ID 17, which is the G/L entry Table, and Read access set to ‘YES’. This permission access, in combination with the ALL Role line of Form 0 and Table 0, gives this user full access to review the G/L Entry Table and see General Ledger transactions on screen, particularly detailed income and expense transactions. This may be undesirable for some customers and will need to be addressed through some workarounds provided below. To deal with the issue of G/L entry access, you can do one of two things. First, you may need to create a new “ALL Role” called “ALL-NOFORMS”. You will then use the Windows copy function and copy the Permissions lines from the “ALL” Role and paste them into the “ALL-NOFORMS” Role. You will then delete the line for Form 0 - Execute “Yes” from the ALL-NOFORMS. You will then create new Roles for every Functional Area giving the necessary permissions to the individual Forms required for that Functional Area. The second change that the user may want to consider is to modify Codeunit 12 Permissions related to reading the G/L Entry Table. To do this, you will: Access Tools, Object Designer Select Codeunit 12 Select the Design button. Select the Properties icon Click in the Value field of the Permissions line Select the ellipse button (…) On the line for Object ID 17, check the “Read Permission” box Once this is completed, a user can select any of the “POST” Roles listed above and change the “Yes” option in Read Permission for Table 17 – G/L Entry Table data – to “Indirect”. By completing this change, a user will be allowed to Post an Invoice and have the posting process create the new entry in the General Ledger Entry Table. However, by changing the Read Permission to Indirect, the user will not have access to the General Ledger Entry Table from a drill down in the Chart of Accounts Net Change field. Maybe this will clear up some of the confusion regarding my question.