I had a read through this related topic, but as it’s more than a year old I’m creating a new one.
So this is something I think I’ll need to be able to do. I’m using User Profiles with Allowed Email List.
I’ve been thinking through an approach for a few days, and this is the idea I came up with:
Give users a button on their profile page - ‘Change My Email Address’
Clicking on that button takes them to a form that shows their current email address, and prompts for a new one.
This writes an entry to a “User Email Changes Table”
A trigger script detects the new row in that table and fires another script that essentially does a global search and replace on that users email address across all sheets (except the sheet that fired the change).
What I wasn’t sure about is what the user experience would be after they make the change. So I did some testing with that. I created a dummy user account using a spare email address and then allowed that user to edit their email address. What I found is that as soon as I submitted the change, I got a completely blank screen. So I killed the app and refreshed, and found that I was still logged in, and the change hadn’t been made.
The conclusion I have at the moment is that making this a self-service feature is probably a really bad idea™
But… I’m still going to need to get it done one way or the other. I could just allow users to create a second account and abandon their original, but the problem with that is they’ll lose access to all data associated with the original account (and there is lots of that). So the modified approach that I have in mind now is something along the following lines:
Allow users to submit a “Change My Email Address” request.
This gets written to a sheet, but no automatic action is taken.
The user is then instructed to log out of the app and await further instructions
Once I pick up the request, I would:
Delete that users rows from both the User Profiles and Allowed Users sheets
Add a new entry to the Allowed Users sheet using the new email address
Run my magic script to reassociate all of that users data with their new email address
Contact my user and let them know they can now login with the new email address
Does anyone see any potential gotcha’s with that approach, or have a better suggestion?
So, the last time I tested the changing of an email on an ‘allowed email list’, my experience was that I was immediately signed out, the original email no longer worked, and I had to sign in with the new email. The process seemed to work as expected. I would have to test again to see if any of that has changed.
The fact that you got a blank screen and could still sign in surprises me. Were you still able to sign in after a few minutes after glide re-synced the sheet? Was your test using the script or by directly editing the whitelist email through the app?
In the old post you referenced I mentioned the use of a user id instead of an email to link data and to use for filters. A lot has changed in a year with security, and with the addition of row owners, it now requires the use of an email in each sheet for data that needs to be secure, so there is a need for something, such as a script, to update the email throughout the spreadsheet. On the other hand, if you are not actively using the Roles feature, you could assign the role to the user id column in the user profile, use that ID instead of email in all your sheets, and then assign row owners to that ID column in each sheet. That way you only need to update the email in the user profile sheet, and that can be done without a script by instead allowing the user to edit the email themselves in Edit mode (if it works).
I will have to play around again, but I really think it should have signed you out once the email is changed in the user profile/whitelist sheet. In my tests I was more focused on an admin type user “blacklisting” a whitelisted user. I didn’t test as the user changing the email themselves. I’m guessing it maybe caused an app crash since the email didn’t match on the local device database and couldn’t sync back to the glide server database. That’s why you were able to refresh and sign back in with the same email.
ooh, no… my test was with the user editing the email address in the user profile sheet, not the whitelist. I need to retest to see what happens when I allow them to edit the whitelist. If it does log them out immediately (which is what I’m hoping), then maybe I can return to a slightlly modified version of my original aproach.
I am using roles, and my app is littered with email-based relations. I’ve already written and tested the script to do the global search/replace, so I’m not really concerned about that part.
Would it be better to make the user profile sheet the whitelist sheet instead of maintaining two separate sheets? I’m thinking you could pre-populate the user profile sheet with emails and when the user signs in for the very first time, it should link up to the correct row instead of writing a new row. In my app, the user profile sheet is the whitelist sheet.
I think your reply makes a little more sense. I’m guessing you broke the user profile link, which crashed the app, and didn’t sync back to the glide servers, but the user was still whitelisted as well.
hmm, that’s something I hadn’t considered. I guess I just assumed that they needed to be separate sheets. Making that change now in this app would involve quite a bit of refactoring, so I prefer to avoid that if I can. But will definitely keep that in mind for future apps.
Anyway, you’ve given me some ideas to work with. I’ll get back to tinkering and once (if) I come up with a working solution, I’ll post it here as a reference in case it’s useful for others.
What did you learn from this testing? I’m trying to allow the user to edit their email address in a Page where all of the table RowIDs are the Row Owners, and while I can update the user’s email address in the builder as an admin, the same admin user cannot update the email address from the webpage. I’ve run across this same behavior before when a user doesn’t have access to a record and Glide will show the update in the web browser but will not update the database, e.g., when a user adds a row that they do not have access to, the Set Column Values action for the new row doesn’t commit the data back to the database but shows the update in the user’s browser.
I guess the main thing that I learned was that allowing users to change their own email address isn’t really a good idea, and so in the end I abandoned it
In the 18 months or so since I posted this, I’ve probably had about a half dozen cases in this app where user email addresses needed to be changed. In each case, I did it manually. That’s easy enough to do when you’re using Google Sheets as it’s a simple global search and replace. If you’re using Glide Tables, it would be a bit trickier.
The other thing I took away from this one is that it’s generally a good idea to avoid using user email addresses to link records, and instead use a UserID. This was the very first substantial Glide app that I built, and back then I really had no idea what I was doing. Nowadays, I generally avoid having email addresses anywhere except my User Profiles table, and will only use them in other tables if I need to apply row owners.
Agreed. This is best practice. Unfortunately, user profiles are unequivocally linked to the user’s email address, so the moment the email address gets changed, the user will need to sign out/in to re-access their user specific data.
You’re doing it right—use row ids throughout the app.
I was just mentioning that if you allow users to change their email address in the app, the app will log them out since the email is the source of truth for user profiles. Once they sign back in, users will regain access to their profile and all relations ties to the user’s row id.