Hi HomerJ,

I have seen this before and most dont understand fully the way groups and permissions work with the data hiding. The issue I have seen many times is that the users were member of multiple groups and one of which was a default group (which doesn't allow for data hiding at all) or another group that doesn't have data hiding applied and thus other group permissions were taking precedence over the one that had the data hiding set.  The recommendation to insure permissions are applied as desired is to be the member of one group only. In the other case we have removed the default group and all groups not hiding the data from the user used for testing and to illustrate the limitation and then the data hiding has always been applied as desired.. The only suggested work around is to suggest using custom workflow as an alternative as that allows for data hiding of even the default groups.

I hope this helps,

Dan

I was literally dealing with this same thing yesterday. Because the ALM users are given Viewer group rights and privs by default when you add them to a project, more often than not when someone creates a new group and adds the user to it, they tend to leave the Viewer there as well. For example if we assigned someone to a Tester group they would then be assigned to both Tester and Viewer. When we did a bunch of data hiding for the Tester group it never seemed to work. Once we realized that because the Viewer rights let them see all of the fields, even though the Tester rights hid the fields, the user always gets the rights and privs of whichever groups allows them more permission. I don't usually tend to think that a Viewer could possible have more rights and privs over any other group, but in this case when it came to being able to see the fields, that is one thing a Viewer does best!