Drill Through - Leaf Level Rule, but not allowed to drill

[shopkins]

Hello,

I have been able to build my drill down process with the help of some members of this forum (thanks!).

We rolled this out to a few members of our user base but ran into an issue. The Drill Through rule assignment is set for the leaf level:
[] = S:IF( (ISLEAF = 1), 'fullbutest_reportingQA', ''); -> where fullbutest_reportingQA is the Drill Through process

I can still get to a leaf level and Drill Through, however, one of the main users (one with read-only permissions - while I am considered an Admin) is not able to drill down even though the field is a leaf. I see the cell as white while they see it as gray and the Drill option is grayed out as well.

I am not sure what the issue would be. Could it be permissions or just how the process was created? I am a little stumped as to how to correct this for the users.

Thank you!

[lotsaram]

You need to make sure that all users have read access to the }Drill_ process. From memory I'm not sure about the }CubeDrill_ cube where the drill assignment rule is but I think access to this object isn't necessary but the read access to the drill process is essential.

I find this is something that nearly always gets overlooked by developers who then find the users can't drill. In my models I normally have a blanket rule in the }ProcessSecurity cube like this so that this issue never comes up.

Code: Select all

['}Groups':{'ADMIN','DataAdmin','SecurityAdmin'}] = S: STET;

[ ] = S: 
IF( SubSt(!}Processes, 1, 6) @= '}Drill',
  'READ',
  Continue
);

[shopkins]

I tried that code snippet in the }ProcessSecurity cube but it didnt work. I am unable to drill.

Code: Select all

['}Groups':{'ADMIN','ALL UAC EE'}] = S: STET;

[ ] = S:
IF( SubSt(!}Processes, 1, 6) @= '}Drill',
  'READ',
  Continue
);

One question - in }Groups line in the code, do I need to specify all the groups who have access? I added the ADMIN group which we have as well as the group that has every user in (ALL UAC EE), but when I applied the change and had my ID reduced to the ALL UAC EE group, I still wasnt able to drill down.

Thoughts??

[shopkins]

Solved it.

I went down to Processes and right-clicked on it and went into Security Assignments.
I was able to find the process and assign the READ permission to the group that I wanted.

Thank you for your help!

[lotsaram]

One question - in }Groups line in the code, do I need to specify all the groups who have access? I added the ADMIN group which we have as well as the group that has every user in (ALL UAC EE), but when I applied the change and had my ID reduced to the ALL UAC EE group, I still wasnt able to drill down.

Thoughts??

Shopkins - you need to understand first how rules work and what it is doing. The STET rule is just there so that no rules will apply to this area. This is done more for tidiness to not have the rule apply to the inbuilt admin groups, not that it would have any effect anyway as the rights of these groups can't be impacted by any rules or manually entered settings anyway. But by adding ALL UAC EE to the first rule what you are doing is making sure that any subsequent rule (that is the one that you need for this group!) will not actually be applied. You need to remove this then it will work.

In terms of making the bottom rule that applies to all groups and all processes (this is what the empty square brackets means) I wouldn't see any particular need to limit this to individual groups of users.
1/ because drill processes are control objects and so are generally hidden
2/ because even if users have theoretical read access to a drill process cube security must still be there for a user to get the drill context and execute the drill sucessfully

[shopkins]

Code: Select all

['}Groups':{'ADMIN','ALL UAC EE'}] = S: STET;

I tried that line with and without 'ALL UAC EE' and I couldn't get it work with the drill when I was no longer set to an ADMIN and only in the 'ALL UAC EE' group. I added the 'ALL UAC EE' to the line when I didn't have success without it.

To get it to work, I was in the Explorer and went to Processes and right-clicked on it for Security Assignments. I noticed that the setting for the Drill process was set to 'None' for the 'ALL UAC EE' group. I changed the setting to be Read. I had another Admin take away my Admin rights and put me only in the 'ALL UAC EE' group. I was then able to drill down on the field. I think that I understand what the second part of the code was doing there where is comparing the first 6 characters of the process to }Drill and if they are the same then READ else continue on. It makes sense, but I wasn't able to get it working though.

[tomok]

I think that I understand what the second part of the code was doing there where is comparing the first 6 characters of the process to }Drill and if they are the same then READ else continue on. It makes sense, but I wasn't able to get it working though.

Did you refresh security (by right-clicking on server in Server Explorer and choosing Refresh Security) after making the changes. When you make security changes without using the security section of the GUI then those changes don't take effect until you refresh security or restart the server.

[lotsaram]

I was going to post the same but Tomok beat me to it. If any change is made to the security cubes (either by direct data input or CellPutS in the cube itself or by a rule) then before the change takes effect it is necessary to perform a security refresh either manually or via TI. This isn't necessary when changing values directly via the security GUI. However because TM1's security GUI is so mindbogglingly slow and awful most experienced admins and developers will opt for direct edit followed by security refresh.

If you implement the rule correctly then do a security refresh then your drilling issue should be fixed. If you could report back if this is the case it would be good to either confirm this or then dig deeper.

[MSidat]

Lotsaram/Tomok,

It might just be 9.5.2 onwards but I dont think a Security Refresh is required when changed via a TI or direct input into the security cube. We used both Rule based and direct input methods and find that the direct inputs (via TI or Cube Viewer Input) are reflected straight away, whilst a rule change always require a Security Refresh.

[lotsaram]

I might have been wrong about the direct input to cube .....

[shopkins]

I will try the proposed solution again tomorrow. I will make sure to refresh security this time as well. I will make sure to set the permissions on the process through the Security Assignments back to the original value of None before I make the change.

We are running version 9.1.3 currently so it appears that I should do the refresh of security once I add the rule to the }ProcessSecurity cube.

I will post my findings once I am able to do the testing.

[tomok]

I will try the proposed solution again tomorrow. I will make sure to refresh security this time as well. I will make sure to set the permissions on the process through the Security Assignments back to the original value of None before I make the change.

We are running version 9.1.3 currently so it appears that I should do the refresh of security once I add the rule to the }ProcessSecurity cube.

I will post my findings once I am able to do the testing.

This is all going to depend on what function you used to update the cube. If you use the generic CellPutS function then you will need to refresh security. If you use ElementSecurityPut then you are not supposed to have to. I always issue a SecurityRefresh command in the Prolog whenever I mess with security in a TI just to be safe.

[shopkins]

I was under the impression from the previous posts that I needed to add the rule to the }ProcessSecurity cube and then refresh security for that to work.

From what you are saying, it appears that there needs to be code in the TI process which updates the cube. I am now a little confused.

I was able to get the permissions to work by changing the Security Assignments for the Processes. I changed the group setting from None to Read which did allow me to use the Drill process once I was no longer an Admin.

[lotsaram]

I was under the impression from the previous posts that I needed to add the rule to the }ProcessSecurity cube and then refresh security for that to work.

That's what I'm betting.

[shopkins]

OK - here is what I did this morning:
Went into the Processes -> Security Assignments and took the Read permissions for my }Drill process off of my ALL UAC EE group and reset it back to None.
I then went into the rule for the }ProcessSecurity cube and put in the following code:

Code: Select all

['}Groups':{'ADMIN'}] = S: STET;

[ ] = S:
IF( SubSt(!}Processes, 1, 6) @= '}Drill',
  'READ',
  Continue
);

I then refreshed the Security on the server.
Next, another admin took away my Admin powers and put me only into the ALL UAC EE group. I then went to my Level 0 view in my cube and was able to right-click on the cell and see the Drill option and get results back.

Thank you for your help and commentary on this. I have been learning quite a bit on this forum.

[tomok]

Did you refresh security (by right-clicking on server in Server Explorer and choosing Refresh Security) after making the changes. When you make security changes without using the security section of the GUI then those changes don't take effect until you refresh security or restart the server.

Sorry for the nonsense post. I was thinking you were doing the security update through TI and not a rule.

[shopkins]

Well, it appears that with our version (9.1.3) that I needed to refresh Security.

I made the changes and forgot to refresh Security and wasn't able to drill. As soon as I became an Admin again and refreshed Security, I had my Admin rights taken away again, and this time I could see the Drill option and was able to drill.

It appears that I needed to do the refresh of Security to get it to work properly.