Skip to main content
M
MS_99904226-Contributor
6-Contributor
October 19, 2022
Solved

Lock Editability based on Item State for Item Fields without Editability Tab

  • October 19, 2022
  • 3 replies
  • 2371 views

Hello all,

 

We've come across fields without an "Editability" Tab, where we need to lock the field's editability dependend on the item's state. How do we do that?

 

In our system there is a field "Category" with the type "fva" where the Relationship is "References" and the Field is "Shared Category". The field "Shared Category" is from type "pick".

 

This field "Category" is visible on an Item "Input". What I want to achieve is that if the "Input" item is in State "Released", the field "Category" shall not be editable.

 

Normally, within the "Input" Type I can override the editability for a field within the "Editability" tab... but it is missing?!

 

MS_9990422_0-1666170360243.png


Why is it missing and how do I accomplish that it is read-only dependent on the item's state?

 

Thanks and kind regards,
Michael

Best answer by kjain2

Hi @MS_9990422 ,

Have you tried these 2 properties "MKS.RQ.Editability.1" and "MKS.RQ.Editability.Document.1". Allow Edits and Valid Change Tasks are such attributes controlled by them. So, let's stick to Allow Edits you can write your "State != Released" in computation rule and this can be a quick solution for you.

If this doesn't work then as other also recommended trigger is also a solution which is also going to be small script hardly 10 lines depending on how deeply you write logging or you can use OOTB abortScript.js which is way fast solution without writing any code. Just create a trigger with your required rule and use this OOTB script and just add beautiful prompt message for user and it's done.

Feel free to ask further questions.

Vielen Dank / Many Thanks,
Kapil Jain

3 replies

L
LLawton16-Pearl
16-Pearl
October 19, 2022

Hello,

This field is part of the "document model" and PTC decided many years ago to remove editability and relevance rules for such fields. It doesn't make any sense to me, my guess is that they thought they would prevent users from making mistakes.

In any case, I too have searched and searched for a solution and cannot find one. Except using a trigger to block such edits, but that's ugly of course.

My own solution at this point is to let my users make mistakes. I wonder if you could create your own Category/Shared Category field combination and hide the other one away (you can't remove it), but I don't have time to test that.

I'm curious too and I'd like to know if someone has come up with a solution.

    M
    MS_99904226-ContributorAuthor
    6-Contributor
    October 24, 2022

    Upon an e-mail requesting the current status of the issue:

    We have not come across an answer why specific "built-in" fields do not have an editability tab yet. We have implemented a trigger for such fields which prevents any user edits.

    K
    kjain214-AlexandriteAnswer
    14-Alexandrite
    October 26, 2022

    Hi @MS_9990422 ,

    Have you tried these 2 properties "MKS.RQ.Editability.1" and "MKS.RQ.Editability.Document.1". Allow Edits and Valid Change Tasks are such attributes controlled by them. So, let's stick to Allow Edits you can write your "State != Released" in computation rule and this can be a quick solution for you.

    If this doesn't work then as other also recommended trigger is also a solution which is also going to be small script hardly 10 lines depending on how deeply you write logging or you can use OOTB abortScript.js which is way fast solution without writing any code. Just create a trigger with your required rule and use this OOTB script and just add beautiful prompt message for user and it's done.

    Feel free to ask further questions.

    Vielen Dank / Many Thanks,
    Kapil Jain

    M
    MS_99904226-ContributorAuthor
    6-Contributor
    October 28, 2022

    Hi kjain2,

     

    thanks for your answer.


    I've played around with the 2 properties "MKS.RQ.Editability.1" and "MKS.RQ.Editability.Document.1" because naturally, from the description of the properties they should accomplish exactly what we wanted. The problem was, that the edibaility of a field if blocked by "Allow Edits" or a Custom Computed Field is only locked in the inline editor (if you edit a node within a segment). As soon as you open the node within a seperate editor (STRG + E or Right-Click -> Edit Item...) you can edit any fields regardless of any MKS Property.

     

    Thanks for your comments on the trigger. I have already implemented one. Obviously, he is neither long nor complicated, but a trigger is always the worst user experience and we try to avoid them as much as possible.

    K
    kjain214-Alexandrite
    14-Alexandrite
    November 15, 2022

    Hi @MS_9990422 

    Just wondering, after opening node within a seperate editor (Strg + E or Right Click -> Edit Item), after editing value, you tried clicking on Apply. Does server allows you to save the information? 

    As far as i know you should get an strange error message after clicking on apply. (Not before that)

    Vielen Dank / Many Thanks,
    Kapil Jain

    Terms & ConditionsCookie settingsAccessibility statement