In essence, you can not alter the core behavior of the arserver with plugins, you can only extend it. The area and ardbc plugin architectures let you write how certain api calls are handled under the contexts the api address, but they are limited in scope on what they were intended to address, thus only allow you limited control on the behaviors you can write.
Axton Grams On 4/25/07, Andrew Hicox <[EMAIL PROTECTED]> wrote:
Regarding the "plugin architecture" ... I'm talking, specifically, about the shared objects one can load when the server is started, via the ar.conf file. There's a couple for LDAP, and one for the webservices, etc. My question regarding them, is "is it possible to write one which overrides the function (I'm guessing) inside the ARS codebase that does the comparison on the Asssignee Group field?". Of course, keeping it as simple as possible, I'd just like to take that existing function and replace "OR" with "AND". I know it's a long shot. I'm hoping there are some folks on the list who can at least tell me if the plugin architecture works like that (overriding ARS core functions is possible?). Regarding the approach you outlined ... Rube Goldberg would be proud! ;-) No but seriously, that is a pretty ingenious way of handling it. The issue on my side, is a security requirement that the row level locking has to occur at the API level as well. thanks again everyone, -Andrew On Apr 25, 2007, at 12:37 AM, Carey Matthew Black wrote: > 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" > > Andrew N. Hicox Hicox Information Systems LLC Manassas, VA USA http://hicox.com [EMAIL PROTECTED] 703-367-9085 _______________________________________________________________________________ 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"
