The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
The community will be in read-only from Tuesday 11:59pm (PST) to Wednesday 7:30am (PST)
Service Desk Practitioners Forum
cancel
Showing results for 
Search instead for 
Did you mean: 

Restrict access to Service Call Status based on group

Highlighted
JW3
Regular Collector

Restrict access to Service Call Status based on group

I have eleven Service call Status entries:

 

New

Accepted

Reject

Reassign

Pending

Out of Pending

Reopen

Future Consideration

Informed

Closed

Cancelled

 

I want to hide 'Future Consideration' from all groups but one, and I want 'Closed' to only be available to a separate group.

The only way I can see to set (or restrict) access is by selecting a range:  New to Informed, for example.

Is there a way to individually choose (or exclude) one individual item ?

 

--Jeremy

6 REPLIES
John Stagaman
Honored Contributor

Re: Restrict access to Service Call Status based on group

If you mean that users should not be able to see tickets in the other statuses, you can restrict access to view records by status by updating the Allowed Statuses list in the module profile.

 

This is very problmatic, however, as it can break workflow. For example, restrict a user from viewing tickets with a status of Closed, they will also be unable to Close a record because the status is changed as part of the close process. 

 

OR did you mean that you wanted to limit what statuses the could choose? 

----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
JW3
Regular Collector

Re: Restrict access to Service Call Status based on group

I'm referring to statuses they can choose.

 

For group 'A', I would like them to see New to Informed, but not 'Future Consideration'.

For group 'B', they need to see New to Informed, including 'Future Consideration'.

Group 'C' needs to see New to Closed, but not 'Future Consideration'

 

--Jeremy

The Pike
Honored Contributor

Re: Restrict access to Service Call Status based on group

If the question is related to Service Desk, then what John Stagaman mentioned about breaking workflow does not apply.

 

To hide certain Status codes in Service Desk, you can use either UI Rules or Status Entitlement (via Roles), you might want to make sure Future Consideration has the greatest Ordering number so it appears last.

 

HTH,

The Pike (don't forget to give kudos)

JW3
Regular Collector

Re: Restrict access to Service Call Status based on group

I think the UI rule will work, but how can I set a condition based on who is viewing the ticket ?  i.e. only a member of group 'B' should have 'Future Consideration' visible, regardless of who the ticket is assigned to.

 

--Jeremy

The Pike
Honored Contributor

Re: Restrict access to Service Call Status based on group

Jeremy,

 

I responded to your other post on how to add a UI Rule condition that responds to current user.  However, it is limited to 1 user.  One cannot compare if the current user is member of a specific role or workgroup in a UI Rule condition.

 

Do not forget to give kudos if you find this useful.

 

HTH,

The Pike

Axel Jaskulski
Regular Collector

Re: Restrict access to Service Call Status based on group

Here's what we have done to do such things ..

 

  • add current_person field (entity reference to person object) to service call item
  • add ui rule (servicecall) that puts the current person -> into the new current_person field for verification purpose (should be the first one that's triggered when items is being opened/or new on created
  • add field 'level' to person object (values: level1, level2, level3)
  • build generic relation between the field level and service call status / here you have to say, which level should have access to which statuses
  • set the level field in the needed person documents
  • add ui rule that limits the status by relation, using the value [current_person;level] as trigger

This should work. - BUT, as the field current_person is changed in every case a service call is being opened/created, the service desk client asks if the values should be saved on close - even, if the user has not changed something.

 

It good to reset the "current_person" again to 'make empty' on close ..

 

bye,

axel

 

//Add this to "OnDomLoad" event