Deleting user-posts when deleting a user!

Ask for Help
1

Hi,

I need help with one flow in my app. In what’s a simple implementation, I have user-profiles and each user can post certain content on the app. Now I have given the option for the user to go and delete his profile himself.

BUT !! i noticed that when he does so, his posts are still remaining.

I (admin) went and did a cleanup from the backend where I went to the data section of settings and then gave the user email and did clear data. But the posts are still around.

Basically when the user deletes his profile or when the admin deletes the profile, all the “posts” corresponding to the user need “also” needs to get deleted too. But this isn’t happening.

I have gone through these threads but on the forum which is related but not completely.

Delete user data - Announcements - Glide Community (glideapps.com)

Delete user - Glide Community (glideapps.com)

Need help with a problem - Deleted user’s name is removed from items they posted - Glide Community (glideapps.com)

Any guidance on the best way to implement this.

-Shiv

2

There’s no cascading delete in Glide. What the user deletes is simply his/her profile row.

If you still know the email I think this “delete user data” part will do, but only inside the builder.

image
image1340×1260 126 KB

Otherwise you would have to implement scripts/Zapier/Integromat to help.

1 Like
3

I think the “Delete User Data” option only deletes internal glide data, such as login information, user favorites, maybe comments???, and any data that would be contained in user specific columns. Like @ThinhDinh said, there is no cascading delete, and honestly, I don’t think you’d want Glide to “guess” what should or should not be deleted. That’s something that should be fully controlled by the developer.

3 Likes
4

Correct! Glide lacks the context to be able to accurately guess what should be deleted via a relationship and what should not. The semantic meaning of your data is what you are bringing to Glide when you build an app, and without that it’s impossible to know exactly what to delete. In the future we may offer tools where we suggest additional things you might want to delete, but that would never be fully automatic.

4 Likes
5

Oh, have there been any documents about what exactly this function can delete? Even if it’s only those it’s useful for me to reset an account.

Edit: Found the post from Jack, you would still have to cascade delete the things from Sheets and Tablea.

2 Likes
6

do you want to delete the data permanently?

7

What I did in of my cases, user inputs many entries and each entry may have few sub-entries.

So when user deletes one entries, it does not delete corresponding sub-entries so even after delete user used to see sub-entries.

As temporary solution, I make visibility condition with relation, so if Main entry is deleted or not visible in main sheet, it filter outs the subentries and does not show subentries.

I hope I could explain it.

3 Likes
8

Yep, I think a relation back to the “parent” category will work. Visible only when relation is not empty.

1 Like
9

Yes Jeff - after a bit of thinking about it and going through the replies I realized It’s our responsibility than letting Glide decide and delete ( and probably end up with a disaster ).

Thats interesting, good to know Glide is working on something which will at least give some suggestion which will def be good than taking a decision itself. looking forward to it.

Yeah saw this post and realized it’s my decision than expecting glide to automatically delete.

yes, that was/is the idea. I have 2 parallel thoughts on if and should i delete the data or retain it with the consent of the user or maybe give the option to the user to give consent for the admin to go ahead and delete the data from the backend.

I kind of have a simple version of it already implemented where i do disable the visibility if need be, but doing it as a part of relation and having a visibility condition to disable the visibility based on the availability of the parent would be something i will def give it a try. Thanks for the idea.

Yes looks like an idea to try out.

Thanks to everyone for the inputs and suggestions. Every day I get to learn something new about Glide and also about what’s supposed to be a potential solution or approach for something that me/others are stuck. That’s the best part of this platform or forum.

You will never be stuck with an issue without a solution :slight_smile:

-Shiv

2 Likes
10

My advice would be to ensure that any data attributes that could be considered personal information (email address, name, etc) live in one place, and one place only.

What I generally do is:

  • Add a Row ID column to my User Profiles table, and rename it to UserID
  • Relations I make with my User Profiles table will then use UserID, as opposed to email address
  • I’ve seen others create templates using the current users email address. I don’t do this - I use the current users UserID
  • Wherever I need a users name/image/whatever, I always use a reference back to my User Profiles table, and never replicate that data in other tables.

The advantage of this approach is that once you remove a user from your User Profiles table, there should be nothing anywhere in the app that could be used to identify them. (This won’t always be the case, of course - there will always be exceptions).

3 Likes