I need a work around.
Combo Box attributes (peer single relationships in this case) cannot have presentation rules.
I have a Contract that can be sold internally by a person or externally by another company.
I have different BO for People Contacts and Company Contacts and have created a BOG called SalesPeople.
People Contacts have psEmployer relationships, but Company Contacts do not, so that attribute does not show up in the BOG.
The filter became too unmanageable to use a single Sold By field populated with the BOG SalesPeople. So I reverted to putting a switch on the form and a hide rule based on the switch value Internal/External sale which shows the peer relationship for internal staff or external agents.
This works quickly and is tidy.
But now I can't get the Required flag to show because there are no presentation rules on Combo Boxes... The BO is generating the required error on the field that receives the Person or Contact but it just doesn't show correctly in the UI because the fields are being faked.
I could set the both the input fields to be required, but then the form will never save because it can't be both externally sold and internally sold...
Complex BOG Query
Re: Complex BOG Query
The only thing I can think of is using READ PROTECT in update rules if you want to use two different relations instead of a group.PointsWell wrote: ↑Fri Sep 24, 2021 6:16 am I could set the both the input fields to be required, but then the form will never save because it can't be both externally sold and internally sold...
I have a similar situation on an app running v 8.4, but in my case it is two plain text attributes instead of two relations.
The reason it works for us to save is because the required check will not run if the field is read protected. I hope this makes sense and I hope it will work the same way for relations.
Example:
Code: Select all
If Bo.InternalSale='Yes' Then
READ PROTECT Bo.ExternalRelation FROM ALL EXCEPT System
Code: Select all
If Bo.InternalSale='No' Then
READ PROTECT Bo.InternalRelation FROM ALL EXCEPT System
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Complex BOG Query
Yes this is exactly what I have done to show hide the fields. The user has no indication though that the SoldByInternal/SoldByExternal is mandatory.joben wrote: ↑Fri Sep 24, 2021 6:40 amThe only thing I can think of is using READ PROTECT in update rules if you want to use two different relations instead of a group.PointsWell wrote: ↑Fri Sep 24, 2021 6:16 am I could set the both the input fields to be required, but then the form will never save because it can't be both externally sold and internally sold...
I have a similar situation on an app running v 8.4, but in my case it is two plain text attributes instead of two relations.
The reason it works for us to save is because the required check will not run if the field is read protected. I hope this makes sense and I hope it will work the same way for relations.
Example:
And also the reverse rule:Code: Select all
If Bo.InternalSale='Yes' Then READ PROTECT Bo.ExternalRelation FROM ALL EXCEPT System
Then make sure this rule executes instantly when switching between Yes and No. There is an option on the yes/no attribute for saving form on change. Might also work by making the rule dynamic, or a combination. I can't recollect right now exactly how I got it to work in my somewhat different scenario on a somewhat earlier build.Code: Select all
If Bo.InternalSale='No' Then READ PROTECT Bo.InternalRelation FROM ALL EXCEPT System
-
- Posts: 1460
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Complex BOG Query
Works in my scenario where I have plain text attributes.PointsWell wrote: ↑Fri Sep 24, 2021 8:24 amThey can't both be required as it is an either or on which would be populated.
The READ PROTECT prevents the required check from ruining the save form action.
Might not be applicable in your scenario though. I havn't tried this in latest build or with relation attributes.
I will see if I can reproduce this later today.
Re: Complex BOG Query
I have to correct myself.
The required field check cannot be bypassed.
Turns out I had used conditional REPORT ERROR actions, which means the attribute labels will not have the required asterisk symbols (*), which might mess up the UI a bit if that is important.
The required field check cannot be bypassed.
Turns out I had used conditional REPORT ERROR actions, which means the attribute labels will not have the required asterisk symbols (*), which might mess up the UI a bit if that is important.