I have mentioned this issue before, but last time, it just "went away". I
don't know why, but small problem: it's back again.

I have a user who "needs" to be a member of 24 groups within our Help Desk
4.0 system. As a result, the contents of his $GROUPS$ string is 275
characters long, when translated (automatically by the system) into Long
Group Names. In number terms, it's only 124 characters.

My problem is that parts of the system work for this person and parts do
not. For example:

- the Support Console window has a tablefield whose query checks whether
the user's $GROUPS$ contains the group for each SHR:ConsolidatedList entry.
This WORKS.
- Active Links which check for the existence of a particular group in
$GROUPS$ also succeed. eg a test AL which just checks for a particular
group name in the user's group list will run and display its test message.
- HOWEVER, a Filter which compares the user's $GROUPS$ to the "Assigned to
Group+" field and will not allow the user to take ownership of the case
unless it is assigned to a group to which the user belongs, DOES fire, and
prevents the user from assigning himself the case.

I can't understand why similar qualifications in an Active Link and a
Filter operate differently using the $GROUPS$ keyword?

It's almost like the server (filters) has a different maximum length for
$GROUPS$ than the workstation (active links)...

I have also tried reentering the user's entire group list using the group
numbers rather than the names, on the User form. This hasn't helped either.

I agree that there has to *be* a maximum, I just would like it to be the
same everywhere, and documented.

Can anyone think of a way to get around this?

jason


Unsubscribe to: Text is: unsubscribe arslist

you're right. In an acl the field length of $GROUPS$ seems to be unlimited,
in filters this length is only 255 char.

regards

Christoph

-----Ursprüngliche Nachricht-----
Von: Jason_Pearse@KAZ.COM.AU [mailto:Jason_Pearse@KAZ.COM.AU]
Gesendet am: Mittwoch, 29. März 2000 10:12
An: ARSLIST@LISTSERV.VISTAIT.COM
Betreff: $GROUPS$ - different lengths in Active Link vs Filter

Hi all

I have mentioned this issue before, but last time, it just "went away". I
don't know why, but small problem: it's back again.

I have a user who "needs" to be a member of 24 groups within our Help Desk
4.0 system. As a result, the contents of his $GROUPS$ string is 275
characters long, when translated (automatically by the system) into Long
Group Names. In number terms, it's only 124 characters.

My problem is that parts of the system work for this person and parts do
not. For example:

- the Support Console window has a tablefield whose query checks whether
the user's $GROUPS$ contains the group for each SHR:ConsolidatedList entry.
This WORKS.
- Active Links which check for the existence of a particular group in
$GROUPS$ also succeed. eg a test AL which just checks for a particular
group name in the user's group list will run and display its test message.
- HOWEVER, a Filter which compares the user's $GROUPS$ to the "Assigned to
Group+" field and will not allow the user to take ownership of the case
unless it is assigned to a group to which the user belongs, DOES fire, and
prevents the user from assigning himself the case.

I can't understand why similar qualifications in an Active Link and a
Filter operate differently using the $GROUPS$ keyword?

It's almost like the server (filters) has a different maximum length for
$GROUPS$ than the workstation (active links)...

I have also tried reentering the user's entire group list using the group
numbers rather than the names, on the User form. This hasn't helped either.

I agree that there has to *be* a maximum, I just would like it to be the
same everywhere, and documented.

Can anyone think of a way to get around this?

jason


Unsubscribe to: Text is: unsubscribe arslist


Unsubscribe to: Text is: unsubscribe arslist