[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

Re: How to "split" Unrestricted Access



**
Hi Doug,

I'm using ITSM 8.1.02

/Irina

2017-04-21 21:02 GMT+03:00 Mueller, Doug <doug_mueller@bmc.com>:
**

Irina,

 

You did not mention the version of the ITSM applications that you are using.

 

In the 9.1 release (and I suggest the sp2 or later release), there were some adjustments made to the security model of ITSM.   It is configurable to use the new vs. old security model (configuration option available in the sp2 and later release).

 

The options are to make the security Company centric (the old model) or to make it Support Group centric (the new model).

 

In addition, the Hierarchical group feature of the AR System is fully supported within the ITSM applications.

 

So, with this approach, what you would do is have support groups that are for IT tickets and support groups that are for HR tickets.  You can then link them up with parent groups (and you can have multiple levels) and roll up to an IT-ALL ACCESS and an HR-ALL ACCESS group respectively.    Then, you add IT users to IT-ALL ACCESS and HR users to HR-ALL ACCESS and no one has Unrestricted Access.

 

This way, all IT users can access all IT tickets – but no HR tickets.   HR users can access all HR tickets – but no IT tickets.

 

If someone can see across things, they can be in both parent groups – or Unrestricted Access.

 

The key is that what you are trying to accomplish is OOTB functionality with the new security model option available in the 9.1 sp2 or later releases.  Something to look at to see how it can solve your problem at a minimum.  Then, something to consider upgrading to is that does indeed solve the problem you are looking at.

 

Doug Mueller

 

From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brian Pancia
Sent: Friday, April 21, 2017 6:57 AM


To: arslist@ARSLIST.ORG
Subject: Re: How to "split" Unrestricted Access

 

**

Irina,

 

I would recommended cleaning everything up and moving to a multi-tenancy model.  Unrestricted Access should be used sparingly and shouldn't be given to everyone.  I normally treat that as an admin function or for auditing.  Multi-tenancy is exactly what you are asking for and is out of box functionality, no customizations required.  If you try to customize a solution now you will probably regret it in the future.  What happens when facilities or security want to come on board and have the same data restriction requirements?  Don't over think it and make a complicated solution.  Too many developers destroy systems by coming up with solutions that out of box functionality can handle.  Think of patches, upgrades, onboarding new customers.

 

Brian

 


From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Murnane, Phil <phil.murnane@WINDWARD.COM>
Sent: Friday, April 21, 2017 8:14:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: How to "split" Unrestricted Access

 

**

Hello Irina,

 

Most HR applications I've seen store their records in separate tables from non-HR records, partly to make the security scheme simpler.

 

If this is not an option for you, I can think of one solution but it's not a good one at all: add two filters to the Incident form that fire On Get.  The first checks for membership in the "HR Incidents" group and stores the result of the check in a display-only field.  The second sets the value of all fields to null if the membership check fails.  This is very ugly because of 1) the extra load on the system to process all the On Get actions and 2) because a query would still know that a record exists, but would not know the content of the record.  Also, the OOB workflows will need a lot of fix-up.


FWIW,

--Phil


From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Irina Solarcuka <irinasever@GMAIL.COM>
Sent: Friday, April 21, 2017 5:18 AM
To: arslist@ARSLIST.ORG
Subject: Re: How to "split" Unrestricted Access

 

**

Hi,

 

The issue is that all support groups members has unrestricted access and I can't remove that. 

It is a reason why I need "another unrestricted access" that allows to HR people to see only their incidents.

At the same time I need to limit an existing Unrestricted Access so that people can see only non-HR incidents.

 

BR,

Irina

 

2017-04-21 11:33 GMT+03:00 Chris Jones <chris.jones@aramea.co>:

**

Hi Irina,

 

Another option for you to consider is using parent groups to control access to multiple companies, etc.

 

https://docs.bmc.com/docs/display/public/ars81/Using+a+parent+group+for+permissions+inheritance

 

Maybe you could create an HR parent group and grant access to that so HR people are granted access to anything within this parent group?

 

Regards,

 

Chris

 

Chris Jones, Director

www.aramea.co

 

From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Irina Solarcuka
Sent: 21 April 2017 05:34
To: arslist@ARSLIST.ORG
Subject: How to "split" Unrestricted Access

 

**

Hi,

 

I would like to "split" Unrestricted Access in two parts - HR Unrestricted Access and Unrestricted Access for the other incidents.

Is it possible?

I've created an additional field in CTM:People form called HR Unrestricted Access, an additional Role and group with the same name.

I can't use multi-tenancy since we have a mix of customers and support companies. Each support company can support each customer.

I can't remove Unrestricted access from all the users that have that because of the same reason..

 

Any help is appreciated 

 

BR,

Irina

_ARSlist: "Where the Answers Are" and have been for 20 years_

 


Image removed by sender. Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



_ARSlist: "Where the Answers Are" and have been for 20 years_

 

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately.

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_