UI Action vs relevant Business Rule ... how to set order correctly?

[Zod]

HI,

somehow I stuck.

I have a Business Rule that need to check if field A or field B is set. Both is ok. This is relevant if status is INSTALLED.

Now I do have a UI action that will DEINSTALL the record - meaning setting all field values to blank and the status to DEINSTALLED.

Now the Business Rule is blocking the UI Action to be executed, as the status still is INSTALLED when trying to execute the UI ACTION.

Important is, that I need the system to only have ONE Update to be done ... so changing the state first and changing the values of the fields in a second step is no option due to automatic updates that need to be triggered in one step due to legacy system ...

I think this a minor issue I'm not aware of to solve this issue ... . As the issue is a little bit more complex that I'm describing here .. I'd like to somehow stick to the BR and anyhow run the UI Action ...

thank you

[Goran WitchDoc]

This doesn't make sense, since you are setting the status to deinstalled, it won't be installed when before br hits.. just like the fields are empty, the status change is "changed" as well..

[DrewW]

There is something wrong with your Business Rule.   With out seeing it I cannot say what that may be.

[Zod]

BR is ok. I found the issue. Its that the status can not be changed by the user due to ACLs.

But the user should not change the status - except using this UI action ...

Any idea how to make an ACL exception if it is done via UI Action?

[DrewW · Accepted solution]

Sounds like this is a client side UI Action then, and I see from your code that this is correct.   You need to change the UI Action to run on the server side.   This will allow the code to do what it needs regardless of ACL's.

You will not be able to do a confirm as you currently are.

The other option that you have is removing the ACL and adding a UI Policy to make the field read only.

[Zod]

Yes - jsut found that out too 😉

Using the UI Policy way now 😉

Thank you