[FR] delete-user-data: Delete subcollections

[claust]

[REQUIRED] Step 2: Extension name

This feature request is for extension: delete-user-data

What feature would you like to see?

It would be helpful if the delete-user-data extension could delete all documents in subcollections as well.

How would you use it?

Often you would have one or more subcollections below a user profile document.
Example: /users/{UID}/stories or /users/{UID}/likes.

In this case it would be really nice if the extension could delete all documents in a specified subcollection, or maybe all documents in any subcollections (recursively). This is not trivial to implement, and therefore fits very nicely in the delete-user-data extension.

[Ehesp]

Let's open discussion on this one. By default a delete won't delete subcollections, as its not always desired.

We could either do this by default, mention in the docs how to do this (provide explicit additional paths), or implement some wildcard paths.

[thatfiredev]

I vote to make it a default. I mean, if we're deleting all of the user data, it wouldn't make sense to keep subcollections under that UID.

[horaciocome1]

Yes! It is easy to think it should be default, but it would be cool if there had an optional parameter where one specifies if he fits or not in this common case.

Lets say one has an later function that is trigged when user data is deleted. The main goal of the function is to archive someplace stories and likes. Perhaps he wants to notify followers.
What you guys think of this?

[chenlevy]

I think it would be better to allow users to determine if they want to delete a subcollection.

Using an explicit path:
/users/{UID}/notifications

And in case the UID is saved in a document field:
/notifications(userId=UID)

[claust]

Having the ability to keep (documents in) subcollections is kind of an advanced feature, and I believe it makes good sense to recursively delete all (documents in) subcollections by default. This is probably by far the most likely need and expectation of the developers, rather than the other.

It should also be a design goal of Firebase Extensions to be really simple to use. So minimizing the need of configuration for most users would be nice.

So if you have the special need to keep one or more of any subcollections, I think it would make sense to write your own function.

[Ehesp]

cc @karayu - let me know your thoughts on the above. Another idea is to have a dropdown/select option on setup, which gives developers the option (defaults to non-recursive).

[andreivladmatei]

I believe the most common use-case is to delete user/{UID} and user/{UID}/subcollections by default.

When I first installed the extension, that was the way I thought it will go and found out that it's not.

[karayu]

Thanks so much for the feedback! I think this is a great feature request and would make this extension much more helpful. @Ehesp Let's sync directly on how we can make this happen!

[Ehesp]

Currently working on this feature, however I've hit an issue. To carry out a recursive delete with the firebase-tools repository, a user token is required. As the extension runs in isolation, the admin SDK would have to generate this token using a valid UID... However, as the extension is triggered when a user is deleted, the token generated from the UID is invalid causing the recursive delete to fail.

[samtstern]

I believe an Admin SDK token would work, there's an API to generate an OAuth2 access token from service account credentials. Sorry I'm on my phone otherwise I'd look up the details.

…

On Thu, Oct 3, 2019, 1:25 PM Elliot Hesp ***@***.***> wrote: Currently working on this feature, however I've hit an issue. To carry out a recursive delete with the firebase-tools repository, a user token is required. As the extension runs in isolation, the admin SDK would have to generate this token using a valid UID... However, as the extension is triggered when a user is deleted, the token generated from the UID is invalid causing the recursive delete to fail. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14?email_source=notifications&email_token=ACATB2XH22C3IKFLYVU6ZIDQMW3AJA5CNFSM4I3FYG3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAHSVFQ#issuecomment-537864854>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACATB2SLCZS5OPDXOIRGALLQMW3AJANCNFSM4I3FYG3A> .

[Ehesp]

#25

I was having IAM issues when uninstalling the extension (issued raised internally) which caused the token issue. All sorted now in the above PR.

[jimmykane]

Its true. I thought this extension would do a recursive sub-collection delete which is the main pain of deleting user data.

[laurenzlong]

Fixed in v0.1.2: https://github.com/firebase/extensions/releases