Hello everyone.
I am brand now to BOB so please forgive me if I missed some threads that cover what I am asking. I did do a search for best practices but I could not find what I am looking for.
Here is the situation. My organization is upgrading from BO 5.1.3 to XI R3.0. This is a very large leap for the organization. Part of it includes granting limited access to users that know little or nothing about BO and creating several access levels for InfoView, Webi and Deski. Previously all BO users were equal with no need to differentiate them.
Our vendor created 5 security levels which follows:
5 Report Readers: View access only in infoview. No editing, scheduling, etc allowed.
4 Report Consumers: View + Refresh
3 Report Writers: View, Refresh, + Write/Modify
2 Power Users: View, Refresh, Write/Modify + Schedule
1 Deski: View, Refresh, Write/Modify, Schedule + Deski access
The problem is that the vendor set the default level that all user accounts are created into at the Power Users level. This default group also grants access to the data. They then deny rights to create level 3-5 and grant additional rights to create level 1. This creates problems because if you deny anything to the default group, then all users are affected. A few sub-admins locked themselves out of their own folders when trying to restrict access to most of their users. Each user in our sub-organizations must be in their default group in order to have access to their data.
That is the background. I am trying to redesign the security from the ground up and I am having difficulty understanding exactly how and why things are done in the CMC. I would prefer to have our security based on unassigned and granted rights with very sparing usage of explicit denials.
I have found a few different approaches that I can take but I’m not sure of the pitfalls in each:
Approach A:
Seperate out the data access group and the security group. Leave the groups as is.
This would be the easiest solution but I’m not sure if it is the right solution. It still leaves in place a denal of rights for access levels 3-5. Also, it could cause problems with our sub admins if them assign a user mistakingly to multiple groups.
Approach B:
Use the default BO access levels. Create 5 groups for our security levels then assign rights to applications based on the groups.
The thing that I don’t like about this approach is that the default BO access levels don’t fit our administrative plan’s security levels.
Approach C:
Create 5 access levels matching our 5 security levels. Create a matching 5 groups and assign users to the groups accordingly. A seperate group will be used to grant access to Data.
This is the route that I prefer but it does not seem to be as cut and dry as I originally thought. It took me days of pounding my head against the wall trying to figure out why my test users could not change their own preferences and passwords until I granted the test group access to itself.
Any input would be greatly appreciated.
CalDoug 
(BOB member since 2009-01-12)
(BOB member since 2007-09-06)