Marcelo, What you are attempting should not behave differently in 7.6.04 than in earlier releases. The key to the challenge is likely what others have pointed out - that there are more fields that have permission (like 60900) for row level access that you will need to manage as well.
Now, as for the Submitter, isn't the Submitter group granted access to the Entry ID as well as field 112 and field 60900? If so, your Submitter will not lose access to the ticket as they have access through the Submitter field. If they don't, you can follow the suggestion of putting the Submitter onto field 112. Remember, it is the login name of the user you need to add and if you allow someone to submit "for someone else" be aware that the $USER$ value is for the person submitting not necessarily who it is for so you need to deal with the ramifications of that. Finally, filter vs. escalation. I am not coming at things from a performance standpoint but from a security standpoint. You have a situation where for up to 3 minutes, HR tickets are exposed more widely than they should be. This is a security hole. If the escalation runs and has just finished, I submit a ticket, my ticket is visible to others for 3 minutes until your next escalation run. I would argue that THIS is the issue you want to address. There is really no performance issue either way and by using Submitter or by putting the user on field 112 with the HR group you control the access for the user issue. So, I would shift your strategy toward doing real time with filters on Submit and on Modify (and maybe on Merge too if you merge in tickets) to fix permission for any HR issue. That way, there is NO window where an HR ticket has exposure. I hope this helps, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Martinez, Marcelo A Sent: Monday, November 19, 2012 9:09 AM To: [email protected] Subject: Re: Modifying Field 112 ** The reason I used an escalation was for the very reason you mentioned. Users normally call the help desk will all issues (including HR). If the help desk enters a ticket and assigns it to the HR Group, they will get an error after submit because they no longer have permissions to the ticket. Not a very clean. But, I do like your idea of the 2 filters. I have not noticed the escalation degrade the performance of the system. At least in my old 7.0.03 system... we will see in 7.6.04 once I get it working. I have made field 112 visible, and have verified that only the HR Group ID # is displayed in the field - not the Op Company that the group belongs to. Now I have not yet checked on the Vendor Assignee Groups. Thank you Brian Marcelo Martinez IT Change Management / Remedy Administration IT Customer Care Chevron Phillips Chemical Company, LP. 832.813.4262 832.381.7776 Notices: This message is conveyed, and any use is expressly subject to the disclaimer found at the following url: www.cpchem.com/forms/disclaimer1.asp From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Brian Pancia Sent: Monday, November 19, 2012 10:46 AM To: [email protected] Subject: Re: Modifying Field 112 ** 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]<mailto:[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]<mailto:[email protected]>] On Behalf Of Brian Pancia Sent: Monday, November 19, 2012 12:26 AM To: [email protected]<mailto:[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]] On Behalf Of Martinez, Marcelo A Sent: Saturday, November 17, 2012 10:28 AM To: [email protected]<mailto:[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]] On Behalf Of Rod Harris Sent: Saturday, November 17, 2012 1:25 AM To: [email protected]<mailto:[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]<mailto:[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<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://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"
