Re: Row-Level Security on HPD:Help Desk
I wanted to give a quick update on this. I'm currently testing it. I created a field I called ReadOnlyGroups with Field ID 60710 and set the default of that field to be ;-10; so it will pick up the Unrestricted Access group by default. I also created a radio button called Confidential that when checked will clear out the ReadOnlyGroups field. However, upon further investigation, it looks like the Customer's company group id goes into Assignee Groups (112) and the Support Group Company group id goes into Vendor Assignee Groups (60900). As a result, they are still visible to people in those organizations, which unfortunately is too many. If I clear those two fields out as well, then nobody other than administrators can see it. That surprised me a bit because I would have thought the Assignee Groups field would have been used to actually track assignee groups. I'm not really able to see where the specific group is being tracked in such a way that would be used to drive permissions. For example, the Assigned Group ID and the Owner Group ID fields are there, but storing the Entry ID field rather than the group id. As a result, it looks like they aren't using Group security for actually securing the Incidents. My next step is to create a ReadWriteGroups field with a Field ID of 60715 that I can then move the General Access role to by defaulting it to ;-2;, remove that role from having access to the Entry ID and add the ReadWriteGroups dynamic group to that and see if that makes a difference. At that point, I can also see about adding the actual groups tied to the Support Groups to this field as a part of my workflow. I also need to investigate some workflow that is broken by doing this. Specifically, the active links to make the record read only and display the warning on the banner instead of the process flow bar aren't working. However, users that don't have write access still can't get to the record. Does anyone know of anything else I should look at, specifically any other fields on HPD:Help Desk that might need to be taken into consideration so I can ensure that the Assigned Group are the only ones (other than Remedy admins) who have access to the Incident? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security
Re: Row-Level Security on HPD:Help Desk
One more update for today since some people have emailed me off list with interest in what I'm doing. What I ended up doing so far is this: 1) Create a custom character field on HPD:Help Desk called ReadOnlyGroups (FID 60710) to store a default of ;-10; to be able to handle Unrestricted Access permissions. 2) Create a custom radio button on HPD:Help Desk called Confidential that functions as a flag. 3) Create a filter that executes upon submit or modify when the Confidential flag is set for the first time or the Confidential flag is set and the group assignment changes. a. This does a Set Fields from CTM:SYS-Access Permission Grps which sets the Vendor Assignee Groups and Assignee Groups fields on HPD:Help Desk to the Permission Group ID field on CTM:SYS-Access Permission Grps where the Support Group ID field on HPD:Help Desk matches the Assigned Group ID field from CTM:SYS-Access Permission. 4) Create a filter that executes upon modify when the database version of the Confidential flag was checked, and the transactional version is unchecked. a. This does a Set Fields from CTM:SYS-Access Permission Grps which sets the Vendor Assignee Groups field to Permission Group ID where the Assigned Support Company = Navigation Menu01. b. It Sets the ReadOnlyGroup field back to ;-10;. c. It also does a Set Fields from CTM:SYS-Access Permission Grps which sets the Assignee Groups field to Permission Group ID where the (Customer's) Company = Navigation Menu01. Unfortunately, I've broken a few things, so I may have to change how this works to get it working right. One of these things has resulted in the Assigned Group*+ and Assignee+ fields not working for normal users anymore, not just on confidential Incidents but in general. It also looks like it's broken some of the Active Links that handle normal security. I'm hoping these are easy to resolve, but it's too soon to say and I'll probably stop working on it for the day. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Tuesday, March 11, 2014 10:42 AM To: arslist@ARSLIST.ORG Subject: RE: Row-Level Security on HPD:Help Desk I wanted to give a quick update on this. I'm currently testing it. I created a field I called ReadOnlyGroups with Field ID 60710 and set the default of that field to be ;-10; so it will pick up the Unrestricted Access group by default. I also created a radio button called Confidential that when checked will clear out the ReadOnlyGroups field. However, upon further investigation, it looks like the Customer's company group id goes into Assignee Groups (112) and the Support Group Company group id goes into Vendor Assignee Groups (60900). As a result, they are still visible to people in those organizations, which unfortunately is too many. If I clear those two fields out as well, then nobody other than administrators can see it. That surprised me a bit because I would have thought the Assignee Groups field would have been used to actually track assignee groups. I'm not really able to see where the specific group is being tracked in such a way that would be used to drive permissions. For example, the Assigned Group ID and the Owner Group ID fields are there, but storing the Entry ID field rather than the group id. As a result, it looks like they aren't using Group security for actually securing the Incidents. My next step is to create a ReadWriteGroups field with a Field ID of 60715 that I can then move the General Access role to by defaulting it to ;-2;, remove that role from having access to the Entry ID and add the ReadWriteGroups dynamic group to that and see if that makes a difference. At that point, I can also see about adding the actual groups tied to the Support Groups to this field as a part of my workflow. I also need to investigate some workflow that is broken by doing this. Specifically, the active links to make the record read only and display the warning on the banner instead of the process flow bar aren't working. However, users that don't have write access still can't get to the record. Does anyone know of anything else I should look at, specifically any other fields on HPD:Help Desk that might need to be taken into consideration so I can ensure that the Assigned Group are the only ones (other than Remedy admins) who have access to the Incident? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only
Re: Row-Level Security on HPD:Help Desk
The filter would be a good idea but in our situation we are using BMC Analytics for reporting, which goes directly against the database via a SQL driver rather than through the Remedy ODBC driver. It also has what Business Objects calls a derived table for permissions that I may need to modify for this stuff to work as well, but I'll leave that to the reporting team to figure out. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, March 07, 2014 5:33 PM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential
Re: Row-Level Security on HPD:Help Desk
Multi-tenancy isn’t really designed in such a way that it could be used for this because we had to basically give everyone “Unrestricted Access”. Unfortunately, multi-tenancy is pretty useless if you’re using SRM unless you’re a big fan of creating duplicates of every single thing that is shared between different companies (I have no idea why BMC doesn’t allow you to use “- Global -“ in SRM.) Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: patchsk [mailto:vamsi...@gmail.com] Sent: Friday, March 07, 2014 11:57 PM To: arsl...@googlegroups.com Cc: arslist@ARSLIST.ORG; arslist@ARSLIST.ORG; Pierson, Shawn Subject: Re: Row-Level Security on HPD:Help Desk Multitenancy is for security in a shared environment between different companies or different business units with in the same company. You might want to check if you can use this feature if your ITSM env is multitenant enabled? Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
That’s a pretty good idea. I had two others that I could do as a “last resort” if for some reason setting the row-level security didn’t work the way I expect. One is to create a field that only the assigned group has access to called “Confidential Notes” or something like that, but your idea seems cleaner. The other one, which would be cool to work on but isn’t necessarily something that would be quickly implemented would be to add a flag that could encrypt all the data on the Incident via a run process on a Filter when they save the record, and on display a similar run process Active Link would decrypt it. That would be fun to build, but not necessarily quick enough. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Roney Samuel Varghese. Sent: Sunday, March 09, 2014 8:01 AM To: arslist@ARSLIST.ORG Subject: Re: Row-Level Security on HPD:Help Desk ** Shawn, We had a similar requirement, the only difference being the confidentiality was supposed to be in the worklog instead of the Help Desk form. We repurposed the view option on the Helpdesk form and added a third option of confidential to public and locked options while configuring row level access on the HPD:Worklog form. Regards, Roney Samuel Varghese Sent from my iPhone On Mar 7, 2014, at 11:22 AM, Pierson, Shawn shawn.pier...@energytransfer.commailto:shawn.pier...@energytransfer.com wrote: ** I think I’ve come up with a plan but it’s a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I’m going to remove the “Unrestricted Access” Role from the Request ID field on HPD:Help Desk. - Then I’ll create a custom field to take its place, let’s say 60701, which I will create a Dynamic Group for that I can have the “Unrestricted Access” Role be put into as a default. - I’ll add a Radio button called “Confidential” on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I’ll set 60701 to the “Unrestricted Access” Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I’m working on something that has been discussed by others here but I’m having trouble conceptualizing how I can do this. The user’s requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I’m debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I’m struggling to come up with a good way to lock things down. Also, using multi-tenancy isn’t an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we’ll have to be very careful to ensure these don’t show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed herehttp://www.energytransfer.com/mail_disclaimer.aspx. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender
Re: Row-Level Security on HPD:Help Desk
Shawn, We had a similar requirement, the only difference being the confidentiality was supposed to be in the worklog instead of the Help Desk form. We repurposed the view option on the Helpdesk form and added a third option of confidential to public and locked options while configuring row level access on the HPD:Worklog form. Regards, Roney Samuel Varghese Sent from my iPhone On Mar 7, 2014, at 11:22 AM, Pierson, Shawn shawn.pier...@energytransfer.com wrote: ** I think I’ve come up with a plan but it’s a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I’m going to remove the “Unrestricted Access” Role from the Request ID field on HPD:Help Desk. - Then I’ll create a custom field to take its place, let’s say 60701, which I will create a Dynamic Group for that I can have the “Unrestricted Access” Role be put into as a default. - I’ll add a Radio button called “Confidential” on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I’ll set 60701 to the “Unrestricted Access” Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I’m working on something that has been discussed by others here but I’m having trouble conceptualizing how I can do this. The user’s requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I’m debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I’m struggling to come up with a good way to lock things down. Also, using multi-tenancy isn’t an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we’ll have to be very careful to ensure these don’t show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Row-Level Security on HPD:Help Desk
Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Pierson, Shawn Sent: Friday, March 07, 2014 9:30 AM To: arslist@ARSLIST.ORG Subject: Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, Shawn Pierson Remedy Developer | Energy Transfer Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
That is loosely what I did years ago adding row level permissions to ITSM 6. This probably isn't as scary of a customization as it appears at first glance. One thing to consider are permissions to related records. Not only relationships to incidents, changes, work orders (you may never even relate any of those to confidential tickets) but to tasks and probably more importantly work info records. Those are searchable and will not be restricted unless to modify them to fit your permissions scheme as well. Or... You created a filter that fires on get that checks if the ticket is confidential and referencing the groups that are allowed to see confidential requests and throw an error if the don't have access. This also works for all clients (ARODBC, Web services, import tool, Migrator) like permission do. I think permissions provides for a better experience and scalability but a filter avoids changing the out of the box permissions model. For example if a person runs a report and a confidential record they don't have access to is in the results *I think* they will not be a able to run the report until the confidential records are no long in the results. Jason On Mar 7, 2014 9:22 AM, Pierson, Shawn shawn.pier...@energytransfer.com wrote: ** I think I've come up with a plan but it's a bit of a scary idea to monkey around with permissions on ITSM forms in this way. - I'm going to remove the Unrestricted Access Role from the Request ID field on HPD:Help Desk. - Then I'll create a custom field to take its place, let's say 60701, which I will create a Dynamic Group for that I can have the Unrestricted Access Role be put into as a default. - I'll add a Radio button called Confidential on the HPD:Help Desk form, which will have workflow to set fields 60701 and 112 automatically to $NULL$ if the Confidential button is checked. If it is unchecked, I'll set 60701 to the Unrestricted Access Role, and field 112 to the Regular Group where the Long Group name is the same as the company on the Customer+. - Look for any workflow that sets these fields and find some way to override them when the Confidential radio button is checked. Is there a better supported way to do this? Thanks, *Shawn Pierson * Remedy Developer | Energy Transfer *From:* Pierson, Shawn *Sent:* Friday, March 07, 2014 9:30 AM *To:* arslist@ARSLIST.ORG *Subject:* Row-Level Security on HPD:Help Desk Good morning, I'm working on something that has been discussed by others here but I'm having trouble conceptualizing how I can do this. The user's requirement is to track confidential Incidents in ITSM. This is defined by setting a flag of some sort (I'm debating making it either a custom field or an Operational Category) which will trigger a lock down to remove read access from all but the Assigned Group on the Incident (who will also be the Incident Owner Group in this scenario.) To do this, I was thinking about creating a custom field, with a Field ID of 60700 or something. Would I then set a default to be the same as the Assignee Group (7) as well as the Unrestricted Access Role, then when the flag is checked just remove the ID of the Unrestricted Access Role? What would I do to the Request ID field to make it work on combination with this new field to restrict visibility into the Incidents? It seems pretty straight forward to create a new field and give change access to a group that has read only access, but I'm struggling to come up with a good way to lock things down. Also, using multi-tenancy isn't an option, unfortunately. There are a lot of legitimate reasons, as a shared service organization, that we have many people with Unrestricted Access. It seems to be required to make SRM work without creating dozens of the exact same things for each division. Another thing that will be a factor is that we use BMC Analytics for reporting. Based on how it handles security, we'll have to be very careful to ensure these don't show up on reports either. My backup plan is going to be to build a custom form that can be fully locked down in the way that I need, and integrating that with Incident Management. Thanks, *Shawn Pierson * Remedy Developer | Energy Transfer Private and confidential as detailed herehttp://www.energytransfer.com/mail_disclaimer.aspx. If you cannot access hyperlink, please e-mail sender. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Row-Level Security on HPD:Help Desk
Multitenancy is for security in a shared environment between different companies or different business units with in the same company. You might want to check if you can use this feature if your ITSM env is multitenant enabled? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
