• State Not Answered
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 89 views
  • Users 0 members are here
Options
Related

Logged-in users cannot update their own Primary Location in Web Portal profile despite configuration and permissions

gsoto

We require that a specific group of five users be able to update their own Primary Location in their Main Data via the Web Portal profile (logged-in user profile settings).

These users regularly move between offices as part of their job responsibilities, and the Primary Location attribute is used to enable or restrict functionality in downstream systems based on its value. Therefore, it is a business requirement that they can self-manage this attribute.

To enable this, we have already performed the following configuration steps:

  • Added the Primary Location (UID_Location) field under
    Web Portal Configuration → Identity data → Properties logged in users can edit in profile settings

  • Created a custom permission group

  • Assigned this permission group to a custom application role

  • Assigned the five users to this application role

Despite this configuration, the users are still unable to modify their own Primary Location in the Web Portal. The field remains read-only or cannot be saved when edited.

The requirement is strictly limited to:

  • Users modifying only their own identity

  • No permission to change the location of other users

We would appreciate your guidance on:

  • Any additional permissions, object permissions, or column permissions required

  • Whether Primary Location is subject to special restrictions or policies

  • Any known limitations or best practices for enabling self-service updates of this attribute

Thank you in advance for your support and assistance.

  • 0

    Good question.

    P.s. There is no Person.UID_Location field this should be Person.UID_Locality ;-)
    And Person.UID_Locality is an OOTB property shown in the profile. So doublecheck this...

    Now the back story...

    OOTB every Identity can edit there own Person.UID_Locality via the object layer based on the permissions given by the permission group 'VI_4_ALLUser'
    Just give an Identity the following program function 'ApplicationStart_ObjectBrowser' and login with that Identity in the ObjectBrowser.exe and see for yourself.
    Now here's the kicker the apiserver sets the following properties to read-only (hard-coded):
    LastName, FirstName, DefaultEMailAddress, UID_PersonHead, UID_ProfitCenter, UID_Department, UID_Locality
    Reasoning for this being that changing these properties could potentially impact a lot of thing's as you can imagine.
    The only issue i've with this that it is not documented as far as I know.
    So why does an Identity get these permissions in the first place... I think this has something to do with the origin of the product and backwards compatibility.

    So what are your options:
    Option 1:
    Create an copy off 'VI_4_AllUser' to 'CCC_4_AllUser' remove the edit permisison for Person.UID_Location.
    Create an second group CCC_4_User_CanEditLocation and assign edit permisison for Person.UID_Location.
    Assign your users to 'CCC_4_AllUser' instead of 'VI_4_AllUser' 
    P.s. This is pretty advance stuff and should really only be used if you want to implement a least privilege model that starts on the lowest level the objectlayer.
    So not really an  option for this small use-case also take into account that you need to revisit this every time you add an module, update, upgrade or hotfix because that original permissions on the group 'VI_4_AllUser' and the other OOTB groups can always change!

    Option 2: 
    Create an table script (OnLoading) on the Person table to deny edit permissions on these attributes unless you have a certain
    permission group or program feature...

    If Not (Session.Principal.Groups.GetGroupNames()).Contains("CCC_4_User_CanEditLocation") Then
    Entity.Columns("UID_Locality").CanEdit = False
    Entity.Columns("FirstName").CanEdit = False
    Entity.Columns("LastName").CanEdit = False
    ...
End If

    Now, we still have that pesky hard-coded apiserver logic that sets these values read-only.

    Create your own custom plugin.
    CCC.CompositionApi.Server.Plugin.dll

     public void Build(IApiBuilder builder)
 {
     builder.ModifyQueryMethod("person/masterdata", method => {
         PropertyModifier propertyModifier = new PropertyModifier()
         {
             IsReadOnly = false
         };
         string[] strArray = new string[7]
          {
             "LastName",
             "FirstName",
             "DefaultEMailAddress",
             "UID_PersonHead",
             "UID_ProfitCenter",
             "UID_Department",
             "UID_Locality"
         };
         foreach (string key in strArray)
             method.Crud.Modifiers[key] = propertyModifier;
     });
 }


    ../portal/person/masterdata
    look at the json resonse 

    OOTB:
    "UID_Locality": {
    "Value": "",
    "IsReadOnly": true
    },

    After custom plugin:
    "UID_Locality": {
    "Value": ""
    },

    That it now you are back in the driving seat and have control over these properties.
    P.s. i'm not an Quest employee nor a partner and think carefully if this use case is worth the touble and test test test!!! consult your IAM Partner or Quest Support.

    HTH!