mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 05:26:47 +00:00
jubnl
40ede38ea7
UserCleanupService.erasePluginUserData (the account-deletion transaction's own UC2/UC3 enqueue) and PluginRuntimeService.enqueueUserErasure (the emitUserDeleted sink's post-commit enqueue) independently walked the identical SELECT id, permissions FROM plugins + JSON.parse + hook:user-data filter + INSERT OR IGNORE — and both genuinely run for every account deletion, since every emitUserDeleted call site (auth.service.ts, admin.service.ts, trip-members.service.ts's guest removal) fires immediately after deleteUserCompletely. Extracted the shared filter into enqueueHookUserDataErasures (nest/plugins/user-erasure-enqueue.ts) and pointed both call sites at it. UC2/UC3 also come off DatabaseService onto PluginsRepository/ PluginUserErasureQueueRepository in the same change (they were the last raw statements standing in the way of sharing one implementation) — this narrows the Plan 3b Task 5 "stays raw, owned by Plan 3j" ruling to UC1 only (plugin_user_config/plugin_oauth_tokens/plugin_oauth_state), which still stays raw, unaffected. UserCleanupService's orphan-data-directory scan (a plugin uninstalled with data retained) has no equivalent on the enqueueUserErasure side and stays there, now via the same repository. Both enqueue calls still run per deletion (INSERT OR IGNORE keeps this idempotent) — this unifies the IMPLEMENTATION, not the call count; not touching the emitUserDeleted event-sink wiring itself was a deliberate, smaller-blast-radius choice for this task.