Is it possible to use a rule with PROTECTthat stops protecting the attributes when the condition no longer holds? If so, how would this be written?
I would like to protect a BO/query/form from being edited while a process is running on another BO. When the process is running an attribute in this other BO is empty (undefined). When it's all done, the attribute is noe longer empty, but contains a timestamp. At this point I would like the PROTECT to go away
Remove PROTECT when condition no longer holds?
Re: Remove PROTECT when condition no longer holds?
This IS how the PROTECT rule works by default. If you have rule "If Bo.Attribute=1 then PROTECT Bo FROM ALL", the PROTECT rule then only applies when the condition (Bo.Attribute=1) is met.
Henrik (V8 Developer Ed. - Windows)
Re: Remove PROTECT when condition no longer holds?
Thanks, that's what I thought, but I think I'm doing something wrong, since it protects all wheter attribute is 0 or 1. But it might be because of the different BO's? I have "IF BO1.Attribute=0, then PROTECT BO2 FROM ALL", but if this attribute wasn't "avalilable" for the rule, the protect should not work, as it does. It just doesn't stop working. I might add that the timestamp set in this attribute is done by background pakages and agent jobs running on the server. It might make it more difficult for the rule to work like it normally would?
-
- Posts: 1462
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Remove PROTECT when condition no longer holds?
You can only protect a BO based on its own attributes.
Code: Select all
IF BO.Flag=1 THEN READ PROTECT BO.Secret
IF BO.psRelatedBO.Flag=1 THEN READ PROTECT BO.Secret
Re: Remove PROTECT when condition no longer holds?
Okei, thanks, that explains it then
-
- Posts: 1462
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Remove PROTECT when condition no longer holds?
Be mindful that running PROTECT and READ PROTECT will slow queries down if you have lots of BOs because the query stops working as a set and instead each record gets checked to ensure PROTECT compliance.
Re: Remove PROTECT when condition no longer holds?
Okei, thanks for the tip, good to know!
Re: Remove PROTECT when condition no longer holds?
Followup question here: This last code snippet indicates I can use a shortcut, is that correct? Will the system be able to pick up if the shortcut attr has a value or not?PointsWell wrote: ↑Fri Jan 05, 2024 7:33 am You can only protect a BO based on its own attributes.
Code: Select all
IF BO.Flag=1 THEN READ PROTECT BO.Secret IF BO.psRelatedBO.Flag=1 THEN READ PROTECT BO.Secret
-
- Posts: 1462
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Remove PROTECT when condition no longer holds?
No, you need to use the full path from memory. Test on a very simple BSV.lueu wrote: ↑Mon Jan 08, 2024 10:21 amFollowup question here: This last code snippet indicates I can use a shortcut, is that correct? Will the system be able to pick up if the shortcut attr has a value or not?PointsWell wrote: ↑Fri Jan 05, 2024 7:33 am You can only protect a BO based on its own attributes.
Code: Select all
IF BO.Flag=1 THEN READ PROTECT BO.Secret IF BO.psRelatedBO.Flag=1 THEN READ PROTECT BO.Secret