Marcelo, You need to validate what is actually stored in field 112. Why are you using a escalation? It seems that this would put an unnecessary load on the system and may not have your desired results. I would setup a filter that fires on the save button, which will set Vendor Assignee Group to $NULL$ and Assignee Group to the Group ID of your Support Group. You want to use the Support Group and not the Operating Company the Support Group belongs to. I would set the execution order high. There are multiple modifications when a ticket is saved and they will overwrite your workflow if the execution order is not set right. Keep in mind that Tasks and Worklog entries inherit the ticket permissions, so you want to make sure the right values are getting pushed there. The only issue you might run into is if you have other groups open up tickets for your HR group. By setting field 112 on the filter action you will need to also add the submitter to field 112 or errors will pop up for the user submitting the ticket. You can setup another filter to remove the submitter, say once HR puts the ticket in progress.
Brian On Mon, Nov 19, 2012 at 10:01 AM, Martinez, Marcelo A <[email protected]>wrote: > ** > > Brian,**** > > Thanks for replying.**** > > -I have validated my workflow to ensure that field 112 is being set.**** > > -I need to verify Vendor Assignee Group is blank. (thanks!)**** > > -workflow is being set by escalation. **** > > -I have verified that that the accounts I am testing with do not have > unrestricted access.**** > > ** ** > > I’ve noticed that when I create or modify workflow, changes do not take > effect right away. Even after flushing mid-tier. Ie: setting field 112 from > “123” to “456” by escalation (which fires every 3 minutes). Sometimes it > can take 10-15 minutes to see the changes… **** > > ** ** > > Thanks again Brian.**** > > ** ** > > *Marcelo Martinez* > > ** ** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Brian Pancia > *Sent:* Monday, November 19, 2012 12:26 AM > > *To:* [email protected] > *Subject:* Re: Modifying Field 112**** > > ** ** > > ** **** > > I would be careful with modifying field 1 on the OOB stuff. Validate that > your workflow is setting field 112 to what you want and that field Vendor > Assignee Group is blank. Also, check your execution order on your > workflow. The other thing you want to make sure is that people do not have > Unrestricted Access. This will give them access to pretty much everything. > **** > > ** ** > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Martinez, > Marcelo A > *Sent:* Saturday, November 17, 2012 10:28 AM > *To:* [email protected] > *Subject:* Re: Modifying Field 112**** > > ** ** > > ** **** > > Hi Rod,**** > > You are correct. But none of my support staff are part of that group; I > have not defined any vendor support groups. And after overlaying field 1 > and removing that permission, they still had access to view incidents. *** > * > > I’m sure I’m missing something…**** > > ** ** > > Thank you,**** > > * * > > *Marcelo Martinez* > > ** ** > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Rod > Harris > *Sent:* Saturday, November 17, 2012 1:25 AM > *To:* [email protected] > *Subject:* Re: Modifying Field 112**** > > ** ** > > ** **** > > Hi Marcelo,**** > > I think you will find that 112 is not the only dynamic access group used > in ITSM. From memory field 1 is also set to allow members of group 60900 to > view data. This group is for the vendor support group.**** > > Check the permissions on 1 to confirm.**** > > Rod**** > > On Nov 17, 2012 9:08 AM, "Martinez, Marcelo A" <[email protected]> wrote: > **** > > ** **** > > Hello List,**** > > I need your help. In our previous ARS 7.1/ITSM 7.0.03, I had an escalation > that ran against the HPD:Help Desk form every few hours and looked for a > specific support group assignment (ie. Assigned Group = HR Group). If the > HR Group was the assigned support group, then it would do a set fields > action and change fieldID 112 (Assignee Groups) to a particular group (ie > 1000000300). All members of the HR Group were part of the 1000000300 > group; everyone else was not. This action allowed *only* members of the > HR Group to be able to see incident tickets assigned to them.**** > > If at any point the HR group reassigned the incident to any other team, a > field, which fires on modify, would set fieldID 112 back to the original > 1000000006 (group everyone is part of). **** > > **** > > Now, we are moving to 7.6.04. I have created the 300 group and added > members, escalation, and filter. But members NOT in the 300 group are still > able to see incidents which have Assignee Groups = 1000000300.**** > > My understanding is that EntryID (field ID 1) gets its permissions from > Assignee Groups (field ID 112). I have verified my workflow and field ID > 112 is being set correctly. **** > > I have flushed cache and restarted ARS.. to no avail. I’ve read the docs > and as I understand this should work. –As it did in 7.0.03.**** > > **** > > Am I missing something here? Is 1000000006 being set somewhere else? And > is EntryID permissions any different than what they used to be? **** > > **** > > Thanks and good weekend,**** > > **** > > *Marcelo Martinez***** > > **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_**** > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
