Can we set Activity Fields as Read-Only for Approvers?
Hi Experts, currently when a non-analyst (generally this is an approver) goes to the portal to approve an RA, they click the RA in their My Work view, and it opens and they can approve, however, they also have the ability to modify any of the fields on the RA (such as description, title, threshold, etc.) -- of course when they try to Save though, they're presented with the "Request Failed" error message because they don't have the permissions to make those changes.
This is confusing for our users -- why aren't these Activity fields read-only like the parent SR fields are? What can we do to ensure this?
On a side note, the same applies for the "Related Items" tab from an end user perspective -- nothing is read only, but if they make changes, they're presented with the same error! Help
Best Answer
-
David_Darling Customer IT Monkey ✭You know, all we needed to do to accomplish this was to populate the Activity permissions for Edit Manual Activity, Edit Review Activity, Add Reviewers, Edit Reviewers, and Delete Reviewers with the Analysts AD group. Did the trick!7
Answers
The code would need to detect the user and see if they are in the SCSM Analysts group and if not, then set the fields to disabled.
I'm not sure if this feature is planned to be included in an upcoming update or not. Take a look through all the feature requests for the portal and see if there is something similar and either Up Vote or create a new feature request if it's not there.
I hope this answers your question.
We can probably adapt the Hide Activty Fields extension to disable the fields instead,
https://community.cireson.com/discussion/comment/4211#Comment_4211
Just change
to Geoff
Could someone check my understanding here: Out of the box, there are two Service Request forms defined: Default (the full fat console-like version) and DefaultEndUser. Group membership determines which form is presented to the portal user.
So if someone is a member of a security group that grants console access, then they will see the Default form, otherwise they will get the DefaultEndUser form.
Therefore, instead of quering for group membership, could one instead query for the type of form being presented, and use this information to determine whether fields should be hidden / disabled?