Hi Bill I agree with earlier comments that this, to me, looks like it will be a performance killer. Not only the LIKE scan on the assignee group field, but the workflow to constantly scan children for permission changes, or push from child tickets to their parents.
Field 112 Assignee Group is designed to be used to restrict access to data rows to members of certain groups. It is to stop unauthorized users seeing data that they should not see, sensitive data etc. This does not sound like your scenario. Your situation sounds like you are trying to reduce the lists of tickets users see, not because the data is sensitive, but just to 'un-clutter' and simplify their consoles. If that is the case, I would look for other ways to achieve that aim. I would reserve the use of field 112 to occasions where the data has to be protected, such as HR data, etc. So, say the aim is then to show the list of tickets by using appropriate queries in your consoles. Because of your requirement that any team that has historically worked on a ticket should be able to see it, how about creating a new table that has the ticket ID/form and the team name/ID that should have access to it. Each time the ticket is reassigned, push to this form to create or modify a related ticket. If the ticket is a child ticket (has the parent request ID in a linking field), also create a record in this form between the Assignment Team and the parent ticket ID. You should then end up with records in this form listing all the teams that should have access to a particular ticket, maintained by relatively simple filter workflow. Then, create a join form between this new table and your ticket form (or consolidated ticket form) and use that as the source for your console tables. You should then be able to restrict the list of tickets shown using table field queries that include what teams the user is a member of. Whether this will be easier to implement than the route you are taking I don't know, but it is another possible approach to consider. HTH David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Broderick Sent: Monday, January 22, 2007 10:30 PM To: [email protected] Subject: How to start using field 112 after 200k rows Please excuse this long post. I'm stuck and need another set of eyes. I have a feeling what I'm trying to do should not be as hard as it seems, but it's kickin' my butt right now. I need a sanity check on overall approach to do the following, and some advice on specific issues we are running into, before my head explodes. Problem: Management wants to change our security access model, including on existing 200k helpdesk records, including parent and child helpdesk records. Assignee Group field 112 has never been used here, but we now need to start restricting access according to the following rules: 1) On Submit - Login+ name, Submitted by Group ID, and Assigned Group ID, should be appended into field 112. 2) On Modify - If Assigned Group is changed, append new Assigned Group ID to 112 of Parent. Also append new Assigned Group ID of Parent to field 112 for any/all child tickets. 3) On Modify - If Login+ name is changed, add new Login+ to 112. 4) On Submit of Child Tickets - Append the Assigned Workgroup from the Child to field 112 for the Parent. The tricky part seems to be keeping the parent and child 112 fields in sync so the parents can still see the children, etc even if the children have different Assigned Groups. Also, it seems tricky because it's an append and not just a simple push and replace, and we can't wipe out what was there in 112, but must add to it. What I've Tried: First, for the 200k historical records, if I understand field 112 functionality, I'm thinking we can run an escalation to look up the Group ID from the Group table for existing records and put the Group ID into field 112. Then hopefully our reports will still work. For new submits, I'm thinking we can have filters append Login+ name, look up submitter Group ID and Assigned Group ID and append these to 112. As I understand it, we can use a " ; " delimiter and concatenate to do this. For submit of child tickets, I was thinking I could send an event and use an active link guide that refreshes the child table field on the parent, loop through the table field, get all the child group ids, and append them to the parent field 112. But this isn't working like I thought it should. I can't get the table refresh to fire in the right sequence. The log shows it doing everything else, then refreshing the table. Which is too late for my purposes. Interestingly, if I manually click on the table field and refresh it, the lookups and appends seem to put everything into 112 ok. But I can't get it to work automagically. I tried Remedy Support, and they were unable or unwilling to help, but instead referred me to this list... Hmmm. Has anyone ever been in this situation? Am I missing something obvious to anyone? I tried putting the table refresh in a separate active link with a lower execution order, but still no luck. How can I make an active link table refresh fire, then loop through to pick up the child group ids? I read about the `! trick for forcing filters to execute, but how can I force a table refresh from an active link? And does my overall approach seem on the right track? Forgive me if this is unclear, my brain is having a hard time with this one. Thanks for any help you can offer. Bill OCC Helpdesk 6.0 AR 6.3 ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
