CA Service Management

Hey all,

We have an issue where we want to restrict a certain sub-set of tickets that are assigned to a particular group. For example we have a ticket sitting in T1 Technical. We want to TRSF that ticket over to ISPO Security. We want to be able to complete that TRSF than once completed have that ticket no longer available to be viewed. UNLESS you are already within the ISPO Security group. 

So basically need the data constraint to say. If your group membership includes ISPO Security than allow edit level access. If your group membership does NOT include ISPO Security than do not allow view or edit access. 

Thoughts? Your help is appreciated.

Many thanks!

Hi.

My understaning:

Restrictions by data Partition is primarely done through conditions on the context object, not the logged in user.

That means , you always define data partitions constraints on parameter of the context object , here the ticket factory.

the comparisons in a constraint mostly look like:

<context_object_attribute_name>=<value>

While the attribute name part supports a kind of relation-ship chain, the value part only supports simple values(more or less literals), with the ability to specify placeholders of the logged in user.

That said, it is not possible to say something like
Restrict view ticket access to tickets where the currrent group is 'ISPO security' and the logged in user is a member of group 'ISPO Security'.

But it would be possible to have a more general Approach, for example:
Restrict View Access to tickets where the logged in user is a member of the current Group of a ticket.

the constraint would look like

group.member_list.member IN (@root.id)

I think this could work in your situation.

Hope this helps
Regards
..........Michael

Hi Michael,

Thanks for your response!

The problem with your solution above (in terms of having to be a member of the current Group) is there are circumstances in which we want our technicians to be able to view/edit tickets that do not fall within there group memberships. For example the ticket comes into Tier 1. They diagnose and determine they cannot resolve. They TRSF the ticket up to Tier 2. But this is still a functional area of the support desk. Meaning we want them to be able to see items at Tier 2 both for follow-up, ticket statues, as well as learning resolution steps. 

Since Tier 2 (in our case) is the field offices. Giving this access to each analyst to allow access would represent an enormous undertaking. (130+ locations). And I'm not sure that it is sustainable. Which is why some solution that would allow us to indicate particular groups instead of all groups would be ideal. Cause at this time we really only want to restrict one functional area. Our security level information. But still allow access between those areas. In terms of transferring. Which is why tenancy is not a solution for us here. We are also working within a mature environment for which tenancy has proven to provide mixed results on its success. 

Any ideas?

You could create a separate role for "ISPO security" and then create Data Partitions for all other roles to prevent them from seeing those particular tickets.

That is an interesting and plausible idea ...

So assuming I created an ISPO Security role. All other roles were assigned Partition 1. And I created a new data partition for the ISPO role called ISPO Partition.

What would the data constraint look like? Would you apply a constraint to Partition 1 that says you cannot see content in (X, Y, and Z groups)? And just not apply the same constraint to the ISPO Partition?

Or... would it be more like any tickets created other than role cannot be viewed by (X, Y, and Z roles). This might be the solution I'm looking for. Just need to understand how to functionally implement something of that nature.

Thanks!

There is nothing on the ticket that indicates what role the user was in when creating the ticket. So the first idea is probably what you should implement.

Your first assumption is what we use here. We have a similar setup in our organization, our security manager has their own separate role and data partition from the other analyst role and analyst data partition. Our security manager can see all tickets regardless of the assigned group, but the analysts cannot see tickets assigned to the security manager group.

 We apply two constraints to the analyst partition and none to the security manager partition. The two constraints we use are:

type: view. Table: call_req constraint: group != ‘UUID of the security manager group’

type: view. Table: Change_request. Constraints: group != ‘UUID of the security manager group

I also recommend adding this new role to the Administration Access type so that it can be thoroughly tested.

Hi John,

Thank you! Appreciate the follow-up and the examples of how this has worked for your group. I'm going to work on our test environment with the variables you have provided and see what we can make happen. In terms of the big picture.

Thanks again!

It's documented, look at: CA SDM Data partition::. call_req cr