Input modal unreliable

[dbaum]

My app uses an INPUT() modal to allow users to select values for an enumlist column (which references a column in another table). The modal intermittently and evermore frequently doesn't work. It always opens when I select the corresponding action button, but it simply displays as empty. Even when it initially works, it sometimes reverts to empty after I select values from the list but before I can select the modal's "Save" function, although in this case if I go ahead and select "Save" and the modal closes then the values do get saved to the data source. In other cases, it initially works, I successfully make my selections, my selected values appropriately display within the modal, but when I select "Save" nothing happens--modal doesn't even close; my only option is to select "Cancel", which does work.

Is this associated with some likely pitfall in my setup that others are aware of and can guide me how to avoid?

[Steve]

I would guess the column's Valid If expression uses the column's own value to decide what list of items to display, and that the choices made in the dropdown, when used by the expression, produce an empty list.

[dbaum]

It had occurred to me that the column's Valid If expression might be the culprit, and I had already confirmed it didn't directly reference the column itself. Your guidance prompted me to go deeper, and I realized that it references a slice whose Row filter condition does reference the column. Thanks for putting me on this trail. I'll noodle on an alternate approach and report back.

I really appreciate your help.

[dbaum]

Actually, I misspoke. When I went to revise the column's Valid If expression, I realized I had double-checked the wrong column when replying several minutes ago. It's a different column in the same table that references a slice that in turn references the column for which the INPUT() modal is confusing me.

The column that the INPUT() action is related to did not (and still does not) reference the slice, but rather the table directly. I confirmed as comprehensively as I can think of that there's no lurking circular reference--e.g., there's no reference to the column in either table's security filter.

I'm finding it difficult to troubleshoot since the issue is only intermittent. I try something, it seems like it's working for a while, and then suddenly it's not working any longer.

Here's the table columns that are the source of the enumlist--just text (e.g., no complicating refs).

Here's the enumlist column's connection to the source table, along with some other properties. Maybe a factor is the Show if expression that references a view--e.g., maybe the INPUT() modal affects the value of CONTEXT("View")?

Here's the action's Set this column expression. Maybe a factor is problematic characters in the column name? You mentioned in another post that there's an evolving "list of unacceptable characters for file. table, and slice names".

[Steve]

I don't believe there should be brackets around the column name of the first argument to INPUT(). If the column's name actually includes the brackets, that will be a problem.

[dbaum]

In rereading the INPUT() documentation, I realize that first argument is actually supposed to not be the column name but rather be "unique within the context where it is used". I also see that if it were supposed to be the column name, I shouldn't have used the brackets (which indeed are not part of the column name).

Anyway, I revised the expression to use a definitively unique name:

INPUT("Lists_list", LIST())

Regardless, I still experience the exact same issue of varying full/partial/no success.

[SkrOYC]

As far as I know, INPUT() is still on beta, and I don't know if there is people working on it, just check the other features that are left aside.

I had problems with it. I made sure no ValidIf were preventing it from save and still... It worked a couple of days after out of nothing. At that point I stop using the action for those days.

I never reported since it's a beta feature (afaik) and I didn't have time

[Steve]

Personally, I don't use or recommend the use of INPUT().

[dbaum]

Good to know. Do you happen to have any strategies to suggest regarding my use case?

• Users table has an "Assigned Lists" enumlist column that references List ID values from the Lists table.
• I'm trying to enable two separate action series that someone can invoke for one or more users. Each action series involves a way for someone to first select one or more List ID values. One action series then adds the selected values to the Assigned Lists column if they're not already there. The other action series removes the selected values from the Assigned Lists column if they're present.

The technique I'm unsuccessfully using is to present the INPUT() modal for the initial list selection in order to temporarily populate the "Lists to (un)assign" column. Then, other actions follow to either add those selected lists to or remove them from the official "Assigned Lists" column, followed by a clean-up action to clear the "Lists to (un)assign" column so it's ready for next time.

[WillVerkaik]

IMO: Solutions that provide inline user input engagement during workflows are a hallmark of UIs. Not unlike a mirror in the passenger’s visor.  It is an expected function. 

I am finding that the user community works hard at supporting workarounds like yourself.  Is this product being taken seriously by Google?

[dbaum]

Thanks for calling out the beta status. I see now that's noted in the Dynamic inputs for data change actions article, although it's not noted in the INPUT() article.

[lizlynch]

Ah, good catch! I've added a note about INPUT() being a Beta feature. I've also alerted the dev team about this thread. 

[Just_a_noobie]

(Haven't seen this mentioned anywhere) The only type that seemed to work consistently well for me so far are inputs concerning dates and quantities. Anything that has to do with text yields the same inconsistent results as mentioned above. 

[Steve]

Yeah. My impression is the INPUT() function was slapped together to fill some specific need of a developer, released in "beta", then abandoned. It's a half-baked feature. I don't use it at all.

[SkrOYC]

I was surprised to see that it was taken into account when making the new desktop design. Try opening an INPUT() Pop-up on desktop, looks great.

I think it will be taken into consideration again in the future, as well as the new charts and more.

When? I have no idea

[dbaum · Accepted solution]

I revisited this today, and have a few small updates to contribute to the collective understanding of the sometimes enigmatic INPUT function in case this info is ever useful to anyone facing the function's frustrating behavior in apparently unanticipated use cases.

Different bug fixed

First of all, what prompted me to return to this issue was the following detail in the February 16, 2023 Release Notes. The "update" is in the context of a bug fix for the New UI design for desktop users, which (as of the date of this post) remains in preview and is still being rolled out.

Update: As part of this rollout, there is a fix for INPUT() modal form not showing changed values. The value would appear to revert to its initial state after focus leaves the input. This issue has been fixed.

While the issue I originally reported here was definitely unrelated to the desktop UI since it long precedes that feature's preview release, I thought that perhaps this fix for an issue that resembles what I previously reported might also address the problem I observed. Alas, I promptly confirmed that the intermittent issue described in my earlier posts in this conversation still manifested.

Nonetheless, in continued troubleshooting I may have identified the root causes--at a minimum, I figured out at least one way to replicate the seemingly intermittent issue--and believe that I've figured out some app design changes to avoid it.

Seeming ongoing bug

Here's an outline of how I'm able to replicate the empty input dialog modal screenshotted in my original post.

• The INPUT function is in an action that is available in a deck view and a detail view for the same table.
• Specifically, the action type is "Data: set the values of some columns in this row", and the INPUT function is in the expression that sets the value for a column whose Show if property displays the column only in the deck view and not in the detail view.
• After an app sync:
  • If I first select the action button in the deck view the input dialog modal works and if I then select the action button in the detail view it also appears to work.
  • However, if I instead first select the action button in the detail view it does not work (i.e., the input dialog modal appears blank) and even if I then select the action button in the deck view it still does not work.

So, it seems that I initially had a design flaw where the column was hidden in a view where the action was available. That's, of course, easily remedied--I just excluded the action from the detail view (or, alternatively, could presumably not configure the column to not show in the detail view--even if I then still excluded it in the view's column list). However, I think my design flaw revealed a bug. It seems like inaccurate behavior for the app to inconsistently provide a functioning input dialog modal in a given view depending on the prior view when it was invoked.

Row update timing issue?

As I also described elsewhere in this thread, even when the input dialog modal appears as intended, sometimes the values I select in its drop-down list don't stick. I tend to think whatever I observed with regard to this aspect of the issue was a subset of the ongoing bug described above. I did observe this aspect again once during my troubleshooting today, but I can't replicate it.

My only other guess is that this may result from the underlying column momentarily having different values in different rows. As I explained in more detail previously, my use case involves selecting multiple rows and then performing a grouped action series on the selected rows. The action series begins and ends with an action that clears the underlying column; in between, of course, the column is populated with the user's input. When I use the action simultaneously on many rows and then use it again on some or all of those rows, I wonder whether at the moment the INPUT-based action appears its underlying column may somehow have changes still in progress for some of the selected rows. I'm dubious this is truly the case since it seems unlikely that I'm clicking faster than the rows are being updated within the app on my device (obviously, syncing takes longer). Anyway, I'm now disabling the group action while the column in question is not blank. So, if there's actually anything to this diagnosis then users won't encounter it because they won't be able to select the action for a row while a previous instance of the action is still processing for that row.

Tentative conclusion

Overall, with the small app configuration changes I made the action now seems to work reliably and the problems I originally reported haven't reappeared during my testing.

[WillVerkaik]

I am noticing other feature solutions that appear to be implemented outside the core data management routines likely engineered. 

Meaning secondary data CRUD functions that had no original architectural intention.   This usually means that the data object service layer has multiple interfaces to data and gets confused.  
I have encountered bulk edit functionality that randomly updates data and quick edit features that fumble as well. 

These features are highly desirable especially to compete with other Low/No Code platforms, unfortunately data integrity is a primary and fundamental need in any platform of this nature as it is all about the data.