Custom fields - #54
Open
MangoSwirl wants to merge 7 commits into
Open
Conversation
|
🚅 Deployed to the lovat-server-pr-54 environment in lovat
|
Let scouting leads define custom post-match questions (text, number, single-select, multi-select) that scouts answer in Lovat Collection and that surface across the dashboard's analysis, scoped per source team. - New CustomField / CustomFieldAnswer models + Zod/OpenAPI mirrors - Lead-only CRUD plus a public x-team-code manifest endpoint for offline caching - Optional customFieldAnswers on both scout-report submission handlers (lenient: unknown/wrong-team/out-of-options answers dropped, report kept) - Answers flow into raw report data, both CSV exports, category metrics + detail sparklines (number), breakdown distributions (select), and picklist z-scores (number) via a cf_<uuid> key convention - Per-viewer cache isolation so custom data never leaks across teams - Fully additive/backwards-compatible Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MangoSwirl
force-pushed
the
custom-fields
branch
from
August 2, 2026 04:47
abc7a9a to
ca0b1a9
Compare
This was referenced Aug 2, 2026
getNotes returns each report's Text custom answers (customTextAnswers), scoped by the same data-source rule as notes so it stays cache-safe, and now includes reports that have only a text answer. Both raw scout report endpoints return custom answers to any viewer who can see the report (not just the source team), since they display inline with their question names. Aggregate surfaces (categories/breakdowns/picklists) stay own-team-scoped. Co-Authored-By: Claude <noreply@anthropic.com>
getNotes returns each report's uuid so note cards can open the raw report.
matchPageSpecificScouter returns canModify (scouting lead of the report's
team) plus the answers' source team, so the client can gate editing and
label the section ("Asked by your team" vs another team's). Answer views
carry their own uuid. New endpoint PUT /manager/customfields/answers/:uuid
lets a scouting lead of the field's team edit a text answer.
MangoSwirl
force-pushed
the
custom-fields
branch
from
August 3, 2026 22:58
9d470fb to
3a8a49e
Compare
CustomFieldAnswersInputSchema (strict: value string<=1000 | number | string[<=80]<=30, fieldUuid required) was embedded in the top-level .parse, so a single oversized/malformed custom answer threw a ZodError and 400'd the whole match report — contradicting the documented lenient design. Parse the field with a permissive wire schema (array of unknown, length-capped) and let validateCustomFieldAnswers do all per-answer validation by dropping/clamping (now also guarding non-object entries, non-string fieldUuids, over-long text, and oversized multi-selects). The strict schema is kept for the OpenAPI docs.
The NO_SCHEDULE guard checked matchesResponse/teamsResponse for null, but it sat after the code already dereferenced matchesResponse.headers.etag (both are always non-null there since the try/catch returns or throws), so it could never fire and the handler's 404 "No schedule available" path was dead. Replace it with a real check — no qualification matches after filtering — placed before the schedule is built, so tournaments without a posted schedule return 404 instead of an empty one.
playoff_type selection fell through to the 4-team double-elim map for ANY type other than 10, so a single-elimination (or other non-double-elim) event had its elim matches forced through the 4-team ordering — mis-numbering some and silently dropping the rest. Map only playoff_type 10 (8-team) and 11 (4-team); any other type gets an empty order map so elim matches are skipped rather than mis-imported (qualification import is unaffected). Also remove a leftover console.log that dumped the entire TBA event payload on every import.
…route checkMatchExists (security: [], no requireAuth) returned the raw caught error via res.status(500).send(error) on any DB/TBA failure, disclosing internal details to anonymous callers. Log it server-side and return a generic "Internal server error" instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the custom fields feature: scouting leads define their own post-match questions (text, number, single-select, multi-select) that scouts answer in Lovat Collection and that surface across the dashboard's analysis, scoped per source team.
What's here (backend)
CustomField+CustomFieldAnswer(typed value columns) with Zod/OpenAPI mirrors;SharedPicklist.customFieldWeights. Purely additive (prisma db push)./v1/manager/customfields, plus a publicx-team-codemanifest endpoint ({hash, data}) for the collection app's offline cache. Options are append/reorder-only; type is immutable.customFieldAnswerson both scout-report handlers. Lenient — unknown/wrong-team/out-of-options/archived answers are handled gracefully and never reject the report.cf_<uuid>key convention.augmentResponsehook + viewer-scoped cache keys, so custom data never leaks across teams.Testing
Validated end-to-end against a local server restored from a production dump: CRUD via the real dashboard UI, submission via the real collection app, and every analysis surface (raw report, CSV, category avg, sparkline, breakdown distributions, picklist), plus cross-team isolation and backwards-compat.
npm run build(tsc) + eslint clean.Related PRs — this feature spans four repos: