Michael,
Actually I think there is at least one good reason for why ARS
supports (or maybe "supported" is a better phrase) this feature.
The idea is a "group alias". ( Two "Group" form entries with the same
'Group ID' value but different 'Group Name' values.) This is a
designed feature from the "old days". Ref: v4.0 admin_vol1.pdf pg
1-26: This is part of a table "Table 1-3 Key Fields in Group Form":
"
Group ID
Integer ID that is the recognized identity of the group. For groups
that you create, the ID should be greater than 10. If you use the same
ID with multiple group names, you must keep the Group type the same
for each because you are creating aliases for the same group.
"
and a parallel v6.3 doc segment has this to say:
BasicGuide-63.pdf page 114
"
If you use the same ID with multiple group names, you must keep the
Group type the same for each because you are creating aliases
for the same group.
To make sure that you do not create duplicate Group IDs, use Remedy
Administrator to build a unique index on the Group ID field in the
Group form. (For more information, see "Defining indexes" on page
210.)
"
However at the lowest level these values are used for one of two
reasons: Access Controls or Notifications. And the point of the alias
has to do with the latter use not the former.
Over time it is possible (and likely) for your groups to be
organizationally merged. For example: "Helpdesk HR"(10000) and
"Helpdesk Technical"(10005) might become "Service Desk"(10005). In the
case of Notification actions in workflow these values are held as
strings('Group Name', 'Login Name', hard coded "Email Addresses" or
lists of combinations of those things) in the object definitions.
So when groups merge into a new name (or into one existing name) you
need to maintain that 'Group Name' that still has notifications going
to it, or pick through your entire application and replace the old
value(s) with the new value(s). The alias values allow you to solve
this "normal change" with a data change in one ARS form. ( You can
change the group ID values to now be Helpdesk HR"(10005) and "Helpdesk
Technical"(10005).) This would allow you to not have to change your
application and notification actions sent to "Helpdesk HR" would now
be routed to the 10005 'Group List' members instead. (Yes you likely
need to move all users in 10000 into 10005 in the 'Group List' too. So
that 10000 can be total abandoned.)
Keep in mind that if the 'Group ID' is used as an Access Control then
those references are NOT removed by changing data in the Group form.
So if you ever reuse that value later(10000) then those places that
this Access Control is used will still be there and will "spring back
into life" as soon as that group is defined again in the Group Form.
Also if your application allows your users to type (manually) in a
value then that muscle memory of entering "Helpdesk HR" will also not
go away anytime soon. So you may want to support users still using
that value (for a period of time) to again, not break your existing
processes during changes like this. ( The "group alias" feature allows
for this.)
So... I think the point was to allow an easier transition under normal
and expected business org changes. However, there may be other good
reasons too.
--
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 Jan 9, 2008 4:10 PM, Durrant, Michael M. - ITSD
<[EMAIL PROTECTED]> wrote:
> **
>
> I did an application export/import from development to production and it
> replicated our existing Group IDs. Why is there no unique index on Group
> ID? I can't fathom a situation where I would want differently named groups
> with the same ID. Am I totally off-base on this or ???
>
> Thanks,
>
> Michael
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
