I'm using a custom application and we are working on getting the same thing implemented. I don't know if you are using an out of the box app so my answer may make some kind of sense, it may not. Nonetheless, why not use computed groups? I've got some screwy requirements that are making me restrict users from the same group not be able to see tickets except as they are assigned to them. It seems troublesome that you would use the login name to set access because I wouldn't know how to remove the previous login name from the 112 field as you set the new login name unless you assigned it to that specific person, in which case you could use the assignee group in your permissions so that they could see the record. Also using computed groups, I don't have to create a group name for every possible group that it can be assigned to. Also, one consideration for us is whether all of our children records should be restricted or if they need to be restricted independently, if yours do not have to be independent of each other, then just do a filter push of the assigned group to 112, you don't have to resolve the group id, ARS will do that for you if you push the group name, then do a push fields to the child record to modify all. Hope that helps a little.
> Date: Mon, 22 Jan 2007 17:30:27 -0500> From: [EMAIL PROTECTED]> Subject: How > to start using field 112 after 200k rows> To: [email protected]> > 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" _________________________________________________________________ Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. www.live.com/?addtemplate=holiday _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
