mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-09-24 16:30:27 +08:00
Dannon Baker
3c02ff707c
deactivate_unprivileged_tool deliberately only flips the per-user UserDynamicToolAssociation.active flag, leaving DynamicTool.active intact so other users with associations to the same DynamicTool aren't affected (the model schema permits many-to-many, even though the current create path is 1:1). That means a user who deactivates "their" UDT can still resolve it by UUID through the toolbox -- and run it via tools_service._create -- because get_unprivileged_tool_by_uuid doesn't filter by association.active either. Add a runtime preflight in run_user_tool that fails the call when either the underlying tool or the calling user's association is inactive. Also surfaces unauthenticated and unowned errors as clean ValueErrors before reaching the deeper service layer. Tightening the chokepoint (DynamicToolManager.get_unprivileged_tool_by_uuid) to filter by association.active would close this across all entry points but is a meaningful behavior change for the existing UnprivilegedToolsApi endpoints; leaving that for a separate review.