Hitachi Consulting BI Blog

Where’s the beef? (eh, permissions?), Part 1

I created roles, added users and groups to the roles, and then using the Role Designer granted permissions to the roles. For curiosity’s sake, I then decided to look at the roles’ XML. When I viewed the .role XML files I found the users and groups, but no permissions!

Where did they go? In AS 2005 a permission is a property of the object to which the permission is granted. My role named HR was granted Read permission to the HRCube. The code granting this permission is contained in the cube’s XML file. My role named Sales was denied permission to certain attribute members in a dimension. The code denying access to these members is contained in the dimension’s .dim XML file. 

This makes objects less portable. I created a new database and then added all the objects from the database described above, except the roles. When I tried to build my new database I got the following error: “The Role with ID = ‘Role 1’ doesn’t exist in the collection.” 

Why did I get this error? Because the XML code for the objects I added grant permissions to roles that do not exist in the new database. No problem, I thought, I’ll just remove the permissions from the objects. Unfortunately, because I have no roles in the database, I have no access to the role designer. I have to directly edit each object’s XML file in order to remove the permissions. 

Lesson learned? Objects are portable between databases, just be careful about the permissions granted/denied to each object.

- Scott