Like I thought, this was simple, and even documented (although not in an obvious fashion - see pg. 375 of ARS 7.1 Forms and Application Objects). Even the support guy was thrown off by it until someone who had seen it before explained it to him.
If you add a new table field to a form like HPD:Help Desk, which has a bazillion display-only fields, when you select the new Supporting Form all of those display-only fields remain in the Fields On Form list! They don't even appear to change with your selection of the new form, since the first data field from the new form is completely out of sight. You cannot even sort them out of the way on Field Type, you have to scroll through the entire list looking only at Field type = Data entries until you find the fields from your new supporting form. On HPD:Help Desk this can take quite a bit of scrolling, since there are several hundred display-only fields. Doh!! Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of strauss Sent: Friday, June 20, 2008 6:03 PM To: arslist@ARSLIST.ORG Subject: Re: Returning a unique list of values from a form with multiple records This got complicated quick - I suspect the incomprehensible behavior of a deployable application may be at play here. I created a form like you said, and have filters populating it with records when HPD:Help Desk updates. I have not been able to create a hidden table field on HPD:Help Desk that points to the custom form, however, possibly because it isn't part of the "application." It keeps displaying the field list from the HPD:Help Desk form itself. On the other hand, I cannot get it to display the correct field list even when I point it at a table that IS in the application. I am probably missing something silly here, this late on a Friday, but there doesn't seem to be any way to add a tablefield to HPD:Help Desk and point it at any other table and refresh the Fields On Form with the correct field list!??? Admin 7.1.00.002 or 003 against 002 server. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A. Sent: Friday, June 20, 2008 2:51 PM To: arslist@ARSLIST.ORG Subject: Re: Returning a unique list of values from a form with multiple records 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" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"