Hi all, Deleting a user from Settings -> List Users fails with a ForeignKeyViolation (HTTP 422) whenever the user has history, on both PostgreSQL and MySQL. Details and reproduction: https://github.com/apache/superset/issues/38629
The Delete button works for users with no history, so in practice admins deactivate users or edit the metadata DB by hand. A previous fix (#41994) was closed after review asked for a policy decision first. Proposal, discussed with @rusackas <https://github.com/rusackas> on the issue: define the behaviour per category of data and enforce it in the application (UserDAO), not with ON DELETE rules on ~60 foreign keys. - personal state (favorites, SQL Lab tabs, user attributes, ...): deleted with the user - audit columns (created_by/changed_by, logs, key_value): reference cleared, rows kept - saved queries and content where the user is the only editor: needs a decision. Today the ORM deletes a user's saved queries together with the user, and a dashboard whose only editor is deleted is left with no editors. - clearer error that names what blocks the delete Newer tables (tasks, extension_storage, ...) already follow the audit -> SET NULL / personal state -> CASCADE split, so this would extend an existing pattern. Questions for the list: 1. Does this need a SIP, or is an issue plus PR enough? 2. Any objection to the application-level approach over a migration? 3. What should happen to saved queries, and to content whose only editor is deleted? A small proof of concept is on a branch here: https://github.com/Ujjwaljain16/superset/tree/fix/user-delete-policy I'll open a draft PR from it to back the discussion. Thanks, Ujjwal Jain
