Mandatory and read only fields after save

[scottjus82]

Hey all,

I now have a requirement to lock fields, make them mandatory and unlock depending on states and wondered what the best/quickest approach would be below is the flow and what locks/mandatorys are needed

When the phase is in definition nothing is mandatory. this is a draft phase and at this point the user can save, request 4 eyes check and delete the record. Once 4 eyes is requested all fields are locked down other than the one for the name of the 4 eyes checker and if its approved or not. Once approved fields are no longer locked and the majority of them become mandatory. I had thoght a simple UI policy would be fine but that makes fields mandatory as soon as the 4 eyes approves. They should only be mandatory once the change is saved as it will be someone else populating those fields. With the different locks,unlocks and mandatory s I wondered how others have done it. My initial thought was a hidden check box that ticks once 4 eyes is done I then base my UI policy on that tick box.

Any thoughts?

[Kalaiarasan Pus]

use a ui policy and have the conditions defined ...

try using state and any other fields that you could come up as per your requirement and current status of the ticket...

later make them mandatory, hidden . readonly

[harikrish_v]

Hi Steve,

I would back you on your first decision to do this with the help of UI policies rather than client scripts. Fact is, you will have to write separate policy for each scenario to gain the result.like this:-

1. Phase is definition:- no UI policy required as nothing is mandatory

2. 4 eyes is requested:-UI policy(order 200,reverse if false checked) Condition->State is 4 eyes only and Assigned to is javascript:gs.getUserID()->

                                                              UI policy actions for fields on table which will be Read only true, Mandatory and Visible will be Leave alone

I hope you got the idea

[Ajai S Nair]

Hi Steve,

I also back you on your first decision. Create a UI policy with these conditions defined and you can make mandatory, hidden or read only there.

Thanks & Regards,

Ajai

[scottjus82]

Hey,

Thanks for the reply's. The reason I am using a client script is there will be requirements for the same fields to be a different state (read only etc) when the state changes further down the workflow. When I set up the two UI policy's, one to set the states when the phase was "in Definition" and one when its in "implementation" They clashed and didnt work. The script option give me the if and else methods so I assume (and I could be wrong) that I can have all of my fields set in one script which will be easy to maintain going forward.

Please do correct me if you feel I am wrong. I am always open to opinion as this forum has been and continues to be a massive help.

Regards

[harikrish_v]

Hi Steve,

You can prevent UI policy clashes by making the conditions specific and ordering them properly(check reverse if false as suited, you dont need that always). But if client scripts are working for you at the moment, you should probably go with that.