Extract shared player ownership verification utility #54

Open
opened 2026-03-01 22:41:10 +00:00 by cal · 0 comments
Owner

Both InjuryGroup._verify_team_ownership (commands/injuries/management.py) and can_edit_player_image (commands/profile/images.py) implement nearly identical logic to check whether the invoking user owns the organization a player belongs to.

They should be consolidated into a shared utility in utils/permissions.py (e.g. async def verify_player_ownership(interaction, player) -> tuple[bool, str]) that both callers wrap.

Notable differences to reconcile:

  • _verify_team_ownership uses get_team_by_owner (ML team only); can_edit_player_image uses get_teams_by_owner (all roster types). The shared version should use get_teams_by_owner for correctness.
  • _verify_team_ownership has an isinstance(interaction.user, discord.Member) guard on the admin check; can_edit_player_image does not. The shared version should include the guard.
  • Error response format differs (embed vs string). The shared function should return (bool, error_message) and let callers decide how to present the error.
Both `InjuryGroup._verify_team_ownership` (`commands/injuries/management.py`) and `can_edit_player_image` (`commands/profile/images.py`) implement nearly identical logic to check whether the invoking user owns the organization a player belongs to. They should be consolidated into a shared utility in `utils/permissions.py` (e.g. `async def verify_player_ownership(interaction, player) -> tuple[bool, str]`) that both callers wrap. Notable differences to reconcile: - `_verify_team_ownership` uses `get_team_by_owner` (ML team only); `can_edit_player_image` uses `get_teams_by_owner` (all roster types). The shared version should use `get_teams_by_owner` for correctness. - `_verify_team_ownership` has an `isinstance(interaction.user, discord.Member)` guard on the admin check; `can_edit_player_image` does not. The shared version should include the guard. - Error response format differs (embed vs string). The shared function should return `(bool, error_message)` and let callers decide how to present the error.
cal added the
ai-working
label 2026-03-05 05:31:12 +00:00
cal added the
status/in-progress
label 2026-03-05 05:33:28 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cal/major-domo-v2#54
No description provided.