Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Important Solution to Assigning Permissions!!
knight
Member Posts: 45
To whom it may concern,
I just have a comment to make on the issue of assigning indirect permissions or permissions via objects exclusively.
Lets just say for example, that I have a user who is allowed to go into the Salesperson Form and they are only allowed to insert a new Salesperson via a particular piece of code in a codeunit, as opposed to being able to just press F3 and insert a new one.
From my knowledge and the knowledge of other technical resources, we were under the assumption that you could use two different methods to get around this.
Firstly, we thought that if we gave the user Indirect permission (via a User Role) to Insert into table 13 Salesperson/Purchaser then they should be able to insert a new record via the codeunit which inserts a new salesperson record itself. This is because it is our understanding that if you give a person an indirect permission, it means that they themselves can't do it (eg. Inserting by pressing F3), but they can via code (eg. rSalesperson.INSERT). Despite this assumption, giving them Indirect permission will not overcome this particular problem.
The second way we may have thought to overcome this problem, is to explicitly go to the properties of the codeunit itself, and give full permissions (including insert permission) to table 13 so that hopefully anyone who uses that codeunit should be able to insert a new record into table 13 via any code in the codeunit. However this too does not work.
Only after thorough testing have I discovered it is only TOGETHER that these actions have any effect. Eg. If I give the user Indirect access to Insert into Table 13 AND also give the Codeunit (which has the INSERT code in it) explicit Insert permission into Table 13, that the user will be allowed to insert a record via the codeunit, but not via any other area.
This may perhaps already be known to yourself, but this has been a problem for me and other technical resources for quite a while. As such, I decided that it would be a good idea to make this solution known so that other technical resources do not get bogged down by this issue any longer. Hopefully the information is of use.
Thanks.
:idea: :idea: :idea:
I just have a comment to make on the issue of assigning indirect permissions or permissions via objects exclusively.
Lets just say for example, that I have a user who is allowed to go into the Salesperson Form and they are only allowed to insert a new Salesperson via a particular piece of code in a codeunit, as opposed to being able to just press F3 and insert a new one.
From my knowledge and the knowledge of other technical resources, we were under the assumption that you could use two different methods to get around this.
Firstly, we thought that if we gave the user Indirect permission (via a User Role) to Insert into table 13 Salesperson/Purchaser then they should be able to insert a new record via the codeunit which inserts a new salesperson record itself. This is because it is our understanding that if you give a person an indirect permission, it means that they themselves can't do it (eg. Inserting by pressing F3), but they can via code (eg. rSalesperson.INSERT). Despite this assumption, giving them Indirect permission will not overcome this particular problem.
The second way we may have thought to overcome this problem, is to explicitly go to the properties of the codeunit itself, and give full permissions (including insert permission) to table 13 so that hopefully anyone who uses that codeunit should be able to insert a new record into table 13 via any code in the codeunit. However this too does not work.
Only after thorough testing have I discovered it is only TOGETHER that these actions have any effect. Eg. If I give the user Indirect access to Insert into Table 13 AND also give the Codeunit (which has the INSERT code in it) explicit Insert permission into Table 13, that the user will be allowed to insert a record via the codeunit, but not via any other area.
This may perhaps already be known to yourself, but this has been a problem for me and other technical resources for quite a while. As such, I decided that it would be a good idea to make this solution known so that other technical resources do not get bogged down by this issue any longer. Hopefully the information is of use.
Thanks.
:idea: :idea: :idea:
0