Delete user is not implemented

[JaseElder]

@CherryCIC

Also need to decide what to do with the products listed when a user is deleted.

At the moment, the products are associated with the User ID that is generated when the user is created.

If the user is deleted from firebase admin and then a new user (for the same person) is created through the app, the User ID that is linked to the products they've listed is no longer relevant, as it's the one from the deleted user.
Which means that viewing the listing in the app doesn't bring up any user details.

Is this a potential use case?

[CherryCIC]

I think the easiest MVP approach is to remove the user’s active listings when the user is deleted, but ideally this should be a soft delete rather than a full hard delete.

The listing should disappear from the marketplace immediately, so it cannot be viewed, searched, purchased, or shown with broken seller details. That solves the orphaned UID problem.

The main risk with hard-deleting listings is that some product records may be needed later for orders, refunds, disputes, donation records, audit trails, analytics, or accidental recovery. If a buyer has already purchased an item, deleting the product entirely could break order history or remove important evidence about what was sold.

Though there are no problems with a hard deletion of items along with the User for MVP; if this is simpler for now!

[Uchyy]

Is there a scenario where a product is live and a user wants to delete their account? And when I mean a live product, I mean something an order is being placed, or has being placed or there is a pending action left to be completed on the product?

[CherryCIC]

@Uchyy great point!

If we are going off of Vinted, @JaseElder no, you should not be able to delete/deactivate your account while there are active orders or unsettled balances. Their Help Centre says users should first complete all active orders and withdraw remaining funds before deactivating the account. Here: https://www.vinted.co.uk/help/4/60-hiding-editing-or-deleting-listings?utm_source=chatgpt.com

For listings, Vinted also separates listing deletion from account deletion. It says a sold listing can only be deleted once the transaction is fully completed, and Vinted may retain some listing data for up to 6 months before permanent deletion.

The correct product logic should probably be something like:

1. If the user has live unsold listings
   • Hide, unpublish, or mark listings as inactive.
   • Do not leave them purchasable.
   • Keep the product records internally if needed for audit/history.
2. If an order is being placed, payment is pending, shipment is pending, refund/dispute window is open, or courier action is outstanding
   • Block deletion.
   • Show a message such as:
     “You can delete your account once all active orders, shipments, refunds, and donations are complete.”
   • Allow the user to request deletion, but queue it until completion.
3. If an order has completed
   • Keep enough transactional data to preserve order history, donation records, disputes, fraud prevention, accounting, and support.
   • Remove or anonymise public user profile details.
   • Do not break historical product/order screens by relying only on a live Firebase user ID.
4. If the user is deleted and later signs up again
   • Do not try to reconnect old products based only on email.
   • The old Firebase UID is gone, so those products should remain linked to an internal deleted/anonymised seller record, not a new account automatically.

[JaseElder]

All makes sense to me.

• The first step would be creating an api endpoint for deleting the user with appropriate response codes.
  The backend should determine whether the user can be deleted based on the rules above, and handle the user's listings appropriately (marking them inactive or whatever)

• Another endpoint for queuing deletion? Or perhaps a flag on the delete user endpoint to say "queue this deletion"
  So the flow would be:

  1. request to delete user through endpoint.
  2. the backend sees that there are outstanding tasks blocking the deletion, so sends back appropriate code to front end.
  3. The frontend displays a dialog informing the user of this and asking if the want to queue
  4. If they approve queuing, make a repeat request to delete through the endpoint, but with the queue flag set.
  5. Then the backend would need to run some sort of cron job or similar to periodically check whether the user still has outstanding tasks, and if not, do the normal deletion.

• Then the endpoint that retrieves the products will need to be modified so that the products have a flag for inactive/hide/unpublish (whatever you want to call it)

• Then the app should be modified to handle all those states (message to deleting user, hiding the inactive products, asking to queue, etc, etc)

[CherryCIC]

That makes sense to me. I think the key point is that deletion should be backend-led, not handled mainly in the app.

For MVP, I’d suggest we keep the flow simple:

1. The frontend requests account deletion.
2. The backend checks whether deletion is currently allowed.
3. If there are blockers, such as active orders, disputes, shipments, or other incomplete tasks, the backend returns a clear blocked response.
4. The frontend explains this to the user and offers to queue deletion.
5. If the user confirms, the backend marks the account as pending deletion.
6. A scheduled backend job later checks whether the blockers are cleared, then completes deletion and marks any active listings as inactive/unpublished.

For listings, I agree they should not remain live once the user is deleted or pending deletion. Product retrieval should filter out inactive/unpublished listings by default, and the app should handle those states cleanly.

This probably needs splitting into separate backend and frontend issues rather than one large issue.

I will create a backend issue for this now.

Update: Cherry-CIC/cherry-Backend#27 @JaseElder @Uchyy

[JaseElder]

@CherryCIC Found a closed PR with deletion implemented apparently

#377

It doesn't work, with an error:

I/flutter (31411): ╔ DioExceptionType.badResponse
I/flutter (31411): ║    {
I/flutter (31411): ║         "success": false,
I/flutter (31411): ║         "message": "Route not found",
I/flutter (31411): ║         "path": "/api/auth/account"
I/flutter (31411): ║    }

The PR mentions a backend PR : Cherry-CIC/cherry-Backend#19 which is also closed.
So at one stage, there was a working delete?

Though it doesn't look like it takes into consideration any of the issues raised in this thread.

[CherryCIC]

Nice catch! @JaseElder
To be honest I forgot about this one.

I believe all that deletion button does is log out the user?

Notes were mentioned for the backend PR for this too, but yeah I don't think it has a lot of complexity/ firebase connection like what we're currently looking at.

[CherryCIC]

@taiwo2 have you seen this by any chance?

[yusuphjoluwasen]

I think we should simplify this for now. I'll come up with a simpler approach and update this discussion.

[taiwo2]

@yusuphjoluwasen, I don't understand what you mean here

[yusuphjoluwasen]

leave this to me @taiwo2