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.com<mailto: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<mailto: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 
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.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to