If is_a_widget = 1 then selecting a Widget is mandatory and Foobar is disabled
If is_a_widget = 0 then selecting a Foobar is mandatory and Widget is disabled
After Submit the is_a_widget check mark and only one of the fields should be visible. All should be read-only.
Ironically, I just ran into something similar. The mandatory means the field is occupied, no matter what.
My scrappy solution was to not make the fields mandatory and use set_df_property in the JavaScript instead. As the form is loaded, refreshed, and changed, the JavaScript will do the following on my field:
frm.set_df_property('myfield', 'reqd', 0); // I'm assuming 'reqd' means "required".
Along with a frappe.throw on form validation to show an error, this is the best I could do. Keep in mind this only works if editing documents through the normal Frappe DocForm.
(My original error was thinking the condition was described in SQL, so I was using single ā=ā. Your example made me wake up. Thanks for that.)
This is weird. So ERPNext provides a great big expandable text box āMandatory Depends Onā so you can enter very detailed conditions that will never have any effect 'coz the field will always be mandatory anyway? Reminds me of Kurt Vonnegutās troop ship to Neptune, where the cockpit has only a big red STOP button ⦠so the troops āfeelā like theyāre still in control.
I was thinking that that would be the case if the database table attribute was defined as āNOT NULLā, but I checked and it isnāt.
My learning path for ERPNext has simply taken me from bug to the next bug to another bug. Wasting time and more time and yet more time. Itās a mine field! It really is!
Iām working on commissioning my first ERP site, and reckon by going for Ubuntu 20.04 LTS and ERPNext v13 I ought to get a couple of years run before having to face upgrading. But, then the down-side of a brand new platform is the lack of guard rails, right?.