Restrict profile fields to be not editable for non admins

Hello all,

we want to create profile fields to be not editable for non admins. For example we created a field ‘company’ that gets filled by data out of an xml file. This field should not be editable. I read that fields that have xml file as source cant be edited by users but our users are still able to edit them.

We need urgent help please.
Thank you for your help.

Best Regards,
Pascal Stephan

Hello Pascal,

thank you for your question! When a field is imported from a XML file, it can not be edited by the user for which the field was imported. That also applies, when there is no value given in the xml entry for the field. If there is no entry for the profile field in the users xml at all, the user can still edit the value.
So if the XML tag is empty we assume this is intentionally and there should be set an empty value. If the XML tag for a user is missing, we assume that no information for this user exists and the user should fill it in themself.

In our documentation we included an example and the explanation further explains these edge cases.

Best regards,
Robert Krause

1 Like

Hello @rkrause ,

In our initial import the fields are restricted to edit. But when the second import at the next day is running the profile fields are editable again. That is also when i start the import manually the second time.
I don’t change anything at the xml file. When i change a value the user with the new value cant edit this field. But i want the field always be restricted also when there is the same value as already in the user profile. In our test environment it is working like that.

Best Regards,
Pascal Stephan - init SE

I also used the exact same xml file in test environment and our productive system. In test environment i can import as often as i want. The profile fields stay restricted. In productive environment after the initial import the profile fields are restricted, after the second one i manually initiate or wait for the scheduler the profile fields are editable again.

In our productive system we are on linchpin intranet suite version 5.2.4. In the test environment on version 5.1.4

Hello Pascal,

that does indeed sound like a bug. Please head over to our support team, so we can further analyze this issue.