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 > 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
