**
many thanks again Rod.
But it still doesn't work.
I tried without quotes. I noticed the system translates the userid
000000000001024 into ;000000000001024;
then I tried with '000000000001024'. The same translation happened
;'000000000001024';
I also tried with double-quotes
I created my own Dynamic Group and added the same into that group
Nothing helped: my user does not get access to the request.
But probably you are right, I need to look what is elsewhere going wrong
serouche
Rod Harris wrote:
**
Hi Serouche,
I don't think using dynamic groups should impact performance too
much. You might be seeing some recaching as you change things at the
moment. Things should sort themselves out and settle down. If they
don't then depending on what's causing a performance problem there are
a lot of different things you can do to improve it.
Rod
On 08/04/2009, Remedy Maniac <remedy.man...@googlemail.com>
wrote:
**
ok many thanks for your infos
Rod.
One thing I am noticing is that having the user id in that field seems
to slow down the system
Am I right?
Is there anything to do to improve the perfs?
serouche
Rod Harris wrote:
**
You seem to be following the right steps.
It is definitely a single quote around the userid. You have
stopped getting the error message when modifying the assignee group
field right?
Check that you're doing everything right. Try it using your
own dynamic group field if you're still stuck. You have to create a
group and a field with the same ID, and it must be in the correct range.
I've used this feature quite a lot in many different
versions of AR so it does work as documented.
Rod
On 08/04/2009, Remedy Maniac <remedy.man...@googlemail.com>
wrote:
**
doesn't work
I gave access the Assignee_Group to the Request_ID field.
I put in the Assignee_Group field the ID of my user. I tried with
quotes and without quotes. Maybe I should try with double-quotes.
I put my user in the CC list as well
I tried to access the ticket using this user. The system doesn't find
the request.
There is something missing, or ?
serouche
Rod Harris wrote:
**
Serouche,
Forget using groups for now then. Just put each userid
in the 112 field surrounded by single quotes.
Create a filter on submit/modify that looks at the CC
field and places each user login ID in the cc field (you may need to do
a lookup of the user form if you have full email addresses in the CC
field) into the 112 field. Surround each user id with single quotes.
Give assignee group permission to the relevant fields.
Use request ID (1) to restrict row level access. Once you do this the
built in permissions system will do the rest.
Rod
On 08/04/2009, Remedy Maniac <remedy.man...@googlemail.com>
wrote:
**
my problem is exactly
here: all people are in the same group let say "Callers"
They all can submit tickets. So with the submitter I have no problem.
But then in addition to this: they should be allowed to access tickets
only when they are in the CC field.
So question: how am I going to check the $USER$ against that CC list
using the Dynamic Group ?
Sorry I don't get it.
I can populate the Dynamic Group with the groupids. But then everybody
from that group will have access to the ticket.
Which I don't want.
How can I build a workflow to give access on the user basis? keeping in
mind I need to extract at some point my user from the CC list field
The documentation is poor and wrong.
Serouche
Rod Harris wrote:
**
Ok, submitter is handled in the usual way. Give the
built in group "submitter", access to everything that it needs, request
ID field in particular.
For the user(s) in the CC field I would create a
dynamic group field and put everyone in the CC field (groups if
necessary too) into the dynamic group field. If you are not already
using 112 for anything else then this can be used to hold the CC users
and groups. Give assignee group access to request ID also.
In summary. Yes - you are on the right track. I
think the main problem was that you just didn't get the syntax quite
right for userids.
Good luck,
Rod
On 08/04/2009, Remedy Maniac <remedy.man...@googlemail.com>
wrote:
**
right.
Many thanks for this infos.
Somehow I have the feeling that I am loosing my first goal: I need to
give access on requests on an individual basis. Depending whether the
user is either the submitter or in the cc list field.
Would that be the way to proceed: using the Assignee Group combined
with Dynamic group?
Or am I just walking in lost corridors?
Many thanks for your help
Serouche
Rod Harris wrote:
**
Serouche,
Yes, you can use the assignee group field to
hold individual users. The userid needs to be enclosed in single quotes
though to distinguish it from a group name.
The same rules apply for the dynamic groups
fields (fields and matching group IDs in the range of 60000 to 60999).
Dynamic groups enable you to have more than 1 field with the same
attributes as the special 112 field. I think this feature was added in
about V6.
One note of caution when you put userids into a
dynamic group field. Watch out for userids that have a single quote in
them eg. 'Peter o'connell'. You need to put a second single quote in
front of the one in the name in these cases.
Rod
On 07/04/2009, Remedy Maniac <remedy.man...@googlemail.com>
wrote:
dear
listers,
I am trying to build an access based on individual basis.
i.e: the user can access any ticket as soon as s/he is either the
Submitter or in the CC list field found in the ticket itself (= there
is a character field used to cc some people)
So i created a character field with id 112 named Assignee Group
I've built a workflow which reads the User form and set the field 112
to the login name of the $USER$
the Request-ID field is readable by the field id 112
This later is correctly updated base on the login found in the User form
But then I keep getting the following message:
You cannot translate the group name in the Group List or Assignee Group
Field. :
Assignee Group (ARWARN 9305)"
Can anyone help on solving this issue?
Thank you
Serouche
PS: ARS 6.00.01 with Mid-tiers 6.3 on Solaris 8 with Sybase 12.5.3
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: RMI Solutions ARSlist:
"Where the Answers Are" html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where
the Answers Are" html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor:
RMI Solutions ARSlist: "Where the Answers Are" html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___
|
