Set Tab visibility from frontend function

rfernandez

Hi,
I need to hide or show certains Tabs of a Tab object depending on values of the data fields.
Is there any existing function to do this?

Otherwise, how do I achieve this?
It is crucial to my use case, as I need to be sure that all the required fields of the first tab have been filled before showing the second and subsequent Tabs.

Thank you!!

gabriel

This is easy to do with form states.

Set the tab in question to 'hidden' in field settings for the tab field.
Define a form state that, if all required fields are filled out (ie. multiple AND conditions), change the tab state to 'default' (ie. 1 effect).

rfernandez

Hi Gabriel,
This worked fine! 👍
However I found a new related challenge. (in fact two, but lets go one at a time 🙂)
Let me describe the scenario (related to another question I posted and already answered)
I hope my detailed descriptions if the scenarios do not bother you. 🤞 If they do please let me know.

I have an entity which data is represented in a series of tables joined by a one to one relationship.
In the Form I have one tab for each of the tables.
Depending on the type of the entity (which is something you should select in a field) I need to show one of two different tabs. The types are Discreta or Masiva.
To chose the type of entity I have a table that defines the entity types and I have a relation field in the Form to chose one of them: (I retrieve the name of the type)

enum_sequence_type.sequence_type is a Text. And the options are Discreta or Masiva

I already have a working Form state that checks all the required fields have been filled before showing any other tab. If I add the last condition to that Form state it does not work (as if it were not recognizing the value selected)

And whis this new condition the action for the Form state, which is to show the tab corresponding to Masiva does not work.

However if instead of using this relation field I use a simple text field I temporarily added to the main relation (which is by no means the way to go, as the user can make typos or write any other thing), it works!! and if I write Masiva in the text field, it shows the corresponding tab.

Further investigation took me to discover that the value that the Form state will take as valid in the case of the relation field, is the id of Masive which is the number 2, and not the text. However in the field I retrieve the text and that is what is shown in the form.
Could this be something to improve/correct?

Thank you!!!

gabriel

rfernandez Further investigation took me to discover that the value that the Form state will take as valid in the case of the relation field, is the id of Masive which is the number 2, and not the text. However in the field I retrieve the text and that is what is shown in the form.
Could this be something to improve/correct?

A relationship input field is there to fill a relationship value (which is an ID). Using a name, or any non-ID value, as the value of an relationship field would not be helpful, as relationship fields are there to resolve records; names do not need to be unique, so filters like F8 = Masiva cannot guarentuee that the correct record is selected.

What you actually want, is to check, if the correct record is selected. For records that serve app logic (like for showing/hidding stuff on your form), you should use presets - which you probably do already. Once you have created presets, you can check for them in the filters directly (F8 = preset record: Masiva). This filter condition guarentuees that the correct record is selected, regardless of names (which could be renamed or exist multiple times).

rfernandez So, I know it is a kind of odd/defying situation, but I will really appreciate suggestions on any workaround or creative solution to avoid having to do a dirty patch

It´s a basic requirement - not odd at all. You just don´t know how to address it yet. If you have an 1:1 extended relation on the same form, but no values are set as default or by the user, the relation record will not be created. If you need the inputs filled in some cases, you use form states to make the relevant fields required in these cases.

This of course only works, if the relations are 100% cleanly separated. As soon as you fill a single value for an extended relation, its record will need to be created. As long as your form states are cleanly making stuff optional / required, based on what the user should fill out, you will not create unnecessary records.

Btw. even using form states, a required field will show a message and block saving if left empty - even if the field is not required by default.

rfernandez

Now, adding the second situation I previously mentioned. (this all comes from the customer's sort of twisted requirements)

The fact that , depending on the type of entity, I show/fill one tab or another, leaves me with the following situation:
All the relations have requiered fields by definition (defined as required in the relations), if I ommit entering the data in one tab with required fields the Form won't allow me to Save. Also, by default even if there were no required fields I would be saving records in tables that do not require that record (for example if the relation is Masiva I need to save I record in the relation Masiva, but there is no need to save a record in the table Discreta, as they are mutually exclusive)

For the requiered fields issue, I can mark the fields as not required in the relations, but that will defeat the purpose of the conceptual definition. Not to mention that the field will not trigger any message or any of all the very useful behaviors that happen in the Form when a field is required and is it not filled.
Or
I can think of other solutions, however they all seem kind of dirty and forced (like filling these required but not visible fields with something, under the hood;, with perhaps a frontend function. Here the problem is that some of them requirie specific values selected from lists with values read from other tables)

So, I know it is a kind of odd/defying situation, but I will really appreciate suggestions on any workaround or creative solution to avoid having to do a dirty patch 😄, and to avoid (if possible) saving records in relations, for relationships that actually do not exist, as if there is a Masiva relationship there won't be a Discreta relationship with the Discreta relation, related to the same main entity.

Thank you very much!!

rfernandez

Hi gabriel,
Thank you very much for your answer!!

A relationship input field is there to fill a relationship value (which is an ID). Using a name, or any non-ID value, as the value of an relationship field would not be helpful, as relationship fields are there to resolve records; names do not need to be unique, so filters like F8 = Masiva cannot guarentuee that the correct record is selected.

What you actually want, is to check, if the correct record is selected. For records that serve app logic (like for showing/hidding stuff on your form), you should use presets - which you probably do already. Once you have created presets, you can check for them in the filters directly (F8 = preset record: Masiva). This filter condition guarentuees that the correct record is selected, regardless of names (which could be renamed or exist multiple times).

I understand, and even agree on the risks of not using presets, and the benefists of using them.
Regarding uniqueness, I made sure of that using a unique index in the relation. Cant say the same about someone changing the text afterwards. It's a matter of choice, I can block changes through presets, or leave it to the data administrator's responsibility. I'll present the case and wait for feedback.

On the other matter:

It´s a basic requirement - not odd at all. You just don´t know how to address it yet. If you have an 1:1 extended relation on the same form, but no values are set as default or by the user, the relation record will not be created. If you need the inputs filled in some cases, you use form states to make the relevant fields required in these cases.

This of course only works, if the relations are 100% cleanly separated. As soon as you fill a single value for an extended relation, its record will need to be created. As long as your form states are cleanly making stuff optional / required, based on what the user should fill out, you will not create unnecessary records.

Btw. even using form states, a required field will show a message and block saving if left empty - even if the field is not required by default.

The problems is compound, from 3 different types of sub-entities, that are part of the extended relation, and that reside in 3 different relations in the database, I must allow the user to enter the data of only one (the first one selected by the user using a display list), and the other relations shouldn't add any record related to that main entity.
If I understood what you said, that might work by default if no field of the other relations is entered. Also provided there is no mandatory fields in any ot these 3 relations, at relation level,
What I havent figured out yet is how to freeze the selection to prevent the user to change the original selection and fill a second relation data, which will override the restriction. I think I could change the state of the field to read-only after the first change of the field, but I'm not sure because if the user simply made a selection mistake, it might imply not being able to save the whole 60 field record, and to have to start from scratch (they will hate me 😄)
I'll give a thought and a try, and let you know. (and probablly also explain the situation to the user to get his point of view)

Thank you!!

rfernandez

Ok.
Findings:

The Tab visibility change works using Form States. ✅
Freezing a selected value works using Form States by making the field read-only (although there is still the fact that once selected forces you to re-enter all the Form in the unfortunate case you made a mistake in the selection) ✅🟨
Required values at relation level cannot be overriden by making them not-required at Form level. Which is completely logical.

PROBLEM:

Depending on the selected entity type, the tabs I hide might have required values at relation level, so in some cases I'll never be able to save the Form, because there will be empty required values. ❌

Solutions:
1. Make all the fields at relation level optional.
Defeats the purpose of having that characteristic defined in one place, and forces to make it required every time you use it. Not to mention that if accessed from outside the application could cause data inconistencies. So, no.

2. Programmaticaly fill the required values before saving the record.
From what I saw that can only be done from the Functions tab of the Form (not available in Form States). This might work, however it will end saving records for all 1:1 extended relations (defeating the purpose of not having to do so when no information should go there), and might cause future data problems is seen from out of the scope of the application. Besides if any of the values has a unique condition, that will require a more elaborated filling algorithm.

3. Define defaults for all required fields at relation level
That looks fine, except for the fact that some of those values trigger actions at Form state level, so if I create a new record with a default value "Masiva", it will immediately turn the field read-only not allowing me to chose anything else.

4. Enable record automatic selection for the field that selects the type of entity.
Same problem that 3.

Any suggestions, on how to solve this in a more elegant/practical way will be much appreciated!!

Thank you!!!!

gabriel

You do not have to loose the "required" constraint on your attributes (ie. on relation level), even in this case.

For all input fields that come from an optional, extended relation, set the field state to either "hidden" or "optional" (via form state or as the default field setting) - regardless of whether they are required or not. This will cause r3 to ignore these fields if no values are set. As long as not a single value of the corresponding relation is filled, r3 does not attempt a save on this relation and the "required" constraint is not broken.

Then, depending on type, apply the field state "default" to relevant fields via form states. "default" will make fields mandatory if their attribute is required, otherwise they stay optional.

The only downside: If your users first set type A, fills in fields from one optional relation and then switches to type B (which uses a different relation), the already entered values are still there, potentially causing a constraint error and producing an undesired record to be created. To address this case, you have 2 options:

Either force users to stay on one type, not allowing them to switch afterwards.
Reset the field values to null if the type switches - this is possible via a frontend function.

rfernandez

Hi Gabriel,

I'm working on this, and re-reading your solution word by word a doubt arises.
The extended relations could be optional or mandatory, depending on whether you define the FK as "must have value" or not.
When you say "For all input fields that come from an optional extended relation", that means that this solution will work only if the extended relation is optional? And consequently if the relationship is defined as mandatory this will not work?

I ask the question because in each of the extension chains, that is, the relations that I will have to fill through the Form depending on the value I input for a certain field, I will have both mandatory and optional relationships.
I hope the doubt is clear enough.

Thank you!!

gabriel

With optional relation I mean a relation that you might not want to create a record for. This relation can have mandatory attributes (setting "must have value").

Your case was that you had a number of relations joined as 1:1, with only some of them needed, depending on some criteria. This means that all relations that are not needed are "optional". If not a single attribute value is set (via field on a form), the record for this relation is not created. In this case, the mandatory check for attributes is not relevant. Only if a record is created on a relation, all mandatory attributes must have a value.

To make this happen, you need to tell the form (via form states) that some input fields are optional (or hidden, depending on your need). If that is set, the form will not ask for these inputs. Only if your criteria matches, certain fields for the corresponding relations are set to "default"; this will let the form know to show fields from mandatory attributes as "required" (ie. shows the little star and blocks saving if empty).

Please test this out, it takes a couple of minutes to create a form with 3 relations (1 base relation, 2 1:1 relations), a couple of input fields (from all relations, set to "optional") and form states (setting fields to "default" from one of the 1:1 relations based on some condition). If you have issues during the test, we can look at them.

rfernandez

Please do not misunderstand me. I did tested it out. I was just trying to get things as conceptually clear as possible.
I did a simple test, and it worked.
Then I did it with my current data model, because a simple test with a few tables/fields wouldn't reflect the complexity of my data model,.
Unfortunately the test with my model didn't work.

What did work: the form stopped showing the "Required input" message.

What did not work:

When pressing the Save button after filling everything and no red fields in the Form, it asked for other fields that must had values. Seemed like something at database level. I solved it temporarily by setting some FKs form other relations pointing at the optional relations as not required in those relations. Odd, but for now it is working. I'll go back to that when I got everything else working to see if I can reproduce the problem and find an explanation.
Although I had hidden all fields in one of the optional relations, the record was still created.
I think the problem was that the relation has a couple of Yes/No fields for which I had set default values.
Once I deleted the default values at relation and Form level, it stopped creating the record in the optional table.
For now I assumed that this was the cause, although have to do some additional checks.

I still have to run several more tests to make sure my assumptions are correct.
But ... there is progress!!, although it wasn't as easy as it seemed in the simple test.

Please let me know if you think any of my conclusions are wrong.
I'll keep you updated once I complete the configuration for the other optional tables, and run some more tests.

Thank you!!

gabriel

rfernandez Please do not misunderstand me. I did tested it out. I was just trying to get things as conceptually clear as possible. I did a simple test, and it worked.

It´s not possible to know what you did, unless you write about it. If someone trying to help you, is asking you to do/test something, please always at least acknowledge that you did or did not do it. Otherwise it´s guesswork - and this wastes a lot of time.

rfernandez Odd, but for now it is working. I'll go back to that when I got everything else working to see if I can reproduce the problem and find an explanation.

That would be interesting, please let me know if you find anything.

rfernandez I think the problem was that the relation has a couple of Yes/No fields for which I had set default values.

Yes, defaults will cause this issue. If there is any value set, default or otherwise, the record will need to be created and then constraints must be correct.

rfernandez

Hi,
I've been able to reproduce the problem that prevents the Form from saving if any of the hidden fields is requiered at relation level.

The error comes from the database, and points to a specific table attempting to write null in a required value. Why? if all fields including the one mentioned in the error are hidden.

And the culprit was again the default value in a Yes/No field.
The annoying thing is that this particular Yes/No field was in another relation, not the one throwing the error.
However, apparently it was forcing all the chain of related relations (all the extensions of the main entity) to attempt saving to the database.

Is this right? wrong? just the way it is?
I can't tell.
What I can tell for sure is that at this level of complexity (unless you have a deep knowledge on internals of the platform's behavior) only a brief moment of extreme mind clarity can lead anyone to hit the solution. I was just lucky enough. 🤯 😅

gabriel

rfernandez Is this right? wrong? just the way it is?

This makes sense. If multiple relations are joined on a record manipulation form, if there is any value set on a joined relation, all previous relations in the chain must have a record. Otherwise nothing could be created, as the existence of the record with the value, depends on the relationship to the previous records (because of the joins).

I would not have thought of this issue on the top of my head, but it it´s a logical consequence. Thank you for testing, finding the root cause and taking the time to report it.

In your case, it might be annoying that you have to check all fields for default values - but it should not invalidate your approach. From a data perspective, it makes sense that the relations in the chain must exist so that relationships between them can be created - once your defaults are clean, you should be good to go.

rfernandez What I can tell for sure is that at this level of complexity...

Definitely true. That is mostly due to the burden of flexibility. Many low code tools do not allow multi-relational records, with optional, extending records being created (or not) based on conditional criteria. In most tools, you would have to place all your fields on a single relation and say goodbye to many checks / constraints. It would just not work and for many that´s good enough - with workaround doing heavy lifting for more complex requirements.

In r3 you can build just as simply - but you can also build complex structures, as long as you can reason about it. r3 rarely invents something new, it just exposes more options to the application author to allow for more flexibility. This definitely is more complex. And while we can do a better job with our UIs & docs, some of this is just the price to pay for having these options in the first place.

rfernandez

gabriel
Thank you very much for following up the conversation, and for your kind comments!
I'm really glad my efforts might be of even a tiny help for other people being able to continue doing amazing things with r3.
As for me, although I now there is sooo much to learn yet, I'm feeling more confident and comfortable with the platform, and I'm being able to build more interesting things I never thought I could.
So, thank you very much for your great work!!!