mtg: classify deck operations as read, edit and owner
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend-api-design
Research direction
Start with parent issue #155 for the deck operation classification, then locate the deck handlers and their existing owner checks. Map each operation to the read, edit or owner lists in this issue and route its handler through the shared access check. Run the existing mtg tests and confirm the OpenAPI spec is unchanged; denied operations should still respond exactly like a missing deck.
Written by the indexing model from the issue text.
Description
Parent
#155
What to build
Prefactor for deck Collaborators: every deck operation goes through one access check that classifies it as read, edit or owner, and that check resolves the caller to owner, Editor or Viewer. Only the owner can occur yet, so nothing changes for users. Later tickets then only widen the check instead of touching every deck handler again.
The classification (from #155):
- read: deck, cards, tags, statistics
- edit: deck update, colours, bracket, rule zero, advisor settings, card add, import, update, delete, deck-local tag create, update and delete, tag assign and unassign
- owner: visibility, share token, folder, attach and detach collection, sourcing, drift, take, fill and return cards, delete, Collaborator management
Acceptance criteria
- Every deck operation is classified as read, edit or owner in one place, and its handler asks the access check for that class instead of hand-rolling an owner check
- The access check can express owner, Editor and Viewer outcomes; today only owner is ever granted, and a denied operation still answers exactly like a missing deck
- No API or behaviour change: the OpenAPI spec is unchanged and all existing mtg tests pass
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- Avg merge
- 10h 20m
- Merged PRs (30d)
- 36
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from myOmikron/code
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
myOmikron/code#102 · 2 comments ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 5/5 Over a week Newbie friendliness 18/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 76/100
logto-io/logto#9837 · 1 comment ·
Maintainers usually reply within 1 day
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 76/100
lingdojo/kana-dojo#32964 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
Documentation status: needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
mastra-ai/mastra#28194 · 1 comment ·
Maintainers usually reply within 1 day
-
priority-low refactor-3
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days