Skip to main content
N
Neeraj_Jain1-Visitor
1-Visitor
November 18, 2017
Question

W&D: Restricting Editability / Relevance of Standard Fields like Shared Category etc.

  • November 18, 2017
  • 3 replies
  • 1979 views

In Workflow & Documents, Is there a way to restricting Editability / Relevance of Standard Fields like Shared Category.

 

The requirement is to allow the setting of Category value only in draft state. Once it moves from Draft state, no one should be able to change the category value.

 

The Editability & Relevance tab is not visible for standard fields as well on the 'Override of Fields' on the Type.

I tried playing with constraints too but it did not helped.

 

One way I can think of is calling a trigger to abort when someone changes category value. But I want to avoid customization. Appreciate any help.

3 replies

V
VolkerEckardt17-Peridot
17-Peridot
November 18, 2017

Hello Neeraj,

in our project we did a deep analysis how the standard document editablity functionality can help us. We came up with the result that the node status can not be added to the editability of the category.

Finally, we found out only one way: using constraints.

 

Let me explain:

The Constraints will make sure that when the state is != Draft only the current Category can be selected.

First, you add a new field to the nodes, and call it "Category ID". For it you use a small trigger to place the selected Category ID, when its changed. (it has to be done that way with a new field, otherwise the constraint will not work)

Then, you add rule constraints, one for each Category value. The rule says for example: if Category ID = 10 then allow in the Pick list for the Category only "Functional Requirement", if its 20, then allow only "Technical Requirements" and so on. So finally you end up with

a) a very small trigger

b) as many constraints as you have defined Categories for your node.

 

It works well: as soon as the node is "In Review", the Pick list will be limited to the value which is already selected, so no more changeable. Constraints are immediately analysed, so if the user changes the State back to "Draft", the full list of Catogory values appear again.

Hope my description is good to understand.

 

Is this something you would like to try out?

Volker

PS: The Category ID could also be the full name, for example "Category Name", perhaps its better for the maintenance. Then, you dont have to deal with the internal numbers. 

 

    V
    VolkerEckardt17-Peridot
    17-Peridot
    November 18, 2017

    Hello Neeraj,

    in our project we did a deep analysis how the standard document editablity functionality can help us. We came up with the result that the node status can not be added to the editability of the category.

    Finally, we found out only one way: using constraints.

     

    Let me explain:

    The Constraints will make sure that when the state is != Draft only the current Category can be selected.

    First, you add a new field to the nodes, and call it "Category ID". For it you use a small trigger to place the selected Category ID, when its changed. (it has to be done that way with a new field, otherwise the constraint will not work)

    Then, you add rule constraints, one for each Category value. The rule says for example: if Category ID = 10 then allow in the Pick list for the Category only "Functional Requirement", if its 20, then allow only "Technical Requirements" and so on. So finally you end up with

    a) a very small trigger

    b) as many constraints as you have defined Categories for your node.

     

    It works well: as soon as the node is "In Review", the Pick list will be limited to the value which is already selected, so no more changeable. Constraints are immediately analysed, so if the user changes the State back to "Draft", the full list of Catogory values appear again.

    Hope my description is good to understand.

     

    Is this something you would like to try out?

    Volker

    PS: The Category ID could also be the full name, for example "Category Name", perhaps its better for the maintenance. Then, you dont have to deal with the internal numbers. 

    V
    VolkerEckardt17-Peridot
    17-Peridot
    November 20, 2017

    Hello Neeraj,

    in our project we did a deep analysis how the standard document editablity functionality can help us. We came up with the result that the node status can not be added to the editability of the category.

    Finally, we found out only one way: using constraints.

     

    Let me explain:

    The Constraints will make sure that when the state is != Draft only the current Category can be selected.

    First, you add a new field to the nodes, and call it "Category ID". For it you use a small trigger to place the selected Category ID, when its changed. (it has to be done that way with a new field, otherwise the constraint will not work)

    Then, you add rule constraints, one for each Category value. The rule says for example: if Category ID = 10 then allow in the Pick list for the Category only "Functional Requirement", if its 20, then allow only "Technical Requirements" and so on. So finally you end up with

    a) a very small trigger

    b) as many constraints as you have defined Categories for your node.

     

    It works well: as soon as the node is "In Review", the Pick list will be limited to the value which is already selected, so no more changeable. Constraints are immediately analysed, so if the user changes the State back to "Draft", the full list of Catogory values appear again.

    Hope my description is good to understand.

     

    Is this something you would like to try out?

    Volker

    PS: The Category ID could also be the full name, for example "Category Name", perhaps its better for the maintenance. Then, you dont have to deal with the internal numbers. 

    Terms & ConditionsAccessibility statement