Add nickname column to players table #408

New issue

Open

opened 2026-04-08 22:44:12 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-04-08 22:44:12 +00:00

Contributor

Type

Feature

Lineage

Standalone — discovered during GroupMe/DB cross-reference audit (2026-04-08). Players go by nicknames (Gabrielius = "Gabe", Querenne = "Q") which makes name matching against external systems (GroupMe, etc.) unreliable.

Repo

forgejo_admin/basketball-api

User Story

As an admin
I want players to have an optional nickname field
So that I can match them across systems (GroupMe, rosters, comms) using the name people actually use

Context

During a GroupMe membership audit, we couldn't automatically match "Gabe" in GroupMe to "Gabrielius Peciulis" in the DB. This will keep happening with any name-based cross-reference. A nickname column solves it — display the nickname where available, fall back to full name otherwise.

File Targets

Files the agent should modify or create:

src/basketball_api/models.py — add nickname field to Player model (String, nullable)
alembic/versions/ — new migration adding the column
src/basketball_api/routes/ — include nickname in player serialization responses

Files the agent should NOT touch:

Registration form/flow — nickname can be set by admin later, not during registration

Acceptance Criteria

When a player has a nickname set, API responses include it
When a player has no nickname, field is null (no breaking change)
Admin can set/update nickname via existing player update endpoint

Test Expectations

Unit test: player model accepts nickname field
Integration test: create/update player with nickname, verify in GET response
Run command: pytest tests/ -k player

Constraints

Nullable String(100), no default
No changes to registration flow — this is admin-set only
Follow existing column patterns in Player model

Checklist

PR opened
Tests pass
No unrelated changes

project-westside-basketball — westside basketball project
forgejo_admin/basketball-api#401 — ContractStatus enum ticket (same audit session)

### Type Feature ### Lineage Standalone — discovered during GroupMe/DB cross-reference audit (2026-04-08). Players go by nicknames (Gabrielius = "Gabe", Querenne = "Q") which makes name matching against external systems (GroupMe, etc.) unreliable. ### Repo `forgejo_admin/basketball-api` ### User Story As an admin I want players to have an optional nickname field So that I can match them across systems (GroupMe, rosters, comms) using the name people actually use ### Context During a GroupMe membership audit, we couldn't automatically match "Gabe" in GroupMe to "Gabrielius Peciulis" in the DB. This will keep happening with any name-based cross-reference. A nickname column solves it — display the nickname where available, fall back to full name otherwise. ### File Targets Files the agent should modify or create: - `src/basketball_api/models.py` — add `nickname` field to `Player` model (String, nullable) - `alembic/versions/` — new migration adding the column - `src/basketball_api/routes/` — include nickname in player serialization responses Files the agent should NOT touch: - Registration form/flow — nickname can be set by admin later, not during registration ### Acceptance Criteria - [ ] When a player has a nickname set, API responses include it - [ ] When a player has no nickname, field is null (no breaking change) - [ ] Admin can set/update nickname via existing player update endpoint ### Test Expectations - [ ] Unit test: player model accepts nickname field - [ ] Integration test: create/update player with nickname, verify in GET response - Run command: `pytest tests/ -k player` ### Constraints - Nullable String(100), no default - No changes to registration flow — this is admin-set only - Follow existing column patterns in Player model ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `project-westside-basketball` — westside basketball project - `forgejo_admin/basketball-api#401` — ContractStatus enum ticket (same audit session)