I am trying to create a "View constraint" data partition in Service Desk that will prevent users from being able to set the priority of a request higher than a 3. So 0-3 would be fine but they should not be able to set a request at a 4 or 5 priority as those should be handled as incidents or change requests. I have looked over the guides TMACUL created and linked at https://communities.ca.com/docs/DOC-231165059
and came up with this constraint:
type = 'R' AND NOT (priority IN ('4','5'))
The system accepts this constraint with no errors but it does not prevent the users from seeing and using the 4 and 5 priorities. Please help!
Have you tried using the ENUM values instead of the SYM values in the Priorities table?
Following the Paul Instructions we need to use the enum values and to show this particularit, i create this doc to help us CA SDM::. loading priority - pri
You can try to do using Summary CA SDM Scoreboard
please let we know if you have any more questions or was resolved.
Thanks Paul and TMACUL for your suggestions.
To answer your question Paul, the variables that I provided in the above example are the ENUM values. We have tried the above line with and without the single quotes. For reference our priority symbols run from 'P5' (lowest) to 'P1' (highest)
I have read through the links you provided TMACUL and found some information that will be helpful in other aspects but we are still unable to leverage this information to create the intended result.
The constraint " type='R' AND NOT (priority IN ('4','5')) " prevents user from seeing priority 4 and 5 tickets in results while searching but does not prevent them from opening tickets as priority 4 and 5.
So a user can create a priority 4 and 5 ticket but once it is saved the user cannot search for the ticket to get back in it.
We are trying to find a way to prevent user from seeing/using these priorities as options when creating a request. They will still need to have them for incidents.
HI RichFTB ,
Great, tks for feedbacking. On this case, i belive this document CONDITIONAL FIELDS (+Source code) by Daniel Bighelini can be useful.
Right now , your constraint only says : Do not let a user sees a CR object where type ='R' and Priority enum is 4 or 5.
To "View constraint" should be on the priority, not on the call_Req object as you seem to do!
(But unfortunatly, priiority is not a table you can add a constraint on.)
So you can do a "Create" constraint on call_req where priority is not 4 or 5.
And by the way. Can we know what is the purpose of preventing user to create p1 and p2?
Ticket type (Incident or Request) should not be based on priority. Those are totally different things.
Change orders are a way to protect your production environnement.
That's why you may encounter problems. Trying to integrate a process that is not compliant with ITIL in an itil compliant tool.
As an explanation :
What is an Incident?
An incident is now defined as any event that is 1.) unplanned 2.) causes an interruption in service or a deterioration in service quality. ITIL lays out the foundation of Incident Management principles in order to address incidents quickly and restore services to full capacity as soon as possible. What is important to note regarding incidents is that any planned service disruption or reduction in quality is not an incident. For example, if you take systems offline for updating, backing up, or maintenance, it isn’t an incident, because it is planned. Additionally, a problem can be a problem without being an incident, because unless the problem causes an interruption in service or deterioration in quality, it isn’t an incident. In other words, if you discover an issue before it causes disruptions, by definition it isn’t an incident.
What is a Service Request?
As you see, incidents have everything to do with what occurs within the systems, and may or may not have anything to do with the users. Service requests, however, have everything to do with the user, and may or may not indicate any issues within the system. Service requests are a formal request submitted by a user for some type of service, software, or hardware. Service requests generally refer to something the user wants and/or needs but does not already have, such as a printer or laptop. Service requests often involve items that are already approved. For instance, if it is company policy that all employees get access to the cloud-based CRM system, and someone from the marketing department sends a service request for access to the CRM, this does not need any additional approval. The IT help desk can simply fulfill this request.
We are trying to remove the higher priority options from Service Requests for the very reasons you listed. Here is a simplified version of our SLA \ Priority matrix.
Our reasoning behind removing the P1 and P2 priority options from Service Requests is that if a request needs to be completed within 4 hours because it could cause a work stoppage, or deterioration in the service we provide, then there should be an emergency Change Record with an Incident attached as this is obviously something the user did not (or could not) could not account for during their process.
My co-worker had asked the question another way here: https://communities.ca.com/message/241968143?commentID=241968143&et=watches.email.thread#comment-241968143
We are now able to modify the form the way we need it. Thank you to all who provided assistance!