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"
