Andrew, The "plugin architecture" is a big topic indeed. Can you be any more specific about which plugin you had your eye on? (ARDBC, Data Visualization Field, ARFilter... ?) However, while I am sure most of them could be used, I think your level of effort would be more than it would be worth. (and I think there are better ways ... please keep reading)
Since you said your coming from a v4.5 perspective I think that does help us to help you. :) I would strongly advise against building groups (of any kind) "automatically" with workflow during the day. However, I think there are other solutions here too. How about this.... Build ONE dynamic group. (Lets call it 'Extended Access Group', with an ARS 'Group ID' of 60555.) Add a special field to your ticket form (field ID 60555, char(255)) Distribute permissions for 'Extended Group Access' to the ticket data fields as desired. (Think field 112 type relationships.) Then.... Create a form that keeps track of these logical groups.( Let us call it "LogicalGroup") (Note this should NOT be the Group form. Make up your own form for this.) When the "time is right" push a record in to this form. [ This is used to manage the logical groups in some way. ] The form should contain a 'YourLocalGroupID'. 'YourLocalGroupID' can be any short [<=255] string that you want to build to uniquely identify the group. ) Create a second form (Let us call it "LogicalGroupMembers") that keeps track of who is in which group. This maps 'Login Name' to 'YourLocalGroupID'. Then you need a third form (Tick-To-LogicalGroups) that maps the "ticket" (based on GUID or better yet, ticket 'Request-ID') to the right 'YourLocalGroupID' value(s). Ok... now we have 4 forms, and three of them need joined up. :) Join the ticket form with the Tick-To-LogicalGroups form. (inner join please, based on ticket 'Request ID') --> Call it "TickGroups" Note: No one really has to have access to this form, but you might let some users see it to manage/remove records as needed. Join "TickGroups" with "LogicalGroupMemberbers" based on 'YouLocalGroupID' values. --> Call it "Extended ticket access" --> This new join is where "LogicalGroup" team members will actually be updating the ticket. :) Now here is where it gets fancy. :) On your Ticket form. Add ONE Dynamic group field (Field ID 60555) that matches the dynamic Group ID that you actually created in the real Group form above. Lets call it this access control group 'Extended Group Access'. Add View/Change access to the ticket as you want to for the 'Extended Group Access' group to be able to process/update the ticket. Think of this as *like* an Assignee Group, but better. :) When you create the "Extended ticket access" Join, do NOT bring the "field ID 60555" from the ticket form. Rather bring up the 'Login Name' field from the "LogicalGroupMemberbers" part of the join and give that the field ID of 60555. (Note you may need to store the Login Name value in the "LogicalGroupMemberbers" form with single quotes around it like the following examples: 'black.123' OR 'andrew' OR 'Bob Backline' etc... ) What this will do is use the 'Login Name' value from the "LogicalGroupMemberbers" record ( that is mapped to the ticket via a 'YouLocalGroupID' and ticket 'Request ID' values) and allow that individual to have access to the Ticket via the 'Extended Access Group'. Yes your workflow still needs to build "LogicalGroup", "LogicalGroupMembers" and "Tick-To-LogicalGroups" data records "as needed". However those things will not impact the ARS server by triggering a recache operation. It is getting late, so I hope all of that made some sense.... if not... ask questions to help us make it make more sense for you. :) HTH. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 4/24/07, Andrew Hicox <[EMAIL PROTECTED]> wrote:
Ah yes. I looked into putting the users directly into the Assignee Group field. However, the maintenance overhead required when say, a new user is added to a group, or an existing user changes groups, is just unacceptable. I think I'm going to have a go at creating the groups on the fly. That is, we create the computed group when a new ticket is added that requires a computed group that doesn't already exist. With any luck, addition of new computed groups will not be a common event, and things will only slow to a crawl once in a great while. It still seems incredible to me that there's not something off the shelf to handle this kind of situation. It seems like it would be such a common problem that it'd have been solved by now. I'm pretty new to ARS7, though I have a lot of experience with the 4.5 series (I know, not evident from my last post about filter permissions). I see there's this new plugin architecture, where one can write java code that integrates into your ARS applications (beyond the basic API layer). Do any listers here know if that architecture is flexible enough to override ARS's built in group matching? It's a lot of documentation to sift through, and I'd like to avoid having to do that if the plugin stuff is a dead end for the problem I'm trying to solve. thanks everyone, -Andrew
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
