Chris, Maybe for what you are trying to accomplish, you should setup a separate form to track the unique listing of different groups who have been assigned to work on an incident.
Setup workflow that when TR.Assigned Group is not null to push data to this "IncidentAssignmentGroupTracking" form where Assigned Group = Assigned Group on the form. If there is a match, updating existing and if not create a new record in the form and include the Incident number, Group Name, and Group ID. Then setup another filter on the incident form to occur after this push to run a table walk through loop on a hidden table field that displays records in the "IncidentAssignmentGroupTracking" form and for each record return append the Group IDs to Field 112 (clear it at first and then run the Filter Guide Table walk through and set the field to each Group ID returned in the table. I cant think of any better way of doing this though. For Work Info records, I wouldn't sweat it since no user can directly get that data and any reporting you set to get Incident and Work Info data can be secured based on the row locking set on HPD:Help Desk. Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Friday, June 20, 2008 2:51 PM To: arslist@ARSLIST.ORG Subject: Returning a unique list of values from a form with multiple records Here's an "interesting" problem. Any of you using ITSM 7 (7.0.02.007) in "multi-tenancy" mode might need to know this, too. BACKGROUND: I keep running into issues where Incidents are not accessible to groups that have worked on them, particularly where the Ownership remains with the default distributed support organization (IT support for the college the faculty/staff work in), but where several separate central support groups need to pass the Incident back and forth between them. Whoever is not currently assigned gets shut out. This is aggravated by the fact that there is a bushel of OOTB workflow present to prevent anyone from TAKING ownership of an Incident; it can only be "given" by the current Owner Group, who may not have anything to do with the incident if it is for a centrally supported system. All of these groups are organized into different companies. I have already had to add filters to shove group IDs into the Assignee Groups field (112) for ALL three groups - customer company, assigned group, and owner group. Now I need to add group ids for previously assigned or even previous owner groups, hopefully without too much redundancy of entries in field 112 (the current solution already results in some redundancy). PROBLEM: The data I need to work with, the history of assignment and ownership, is already being recorded in multiple entries (per Incident) in the Incident Assignment Log form. I want to query that form in filters for Incident Number = Incident ID, and Assigned Group ID != Assigned Group ID, and return all IDs that do not equal the current one. There can be several of course. The same thing for Owner Group ID. Is there a slick way to do this that will return a set of unique values instead of multiple entries of the same value, or am I going to have to set up some horrific parsing routine? I will still need to run another filter that looks up the Group ID (10 digits) from the Assignment and Owner Group IDs (SGP+12 digits) using the CTM:SYS-Access Permission Grps form, for EACH returned value, to get the values that must be added to the Assignee Groups field (112). BTW, it is always possible the Assigned Group and Owner Group are the same, so I am already putting duplicate group IDs in field 112 in that case in some incidents, and it does not seem to be a problem (and it is 255 characters long), but I would rather not pack the field full of duplicate values if I can help it. BTW, the problem extends to the Work Information records as well, since OOTB they only pick up the three values for customer company, assigned group, and owner group based on the current state of the Incident at the time the Work Info is submitted. I think that I am just going to shove the Group ID for Incident user, 20003, into Assignee Groups with the others and be done with it. The HPD:WorkLog form is not public, so access to the records in it is controlled by the parent Incident. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Please consider the environment before printing this e-mail. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
