Pular para o conteúdo principal

MatchPermissionsDto

@raizfc/contracts


@raizfc/contracts / MatchPermissionsDto

Type Alias: MatchPermissionsDto

MatchPermissionsDto = Readonly<{ canCancel: boolean; canContest: boolean; canEditSchedule: boolean; canFinishWithoutResult: boolean; canManageReport: boolean; canReportResult: boolean; canRetify: boolean; canStart: boolean; canValidate: boolean; }>

Defined in: match/match.dto.ts:86

Viewer-scoped action affordances for the management detail screen, computed server-side from the actor's team.manageMatches membership crossed with canApplyMatchTransition. canManageReport (IS-MVP-06.2, reuses isMatchReportEditable) gates the súmula editor (lineups/events). canReportResult/canValidate (IS-MVP-06.3) reuse team.manageMatches the same way every other action in this DTO does, but canValidate additionally requires the actor's authority to come from the team that is not MatchDto.result.reportedByTeamId (SPEC-DOMAIN- MATCH-001 "Validação por gestor do mesmo time que informou: bloquear quando exigida contraparte") — the "contraparte" case EP-MVP-06.1/06.2 explicitly left unresolved. canContest (IS-MVP-06.4) reuses the exact same contraparte rule canValidate already resolved — contest and validate are mutually exclusive actions available to the same actor while waiting_validation, gated further by the 72h contest window (isMatchResultWindowOpen). canRetify covers both resolve (contestedvalidated/cancelled) and request_retification (validatedcontested, immediately resolved by the same endpoint) — unlike canValidate/canContest, it does not require the contraparte specifically: no Championship/Operação authority exists yet in this MVP (IS-MVP-07.x/an "Operação" actor are not built), so it reuses the simpler "either side manages" model start/finish/cancel already established since IS-MVP-06.1 — a decision registered in the EP-MVP-06.4 handoff, not a silent gap.