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___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
