Can we set Activity Fields as Read-Only for Approvers?

David_DarlingDavid_Darling Customer IT Monkey ✭

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

Answers

  • Brett_MoffettBrett_Moffett Cireson PACE Super IT Monkey ✭✭✭✭✭
    You could achieve this at the moment with custom JS code.
    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.
  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    edited November 2016
    Hi David,

    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
    $(ctrl).hide();
    to
    $(ctrl).attr("disabled","true")
    Geoff
  • Adrian_SaloneAdrian_Salone Partner IT Monkey ✭

    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?

  • Geoff_RossGeoff_Ross Cireson Consultant Super IT Monkey ✭✭✭✭✭
    Adrian, the form presented depends on whether the user is an analyst if not - determined by if they are a member of the analysts AD groups specified at installed time.
Sign In or Register to comment.