Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K 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
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 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
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Permissions and Departments in Role Tailored Client
mgrammatico
Member Posts: 4
Hello Everyone,
I have a few general questions on permissions and departments in the Role Tailored Client.
1. Can departments be hidden based on the permissions set?
My experience with this is no, but maybe I'm doing something wrong. We have been limiting access to table data and that usually allows the user to click the link to any item in any department, but if they don't have access, it fails with a message telling then why they can't access it. We'd love for users to only see what they have access to. Is there any way to accomplish this in RTC?
2. If the answer to question 1 above is no, is there any value then in allowing access to table data, but preventing access only to the pages we do not want the user to see. The result seems to be a similar error message stating the page that can't be accessed instead of the table data and as far as I can tell this prevents users from unintended access to screens and processes that were restricted to by getting in different way and unintended restrictions to their assigned functions and tasks. Is this a good approach? What is the downside? Is there a better way?
Thanks in advance for your comments.
Regards,
Marc
I have a few general questions on permissions and departments in the Role Tailored Client.
1. Can departments be hidden based on the permissions set?
My experience with this is no, but maybe I'm doing something wrong. We have been limiting access to table data and that usually allows the user to click the link to any item in any department, but if they don't have access, it fails with a message telling then why they can't access it. We'd love for users to only see what they have access to. Is there any way to accomplish this in RTC?
2. If the answer to question 1 above is no, is there any value then in allowing access to table data, but preventing access only to the pages we do not want the user to see. The result seems to be a similar error message stating the page that can't be accessed instead of the table data and as far as I can tell this prevents users from unintended access to screens and processes that were restricted to by getting in different way and unintended restrictions to their assigned functions and tasks. Is this a good approach? What is the downside? Is there a better way?
Thanks in advance for your comments.
Regards,
Marc
0
Comments
In response to 2, generally I think you should deny access to both page and data. If you want to prevent a user from performing an action, the most secure approach is to deny access to both the page which exposes the action and the underlying table data. I would describe this as defense in depth. Your question is really about how to show the user the right thing rather than security, and in RTC there is no relation between permissions and what parts of the UI are displayed.
If two pages manipulate the same table, but one performs stronger validation, it may be useful to prevent some users from accessing the page with weaker validation. In this case, there is value in the user having access to the table but not the (weaker) page. This situation, however, should be avoided in the first place.
Alex