Okay. So it depends on whether or not you’re using row owners. If you are, just add a component and you’ll find that you can use columns from your User Profiles as the source. Row owners will ensure that you’re selecting from the row that belongs to the currently signed in user.
If you’re not using row owners, then it’s a little trickier. Essentially you’d need to create a single relation between the current table and your User Profiles table (using a template containing the current users ID or email address), and then import whatever columns you need using lookups via that relation.
This might be a case where a custom form isn’t a good choice - I can’t say for sure.
What are you trying to do with the user data? Are you trying to display it on the screen or pass it through the custom form when you submit the form? What you are showing with the user columns in the native form is to pass the user profile data into the form sheet. In a custom form, that same information would still be there, but in an action, such as Add Row. If I understand correctly, you should still be able to do what you want, but you just need to look in a different place to get that user data written to the form sheet.
So I am using conditions, in the action editor, and checking for user-specific fields that are written into from a selector. However, is does not hide my button bar or disable the button if the fields are empty. Please help.
Can you show us some screenshots? Do you mean that if fields are empty in an Add Row action then your button should be hidden (as you said you’re checking in the action editor).
I believe there are 2 cases when a button will be hidden:
It does not satisfy your visibility conditions.
You use branches of conditions for your action and the relevant data satisfies none of those.
Which button do you expect to not be visible here? You’re using a button bar, and your screenshot shows that you have multiple branches of condition, if one of them is satisfied then your button will still be clickable.
I mean here, you have a branch on the left of this and it’s likely that the data satisfy that one. All branches must not be satisfied in order for the button to be disabled.
Here is a version where I use trim whitespace and lowercase text to build the relation that checks for duplicates. Also using trim on submit in the add row action…
Hi @Darren_Murphy
I’ve already mentioned this post on several other posts with appreciation but I’d like to extend another “thank you” also here.
On the topic of duplicates, I’d like to ask a couple of questions:
As it seems, the custom form is NOT creating a new line when form is opened. Instead, the form is “riding” on the top line of whichever table we’re in. Is that correct?
Assuming the above is correct, and all input/form columns are USC, it seems that indeed we’re safe from duplicates. However, one challenge with this “top line” usage. What happens if one of the columns is a counter and as part of the “save” button actions we increment it by 1? Won’t this potentially allow same counter for several concurrent form submissions? Any other problems this may create?
Even if duplicates aren’t possible as per point 2 above, I have another “stupid” issue that I cannot figure out. I’m sure it’s SUPER simple.
it seems we’ll always have the same counter twice. Once for the last entry (created at the bottom of the table) and once in the first row. I also tried to use a math column with “+1” but that didn’t seem to solve anything. Any ideas for a counter inside custom forms?
SUPER simple again: These clients numbers should be, ideally, consecutive no matter which user entered the last entry via the custom form. Won’t that create different set of numbers for each user?
That’s generally the case, but it depends how you got there. For example, if you were in the details screen of a record 20 or 30 rows deep, then did a Show New Screen → This Item from there, then that’s the row where your User Specific Column values will go. What I’ll often do is open my custom form on top of a completely separate table - a table that has just a single row. Then collect all my form data in that row, before writing a new row to the destination table when the user submits. This keeps things nice and clean.
What’s the purpose of this counter? Sounds like it has nothing to do with the custom form?
Again, I think I need to understand better what you’re using this counter for…
So you’re wanting some sort of unique incrementing number?
A word of warning… down this path there be dragons
Thanks!
A very detailed answer, as always. You’re right, the counter is a sequential client number, added to each lead (even before they’re a client, if at all). This will naturally create a situation in which two clients won’t have sequential numbers, even if they have been created one after a another (if a lead was created in between it’ll take that consecutive number). What I’ve done in the past is use the LockService on Google Script. It seems to be exactly what it is meant for, but it’s not very fast and it can create lags if we have many submissions at once, all asking the locked part of the script to generate a number for a new lead. I was really hoping to replace this (hardcore?) lock with a more elegant solution from Glide.
I’ve read all of the posts in the topic you linked and it seems that indeed these dragons hunt many of us
I very much liked your video example.
However, I’m still puzzled by the race condition. Have you ever received feedback from Glide about this?
Same question, different approach, have you ever found out a way to force an action to be on the server-side? Specifically, having the compound action of “incremate” happen on the server. This will, hopefully, complete remove any chance of a race condition, even if two forms are submitted at the exact same time.
I very much liked your idea of having a separate table for the custom form, as well as the column that has the same value in all rows (next number), inside the data table. Again, this one-row custom form table isn’t immune to the race condition. Or is it?
