Methodology of creating permissions...?

I would like to know what is Navision methodology of creating user roles and permissions. How this should be done “correctly”?

why don’t you use the navision standar roles? i think it’s the best way to avoid problems…

I need to create roles for new customer objects but these objects uses other standart Navision objects … but the question was … what would be the best way to create them …

Arthur, The debugger code coverage function can be useful for this purpose. It will tell you all of the objects that are being hit during a particular sequence of actions in the application. However, you will still need to eyeball the code to see what permission type (i.e read, modify, delete… etc) that each object needs. And remember (this caught me out) that sometimes you must give the objects themselves permissions not just the roles. For example… look at the permissions defined in the properties of the posting codeunits. Regards, Chris.

This really isn’t a “devlopment issue”, so it really should move to another forum, but… The methodology has to start with the customer. They need first to identify why the modification was made, and then defining the access structure to the data ans functionality. Once this is done, the consultant should work out mapping from this to the clients requirements, and design the Roles based on this. If you are at the point that you need to trace code and look at code to define roles, then it means that you must have completely messed up (dare I say forgot) the actual design process. In any case the Permission roles should be a part of the design document, and should be defined before the programmer even sees the spec.

I have to agree with David, but I will say this though :- What is a design document?!?! [:D] (joke!) Of the NSC’s I’ve worked for (3), never has the design document noted the other standard objects and relative permission required for them. Maybe this is why I’ve always found setting roles & permissions for users a pain in the backside! [:)] So good point David, I will make sure that in future when I spec something, or when I receive a spec, that it includes the standard objects to be accessed. [;)]

Most of my Navision career (13 years) has been spend training NSCs, so normally I am in the position of teaching them rather than using what they have (there are exceptions though). Part of the training I give is that ALL testing and debugging of development MUST be done using the Clients license. The consultant is designing the Permission Roles during testing, to match the original business rule specification. A client receiving a “You do not have permission …” error is NOT acceptable.