My User Profile table has a (single) relation to another table called Preferences.
I want to make an action that opens a form to edit the values in Preferences.
If I create an action for the Preferences table and set the action to be ‘Show edit screen’, the editing form pops up as expected when I press my button component, however submitting the form adds a new row instead of edits the existing row.
What am I doing wrong?
I am seeing something similar with editing user profile emails. When modifying their email in the APP, a new row is created for them rather than modifying the email for that user.
So each user will have a row in the Preferences table? Can you show us a screenshot on how you’re setting up the relation and the action?
Do you have any on-submit actions for the edit screen?
Relation:
Action:
No, I do not have any on-submit actions for the edit screen. It is completely the default unedited form.
Shouldn’t your action be attached to your Users table, with the Show Edit Screen operating through the single relation?
Are you wanting to edit other users values from the action or just the user completing the form? Also, does your users table have Row Owners?
@Alpha_University Only the user completing the form. Yes, Users and Preferences have row owners based on the user email.
Okay cool. So you’re wanting to edit the value in both the Users Table and the row in the Preferences table for the same user right? So if they update their phone number from their profile (Users Table), it also updates the same column/value of the Preferences Table inside “their own row”?
All without creating a new row at all, unless they don’t have one yet of course.
Does that sound like what you’re wanting to do, or am I misunderstanding? @eddie
@Alpha_University Not quite, I don’t think. I just want a user to be able to edit a column in their Preferences (single relation to the Preferences table from the Users table), where the relation is matched on the row owner column (email address) in both tables.
The edit screen should never add a row. Seems like something isn’t configured correctly. Can you walk us through the flow with a video or screenshots and show us how everything is set up?
It would add another row if it’s set to open a Form Screen, could be configured slightly off… Try using the “Single Value” column, use the Relation as the “Window” to connect to the other table and choose “→ Get Whole Row” to bring in the entire row associated with that Relation/User.
If you do it this way, you’ll be able to select that entire Row through the relation in the action editor.
Just make sure to have the “Match Multiple” box checked for your Relation column, otherwise you won’t be able to select it using the Single Value column. @eddie
Yes, but if the earlier screen shot that was provided is to be believed, then it is not.
My guess is that there could be an onSubmit action on the Edit Screen - but that’s just a guess.
None of that is necessary. He has a Single Relation. He can open an Edit screen via that relation and it will work.
@Darren_Murphy, it does not work. I am opening an edit screen via that single relation, but submitting the changes adds a row instead of editing the existing one.
@tyler_1 to answer your question, this is somewhat expected. If a user changes the email in their user row, it may or may not update that email, but they are still signed in with their old email address. As a result, Glide generates a new row in the user table to correspond with the email they are currently signed in with.
It’s generally not recommended to allow a user to change their email address…or least not without your involvement. Glide has a very tight backend integration with user accounts. There is user data stored within Glide outside of our tables, that we do not see and can’t control other than deleting it through the builder (Delete User Data | Glide Docs). Changing an email can break row owners, relations, anything stored in user specific columns, and potentially other things. Those are all things to consider and it’s usually better if you handle that from the back end since you would be aware of any side effects from changing an email in the user table.
At this point we will need screenshots or a video of the related flow. An edit screen, without any on-submit actions, should not add a new row.
Well, it works perfectly for me. I don’t know why it doesn’t work for you. If you show me exactly how you’ve set it up, I might be able to explain why.
Tested this several ways and I see why the expected behavior would be such. I guess now would be a good time to ask for a way to sign an user via an action.
