I have a button on my form that I only want to show up if certain conditions are met. However, it never goes away.
Here is the button:
And here are the conditions, which if I am reading the data correctly, multiples is checked but Next Day is not equal to or less than Default Days, so I would expect the button to go away.
I added an ITE column to test the conditions and it is most certainly not checked, but my visibility condition is still being ignored (I can see the button)…
Are you changing either value whilst inside the edit form and expecting the button visibility to change?
I don’t think that will happen - because you’re in an edit form - and changes to the underlying table values will only be made once the form is submitted.
You might be able to use screen values, although I’m not 100% sure that would work. I’d need to test it myself.
The values are already set based on existing conditions – I added to my original post to see what would happen if I used a third column to test the conditions and the visibility is still ignored …
‘Next Day’ simply adds one to “Days”, which is a rollup counting a relation. “Default Days” is just an ITE that if a certain column does not contain a value, it plugs in the value of ‘9’.
Interesting. I can’t see anything obvious that would cause that not to work, but I suspect that I’m missing something.
Maybe Jeff will see this and spot the problem.
If I were to purely guess…I wonder if computed columns are being ignored while the form is open. Since the form essentially creates a temporary row separate from the table, it might not be executing the computed columns on that temporary row, so they may be empty underneath.
I guess you could add two additional basic columns to the table, then try to populate them using value column components in the form. Basically write the values of those computed columns to basic columns using the form. Then maybe the new basic columns would be recognizable with the visibility condition.
Another thought would be to use a custom action when opening the edit screen. The custom action would first write those computed values to basic columns, then you can see if those visibility conditions work with the new basic columns.
In either case, you may have to use screen values instead, but I’m not sure.
I suppose it’s not working because computed values could potentially change after an edit form is submitted, but the computations don’t occur until after a form is submitted, so it’s reasonable that computed value may not be fully accessible while you are inside a form screen. Again, just making a guess.
Well, I’d say this part is true, but in my case, one of the computed columns is a rollup of the number of related records – it does not get its value from the record being edited. The other computed column literally just sticks the value of a basic column or a ‘9’ if no other value is found in a basic column, so it’s not really reliant on the basic column in that regard. It will always be a 9 unless the basic column contains data.
I’m just thinking that whatever values I see in the computed columns in the ‘data’ pullup should be reflective of their actual value ‘under the hood’ so to speak. That doesn’t seem to be the case.
Adding the logic as you suggested is simply unnecessarily piling up edits in my App to supply values that should be available as computed columns.
Pretty sure this is the reason.
I understand that in your specific use case, those two computed columns are independent from what the form is allowed to change. Just saying that if you had entry components that affected the column used for the relation or a column used in the IF column, then it could potentially change. Just throwing out a theory as to why those computed columns may not technically be available.
There’s actually 2 of “this row” then… The row as it exists and the row as it’s going to exist… This is the 2nd indication to me that something has changed in the underlying logic of Glide. The 1st was when ‘this row’ stopped functioning as the target of the delete action. And now it seems that the computed columns are not available either.
And right away as I read that I realized that that’s not exactly true either. It may be that they’re just not available in the conditions. They’re definitely available in the actions. So is this a bug then?
If computed columns are showing up as an option, but not useful in any way, then I’d say it’s a bug.
If computed columns are showing up as an option, but shouldn’t be, then I’d also say it’s a bug.
