User Rights Management - Revisited

kirtangor

Hello All,

I am again re-iterating one thing I don't like about NAV's user right setup - it is a really long, cumbersome, and an unmanaged process. I am thinking of creating a small module which will allow the user to give rights based on forms.

Every user will be having the role of SUPER, but the customization which I'll do will prevent the user to view the forms/reports whose rights are not assigned to him.

I will be writing a codeunit for fetching the roles and permissions from the custom table whose schema will be like this -

Role ID    Object Type    Object ID    Create    Read    Update    Delete
========================================================================================
R1         Form           18            Y        Y        Y         N
R2         Form           18            N        Y        N         N

Then, based on the roles assigned, I'll enable/disable the InsertAllowed, ModifyAllowed, and DeleteAllowed properties of the form after calling this codeunit which will return me the permissions for the form for the current user's role. If the role doesn't have read rights, the form will show an error indicating the same.

The main glitch in doing this is that, I will have to write the code on *EVERY* form. Is there an easy way to achieve this? I tried attaching a breakpoint to ApplicationManagement codeunit, but NO, it doesn't get hit everytime a form opens. If only I could tap into NAV when a form opens, I'll be able to do it. I also thought of using COM, but then it would become very lengthy and testing it would be too hard. Moreover it won't work with the Role Tailored Client.

EDIT: I am using NAV 2009 Classic.

pdj

kirtangor wrote:

The main glitch in doing this is that, I will have to write the code on *EVERY* form.

Not really. That could be solved by exporting all forms in txt-format, and than making some code that modifies the file by adding your code.
The real "glitch" however; is that you don't have access to InsertAllowed, ModifyAllowed, and DeleteAllowed properties from C/AL...

DenSter

I think the real glitch is an unwillingness to learn to use the existing security system

pdj

Well, might be, but it is very easy to have some rather simple security requirements that would be a lot easier with this kind of configuration possible.

Let's say a client with a Native DB will allow a group of users to be able to create Sales Quotes, but only being able to read Sales Orders and Sales Invoices. How will you achive that without coding?

Regarding the missing properties in C/AL, then I guess it could be handled by putting code in the different OnSomething triggers on the form. It would just end up being a lot of awfull code in a lot of places in every single form. Wouldn't recommend it for sure, but it would be possible...

David_Singleton

Kirtangor, why don't you just contact Lanham and sell their form level security module to your clients. Trust me they have been doing it for years and know how to do it properly.

kirtangor

pdj wrote:

That could be solved by exporting all forms in txt-format, and than making some code that modifies the file by adding your code.

I was thinking of writing a .NET app which will read the objects, and modify them accordingly. But now, it won't be possible. Read the next line

pdj wrote:

The real "glitch" however; is that you don't have access to InsertAllowed, ModifyAllowed, and DeleteAllowed properties from C/AL...

Hmmm. I never tried that. Thanks for mentioning it #-oAnd yes, we don't want to write unnecessary awful code on all the forms (on onSomething triggers), as you mentioned.

DenSter wrote:

I think the real glitch is an unwillingness to learn to use the existing security system

DenSter, I already know how to use the existing security system. But, we have to provide rights to the users on the basis of *folders*, not forms. This is where the problem comes in. Creating the roles, then giving them permissions on the basis of folders is a very cumbersome and time taking process. It means that we have to give CRUD rights to the forms contained in a particular folder. If you can think of any ideas of how to do it, feel free to reply.

David Singleton wrote:

why don't you just contact Lanham and sell their form level security module to your clients. Trust me they have been doing it for years and know how to do it properly.

David, I searched Lanham on Google, and came up with one Mary Lanham. Are you referring to her? Can you give me some information on how to contact him/her?

EDIT: Hi David, I guess I got them - Lanham Associates & Security Management. But they haven't mentioned any form level security module on their website. Can you provide me the correct link?

kriki

[Topic moved from 'NAV 2009' forum to 'NAV/Navision' forum]

DenSter

kirtangor wrote:

we have to provide rights to the users on the basis of *folders*, not forms. This is where the problem comes in. Creating the roles, then giving them permissions on the basis of folders is a very cumbersome and time taking process. It means that we have to give CRUD rights to the forms contained in a particular folder.

I guess I just have no clue what you mean by 'folders'

kirtangor

DenSter wrote:

I guess I just have no clue what you mean by 'folders'

Hello Daniel,

I'll give an example and explain. In Financial Management, we are having "General Ledger", "Cash Management", "Receivables", "Payables", and "Setup" folders. Now, only a higher authority in the Finance department will have full access to the "Setup" folder, whereas some of the users will have a read-only access to all the items in that folder. We have to create the permissions based on the items contained in a folder.

Moreover, there will be many forms which will be appearing in more than one folder, for e.g. "Vendors" form in the Purchase module. It comes under "Planning" and "Order Processing" both. You can safely ignore such cases, I just want to know how you or any of the members at Mibuso would go with designing permissions for this scenario. We have discussed and exhausted many ways of doing this. For e.g. We created 3 roles per folder - Read Folder, Write Folder & Delete Folder. If a user has permission to read/write for the items in a particular folder, he/she is given the read/write folder permissions. But this way has its own disadvantages, it becomes unmanageable, etc.

EDIT: Hi Alain, I had posted this question in NAV 2009 forum, because I am using NAV 2009; I just forgot to mention it in the question :oops:

garak

Did you use the "Default" MenuSuite :?:
Some customers of mine has the same problem / question.
Do we created a complex "User Rights Setup" and new MenuSuites.
The new Roles (on forms) we set to the useres and in the "Navigation Pane Designer" we set, which user can use this Pane.

It's true, that it is a hard work to define the roles and to define and assign the MenuPane.
A other method is to create a "new Setup Permissions Module", where you define which user can open / read / write the forms / controls / filters.
Like the Lanham solution. But this is also a hard work

Regards

garak

And why do you want to set the permissions to the folder?
If the user has the permissions to run the vendor card, you can't handle if it is run from the "Finance Management Pane" or from the "Purchase Pane". There is not event fired that you can handle with standard C/AL code.

So use the system secutiry model or a solution like the Lanham module.

Regards

DenSter

kirtangor wrote:

I just want to know how you or any of the members at Mibuso would go with designing permissions for this scenario

As you already know, you can't set permissions to those folders, only for individual selections, and the objects that they represent. I would not even attempt to create a subsystem for the folders (since that makes no sense to me at all), but instead I would document the objects that are included and create roles for each folder with permissions for those objects. Now all you need to do is assign it to the users. It will take massive amounts of time though (as you've already found out).

Why doesn't it make sense? That's a good question, so glad you asked . To me it doesn't make a damn bit of difference whether the Item Card is on one menu or another, any given user should have certain permissions to it. By setting that on the tabledata level, you take care of all forms that are used by that table, regardless of which folder they are in. Much easier to manage, yes?

kirtangor

Thanks for your reply, Daniel. And Rene, can you please give me the link to the Lanham's Form Security module you are talking about, because I couldn't find it (as you can see a few posts above).

DenSter

The Lanham addon won't do you any good, because you won't see the folders either.

garak

DenSter wrote:

The Lanham addon won't do you any good, because you won't see the folders either.

Thats true, as i can see (from the pdf and product documentation) it's handles the forms, but not from where they are comming.

kirtangor

Rene & Daniel,

Thanks for the quick responses; it would be really helpful if you can provide me with the link for that product. I completely understand that it is based on forms. I'd like to give it a try and work out some different way of achieving this.

If I am not wrong, the tool can be used to provide rights to forms directly instead of TableData. If this is the case, then it will be helpful if I can download it and try it out. If it works, then we can get the license for the same.

garak

http://www.lanhamassoc.com/securitymgmt.htm

you can't download it. Maybe Lanham offers a WebCast so you can see how it works.
Call the Lanham office

kriki

kirtangor wrote:

EDIT: Hi Alain, I had posted this question in NAV 2009 forum, because I am using NAV 2009; I just forgot to mention it in the question :oops:

The reason I moved it to the NAV/Navision forum is that we changed the 'functionality' of the NAV 2009 forum. If it is about NAV2009 but it 'standard NAV', it goes in NAV/Navision. If it is about the new technologies of NAV2009, then it is for NAV2009.
This seemed more logical to us.