Brien, $GROUPS$ and $GROUPIDS$ are keywords. First, keywords are context sensitive to the environment not to a specific ticket. Second, these keywords are the list of groups to which you have been assigned membership. You cannot be assigned membership to implicit groups. These are groups where there is transient participation on a per-ticket basis.
These keywords will be the same for your login (unless your group assignment changes while you are logged in). They do not vary on a per-entry basis. Just think about the performance ramifications if the system had to dynamically recaculate the value of a keyword on every entry during the middle of a search operation! You are using the wrong technique to try and perform the operation you are suggesting. Permissions grant you access to things. They do not perform assignment. Now, sometimes you may have an assignment field that is also defined as a field that grants access. But they are two different concepts. So, permissions will only let you see entries you should be seeing. Now, you want to subset those entries to get only ones that match a criteria. If you want to search for entries where the user is the Assignee, you have to look for the LOGIN NAME of the user not any group data. The Assignee field is a USER NAME field. So, 'Assignee' = $USER$ is the type of qualification to find records that the user is assigned. Next, comes the Assigned to Group field. In general, when an application is set up, a field like this contains A SINGLE group name (or group number). You generally don't assign something to three groups. If it happens to be a name, $GROUPS$ LIKE "%" + 'Assigned Group' + "%" is a candidate search criteria. You do need to be careful about this type of comparison if you have groups with overlapping names (like Admin and Full Admin where you may get an incorrect match for Admin). If it happens to be an ID, $GROUPIDS$ LIKE "%;" + 'Assigned Group' + ";%" is a candidate search criteria. Note the preceeding and trailing semicolon to gaurantee proper matching as the syntax of the GROUPIDS field is ;#;#;#; so that every group number has a preceeding and trailing semicolon so you don't have issues or risks with partial matches. ;77; matches ONLY group 77 and not 177 or 4077 or 777. Now if you really do assign things to a list of groups and each user can be in a list of groups, you will have to produce more involved qualifications where you parse the GROUPS or GROUPIDS keyword values apart and perform searching like you mention -- but that is really not a common scenario. I hope this note provides a few ideas and gives you a different way of looking at your problem where you separate the concepts of PERMISSIONS from other concepts like ASSIGNMENT. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brien Dieterle Sent: Monday, November 23, 2009 2:05 PM To: [email protected] Subject: $GROUPS$ does not include Assignee, Assignee Group, or other dynamic groups If I am a member of a dynamic group based on field 112 (or AssignedTo for that matter)-- why doesn't $GROUPS$ reflect this group? I tried making a AL and a Filter to display $GROUPS$ in a field on display and/or GET, but it does not include these groups. How else can one query a form for $GROUPS$ LIKE %4;% OR $GROUPS$ LIKE %7;% (Assignee and Assignee Group, respectively) In other words, how can I query a form for records where I am in these specific dynamic groups? There might be several other custom dynamic groups that let me "see" a record, so using permissions alone as an alternative to querying is not useful beyond basic use cases. Simple example: You have read-only access to certain records because you are a Vice President and you like to know what is going on-- however you want to filter out those records and only see records where you are "assigned" to do something, such as approve a specific request. So you query by Assigned To Group field to only show records where a group you are in is Assigned to do the task. Does that use case make sense? Does using groups make sense for this? Sorry if this seems whiny, I am at a loss as to why this is so difficult, I thought groups would make things like this easier! Do I really need to break up $GROUPIDS$ into pieces using an AL Guide and build a really long query string? end result being something like... (for 4 groups 501-504).. 'Assigned To Group' LIKE %501;% OR 'Assigned To Group' LIKE %502;% OR Assigned To Group' LIKE %503;% OR Assigned To Group' LIKE %504;% Obviously the above seems to be the wrong way to do things... but I'll do it if it is the only way. Thanks in advance, and sorry for the repost, my last question seemed too vague so I've reworded it basically. Brien _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
