We have nearly finished designing our end user screens (phasse 2 of our go-live) but we don't want "Add Reminder" to appear on the Incident actions list for End Users.
Normally this wouldn't be an issue but as you might expect, the process we designed for our Service Desk needs to trigger an email when the customer updates via a note.
So if we remove the Add Reminder privileges, End Users won't be able to add notes as the following reminder can't be created due to privilege issues.
Any ideas - or are we stuck on this one?
If so we may have to design a Reminder screen for them which has nothing on it but a message saying "Not Available"
Many thanks - Adam
Faced with the exact same situation myself.
I was forced to remove the 'add reminder' action on the open status available actions in process designer. This allows our end users to add a note which triggers the automatic action in our process for add reminder.
Unfortunately would still like to have it as an available action for analysts as we do use it on our incidents.
I suspected as much.
I suppose one way around would be to create a new Windowed action called "Add a Reminder" on our process statuses which is then followed by a real reminder which copies the values from it.
Then we could restrict access just to the new Action, and remove the real one from each Status.
Cheers - Adam.
The sort of script you need is as follows :-
-- Script to remove the "Add Assignment" action from Incidents for a role, but still allowing
-- automatic assignments as part of the process to be created.
-- Before running edit the role's privileges to *ALLOW* the "Execute" action on "Add Reminder"
-- within Modules -> Incident Management -> Process Related Objects -> Incident.
DECLARE @rolePrivGuid uniqueidentifier
-- Which role do you want to remove the "Add Reminder" action from?
SELECT @rolePrivGuid = tps_privilege_collection_guid FROM tps_role WHERE tps_name = 'PortalEndUser' -- replace with the name of the role.
UPDATE tps_privilege SET tps_value = 0 WHERE tps_item_guid IN (SELECT md_guid FROM md_privileged_item WHERE md_name = 'IncidentManagement.Incident.Function.AddReminder') AND tps_collection_guid = @rolePrivGuid
- (Note: the update statement should affect 1 row)
Dave is right, the SQL script there will do the trick. For the same of Oracle support (don't worry Adam, I have your back!) the script came from this community document which has both SQL Server and Oracle versions: How to remove the "Add Assignment" action on incidents but still being able to use auto assignments.
The cause of the problem is that the privilege displayed in Administration actually alters two privileges behind the scenes. One is the Execution of the action, the other is the creation of records (which is what is needed for automatic actions to still work). The script sets one but keeps the other intact.
I am still having this issue after running the script. I am trying to hide the Add Reminder Optional Action from my end users but I use an automatic action within the process. Here is the script that I ran:
The script works and changes the tps_value=-0; however, I notice that the privilege for Add Reminder turns execute back off.
Basically, as an end user after running the script, I do not see the 'Add Reminder' Optional Action; however, if a user chooses that the incident is an emergency, then the add reminder automatic action does not have the permissions.
I also tried running this script on the md_name='IncidentManagement.Task.Function.AddReminder'; however, that did not solve the issue either.
Please let me know if you have any suggestions or notice a problem in the script I am running.