Bug? Definitely not intuitive behavior. I ha...

[Steven_Coile]

Bug? Definitely not intuitive behavior.

I have the following columns within a single table:

[email] Type: Email Editable_if: =false Initial value: =useremail()

[view_guts?] Type: Yes/No Initial value: =false

[guts_part] Type: Show Category: Page_Header Show_If:

=and([is_me?], [view_guts?])

[is_me?] (virtual) App formula: =in(useremail(), list([email]))

The idea is that the display of the [guts_part] page only occurs if [view_guts?] is true and the user viewing the form is the one associated to the record being viewed ([is_me?], which determines whether the current user’s email matches that in the record).

I would expect changing [view_guts?] from N to Y in the form would change Save at the bottom of the page to Next, allowing me to then click-through to the now-accessible [guts_part] page. Instead, Save remains unchanged.

[Steven_Coile]

If I set the Show_If for [guts_part] to =[view_guts?], Save changes to Next when [view_guts?] is changed from N to Y, as expected.

[Steven_Coile]

If I set the Show_If for [guts_part] to =and(true, [view_guts?]), works as expected.

[Steven_Coile]

If I move the physical [is_me_too?] column (which mirrors the virtual [is_me?] column) so that it occurs (immediately) after the [guts_part] column (the Page_Header), the unexpected behavior returns. If I then swap the order the 2 columns so that [is_me_too?] occurs (immediately) before [guts_part], the expected behavior returns. So the location of the column referenced in the Show_If of a Page_Header category Show column is apparently significant?

[Steven_Coile]

Sorry, @Adam_Stone_AppSheet. Didn’t see your reply until after I’d already posted.

[Steven_Coile]

@Adam_Stone_AppSheet As I think it through, the behavior makes sense: the path followed through conditional pages could affect the later column values. The future columns cannot be expected to remain unchanged without possibly-non-trivial logic, if possible at all.

[Adam-google]

Yes, and it helps ensure pages in one path don’t leak into another, otherwise the app creator may need to create unwieldy expressions that AND the condition relevant to the particular branch/page with the prior set of conditions required to reach that page. For example if an initial value somewhere on branch 3 is meant to indicate that the next page on that branch should be shown by default, this behavior prevents it from showing up on every branch.

[Steven_Coile]

If I set … to =[is_me?] (which should be true!), Save occurs, not Next. Conversely, if I set it to =not([is_me?]), Next occurs. Suggesting [is_me?] is not accurate?

[Steven_Coile]

If I change the Category for [guts_part] to Section_Header and repeat all the Show_If variations mentioned above, the section header content appears and disappears as I would expect when [view_guts?] is toggled, in contrast to the behavior as a Page_Header. This inconsistency appears to be a bug.

[Steven_Coile]

All above testing done for new records. Not yet tested on existing records.

[Steven_Coile]

Behavior appears consistent for existing record, too.

[Steven_Coile]

If I create a physical column, [me?], above [guts_part], with the same App formula as the [is_me?] virtual column (which occurs after [guts_part]), and change the Show_If for [guts_part] to use this new column, the form behaves as expected.

[Adam-google]

Hi @Steven_Coile, it should indeed work as you expect. I think the problem is the way the page header Show_If works. In conditional branching forms, only columns from pages that have been visited so far are considered when evaluating whether the next page should be shown. I think if you use the virtual column app formula directly within the Show_If, it should work.

I think since virtual columns can’t be rearranged and are always at the end, it might make sense to exclude them from this restriction. However, in the future we may support moving them.

[Steven_Coile]

If I create another physical column, [is_me_too?], also above [guts_part], with the App formula =[is_me?] (the original virtual column), and change the Show_If for [guts_part] to use this new column, the form behaves as expected!

[Steven_Coile]

So the problem seems to either be because [is_me?] is a virtual column, or has to do with the ordering of [is_me?] in the list of columns. And the problem affects Page_Header columns, but not Section_Header columns.