I've configured a simple Grid Options Set that simply says "If Metadata group=abc then set LSF queue=xyz"
If I add my individual metadata identity to the Grid Option Set mapping all works 100%. However, if I add a Metadata group that I'm part of, the Grid Options Set is ignored. So it seems like the Grid Options Set recognises me as an individual, but not part of a group.
This is not ideal since we control access based on groups.
Any ideas ?
I have noticed similar behavior, but in my case, the groups do work....sometimes.
This question is directed at SAS but if anyone else knows, please share: How do Grid Option Sets get resolved and is the logic similar to metadata security with Access Control Templates?
Essentially, it would be extremely helpful to understand which Grid Option set would apply to a user if they resolve to more than one based on direct or indirect assignments through group memberships.
Can anyone comment?
could you come across already any of these infos?
http://support.sas.com/documentation/cdl/en/gridref/67371/HTML/default/viewer.htm#n1inymfs0b7go2n147... (this one I guess you did) See 3rd paragraph.
https://communities.sas.com/t5/Administration-and-Deployment/SAS-Grid-options-set/td-p/342149 Andrew, @AndrewHowell, answered something like this:
"Juan's solution is a simple & excellent way to achieve your desired result using metadata security settings rather than Grid Options Sets, particularly if the EG & EM users are in mutually exclusive metadata groups. However, if a user has a valid reason to be both an EM user and an EG user, they would belong to both groups, and as such both Application Server contexts would be available to both clients"
Thanks for the reply @JuanS_OCS, however adding a new server context isn't going to help in our situation. We want to manage where the WORK library is defined as well as MEMSIZE and SORTSIZE settings for different sets of users who use the same applications. So a single context is what we have and meets our needs. In general, the concept of the Grid Option Sets (GOS) is exactly what we like. However, where it seems to fall short, and is not completely reliable, is that it won't resolve users to a predictable GOS if the user meets the filtering criteria of more than 1 GOS. At least, I haven't discovered the rules by which it seems to work. If you are careful and set them up so that all users have mutually exclusive relationships with the groups chosen for the filters, then it does work somewhat reliably. The one constant, repeatable test, that I can always count on working is that if a user is directly assigned a GOS for EG for example, they will successfully use that GOS, even if there is another EG GOS that is assigned to SASUSERS. Where it gets tricky is if there is a GOS that is assigned to a metadata group that a user belongs to as well as a GOS that is assigned to SASUSERS. In that case, I would assume that because the user is assigned to a group, it would have a higher order of precedence over SASUSERS, and therefore get to use that particular GOS. However, it is not always the case, and often they get the GOS that was for SASUSERS. Herein lies my problem. It seems like this functionality was not accounted for in the development of this feature, which is what I'm trying to find out. Yet, this same logic is how the ACTs work and would be extremely helpful in this context as well.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.