Quasi-invisible data (that eventually disappears entirely)

* On Submit

Great question. I honestly think glide actions run too fastā€¦if thatā€™s a thing to complain about. Kind of a cart before the horse situation where it sets column values before the row is completely added.

But, I think @V88 made a really good point about your issue. You are adding a row with no row owner, and then trying to update the new row, even though you are not the owner of that row. Since the new row is not owned by anybody, then nobody can edit it after the fact.

There is a very simple solution. Instead of trying to set those values after the row is added, you can set them while the row is being added. When editing your form, add a new component and scroll down the components list. You will see a bunch of components you probably havenā€™t seen before.

  • There are Values From Screen Column components which are values from the table where the form button is located.
    image

  • There are Special Value components, which are basic values such as user email, current datetime, GUID, etc.
    image

  • And there are User Profile components which are all values from the userā€™s profile row.
    image

These are all values that are added just like components, but they are not visible components on the screen. You simply add them and set them to fill the column you want in your form table. These values are added when the form is submitted. Not after itā€™s submitted. I think using these components instead of the On Submit action will solve your problem.

4 Likes

You have been awarded the big green check mark! Thank you!

Iā€™m. . . not entirely comfortable with the design of the platform here, but at least I understand the nature of my problem and how to avoid it going forward.

There definitely needs to be a doc on when to use :zap: On Submit and when to use those various components (or perhaps there already is and I just havenā€™t seen it), and perhaps one on the semantics of adding a row in general.

One thing I noticed: If I used the ā€œSpecial Valueā€ Userā€™s email address component , the email field was left empty when added. But if I used the ā€œValues from User Profileā€ email component, it worked great. I admit that I have no idea why thatā€™s the case.

In any event: thank you once again!

Scott

1 Like

Thanks. You were really onto something there. :smile:

That doesnā€™t seem normal. That should definitely work normally. I would keep an eye on that. I use the email special value quite often and Iā€™ve never had issues with it.

1 Like

:thinking:

Yeah so actually I ran across this same thing in another project. Because I have a workaround, Iā€™m not going to open a separate ticket on it (unless you really want me to). But just so youā€™re aware. Iā€™m wondering if itā€™s a GDE vs. published thing, as @V88 was thinking about the problem in this topic: like maybe the email Special Value isnā€™t set or doesnā€™t work as expected when Iā€™m in the GDE and can emulate any user. But thatā€™s pure speculation.

Presumably User Profiles have been configured? If not that might explain the lack of access to User Profile email?

So, in my case, for sure yes. In the case of my imaginary test users, it depends what you mean. Theyā€™re set up in my app (that is, if you click User Profiles :lock: you can find all their info there), but theyā€™re not official Glide users, if thatā€™s what you meant.

Forgot to ask: how do you generate the UserIDs?

Thanks.

The user ID can be a row ID from the Users sheet, or you can generate a Unique Identifier with any action.

Thanks. Iā€™ve been using RowIDs, as the doc suggests that Unique identifiers may be deprecated.


[sic]

I was curious to see if he was using any other technique. But RowIDs do the job.

Thanks again.

Yeah, just a RowID and then I usually rename it for context. I know that @Jeff_Hager thinks I shouldnā€™t rename RowIDs, and Iā€™ll probably turn into a pumpkin, but it hasnā€™t happened yet :grin:

4 Likes

Ha! I donā€™t tempt fate. Iā€™m not as brave as you crazy Aussies.

3 Likes

4 Likes

I wouldnā€™t consider unique IDā€™s as deprecated. Row IDā€™s are definitely more convenient since they are automatic, but I believe Unique IDā€™s still serve a purpose. I would be very surprised if they ever went away.

2 Likes

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.