Add user_id ownership on stored tickets and enforce isolation per logged-in user #18

New Issue

H3ALY · 2025-10-29T09:30:47Z

H3ALY commented

2025-10-29 09:30:47 +00:00

Currently, ticket records stored in the my_tickets table are not associated with any user account. This means:

Any authenticated user would see all tickets

Ticket duplication checks occur globally instead of per-user

No ability to support multiple users securely

Business rules and permissions cannot be enforced correctly

This ticket introduces a user_id FK column on tickets and updates both reads and writes so that each ticket belongs uniquely to the authenticated user.

Current Behavior

InsertTicket() inserts tickets without user_id

Duplicate detection compares only game type + numbers + draw date

/account/tickets lists all stored tickets (not filtered)

Why This Matters

Prevents data leakage between accounts

Enables scalable multi-user operation

Allows user-specific duplicate logic and statistics

Aligns ticketing system with authenticated session model

Scope
✅ Database schema update

Add: user_id BIGINT NOT NULL (FK to users.id)

Add index: INDEX idx_tickets_user (user_id)

✅ Update storage layer (storage.InsertTicket)

Accept and store user_id

Include user_id in duplicate check

Update SQL queries accordingly

✅ Update ticket model (models.Ticket)

Add UserID int64

✅ Update handlers (handlers/account/tickets/add.go, list.go)

Extract user_id from session

Pass into InsertTicket

Select only tickets where user_id = ?

✅ Data migration — if needed

Optionally assign existing tickets to first admin user or mark orphaned

✅ Functional test cases

Each user sees only their tickets

Duplicate logic scoped individually per user

Non-Goals

No UI or behavioral changes to form fields

No admin-level ticket visibility enhancements (separate ticket)

Risks

Breaks existing unowned tickets unless migrated

Requires coordinated schema + code deploy

Acceptance Criteria
✅ Tickets are isolated to each authenticated user
✅ Queries include WHERE user_id = ?
✅ Duplicate check uses user scope
✅ No user sees another user’s tickets
✅ Database constraints prevent orphan records

Effort Estimate:
Medium (1–2 dev days)

Currently, ticket records stored in the my_tickets table are not associated with any user account. This means: Any authenticated user would see all tickets Ticket duplication checks occur globally instead of per-user No ability to support multiple users securely Business rules and permissions cannot be enforced correctly This ticket introduces a user_id FK column on tickets and updates both reads and writes so that each ticket belongs uniquely to the authenticated user. Current Behavior InsertTicket() inserts tickets without user_id Duplicate detection compares only game type + numbers + draw date /account/tickets lists all stored tickets (not filtered) Why This Matters Prevents data leakage between accounts Enables scalable multi-user operation Allows user-specific duplicate logic and statistics Aligns ticketing system with authenticated session model Scope ✅ Database schema update Add: user_id BIGINT NOT NULL (FK to users.id) Add index: INDEX idx_tickets_user (user_id) ✅ Update storage layer (storage.InsertTicket) Accept and store user_id Include user_id in duplicate check Update SQL queries accordingly ✅ Update ticket model (models.Ticket) Add UserID int64 ✅ Update handlers (handlers/account/tickets/add.go, list.go) Extract user_id from session Pass into InsertTicket Select only tickets where user_id = ? ✅ Data migration — if needed Optionally assign existing tickets to first admin user or mark orphaned ✅ Functional test cases Each user sees only their tickets Duplicate logic scoped individually per user Non-Goals No UI or behavioral changes to form fields No admin-level ticket visibility enhancements (separate ticket) Risks Breaks existing unowned tickets unless migrated Requires coordinated schema + code deploy Acceptance Criteria ✅ Tickets are isolated to each authenticated user ✅ Queries include WHERE user_id = ? ✅ Duplicate check uses user scope ✅ No user sees another user’s tickets ✅ Database constraints prevent orphan records Effort Estimate: Medium (1–2 dev days)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SynLotto/website#18