bert.hausmans/crewli
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(form-builder): align artist_advance with engagement-scoped sections

Browse Source 
§3.2.5: clarify that advance_sections are engagement-scoped (not
artist-scoped). One master artist with two engagements advances each
trajectory independently. Drop the prose section enumeration that
predated the AdvanceSectionType enum and conflated section names
with section types — section type is the enum, name is a free string,
default seeds land in Session 3 with ArtistAdvanceDefault.

§17.3: footnote on the artist_advance row documenting engagement
context resolution — ArtistResolver::fromPortalToken looks up
artist_engagements.portal_token, returns the master Artist as subject,
populates form_submissions.event_id from the engagement.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
bert.hausmans
2026-05-08 18:48:38 +02:00
parent 7e4db29b2b
commit ad6bf3b44d
1 changed files with 24 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
dev-docs/ARCH-FORM-BUILDER.md
View File

@@ -347,18 +347,31 @@ company-type (supplier/partner/etc.), KvK-nummer, BTW-nummer.
**Who creates:** org-level schema (one per org), seeded from
`ArtistAdvanceDefault`. Schema has `section_level_submit=true`.
**Who submits:** artist via portal_token (no authentication required).
**Who submits:** tour manager / artist representative via the
engagement's `portal_token` (RFC-TIMETABLE v0.2 §5.3) — no
authentication required.
**Section model:** `advance_sections` rows are scoped to
`engagement_id` (per-event), not to `artist_id` (master). One master
artist with two engagements (e.g. Vrijdag and Zaterdag of the same
festival) advances each engagement on its own trajectory.
Section-type categorisation is driven by the `AdvanceSectionType`
enum (see RFC v0.2 §10 + `App\Enums\Artist\AdvanceSectionType` —
`guest_list | contacts | production | custom`). Section labels
live in `advance_sections.name` (string 80). Default-section seeds
are defined in Session 3 (`ArtistAdvanceDefault`).
**Submission flow:**
1. Artist receives email with portal link (triggered by organiser)
2. Opens link → token resolved, submission fetched or created
3. Form shown with sections: General Info, Contacts, Production (power,
catering, transport), Technical Rider, Hospitality
4. Artist fills sections independently; each section submit separately
5. On section submit: FormSubmissionSectionSubmitted event fires
1. Tour manager receives email with portal link (triggered by organiser)
2. Opens link → engagement resolved from `portal_token`, submission
fetched or created with the master `Artist` as subject (see §17.3)
3. Form shown with the engagement's `advance_sections`
4. Sections are filled independently; each section submits separately
5. On section submit: `FormSubmissionSectionSubmitted` event fires
6. Organiser reviews per section → section status approved/rejected/
changes_requested
7. When all sections approved: FormSubmissionSubmitted fires at submission level
7. When all sections approved: `FormSubmissionSubmitted` fires at the
submission level
8. Integration: triggers accreditation generation per ARCH-07 (future)
**Mode:** draft_single.
@@ -2358,8 +2371,10 @@ support.
| Slug | Label (NL) | Subject type | Default submission mode | Public access | Required bindings |
|------|-----------|--------------|-------------------------|---------------|-------------------|
| `event_registration` | Aanmelding vrijwilligers/crew | person | single | yes | `person.email`, `person.first_name`, `person.last_name` |
| `artist_advance` | Artiest advance | artist | draft_single | no | — |
| `artist_advance` | Artiest advance | artist | draft_single | no | — |[^artist-advance-engagement] |
| `supplier_intake` | Leverancier intake | company | single | no | `company.name` |
[^artist-advance-engagement]: *Engagement context resolution: `ArtistResolver::fromPortalToken` looks up `artist_engagements.portal_token` to find the engagement, then returns the engagement's master `Artist` as `subject`. The engagement's `event_id` populates `form_submissions.event_id` per WS-4 denormalisation. The advance-section breakdown lives per engagement (see §3.2.5 + RFC-TIMETABLE v0.2 §5.3), so multi-event artists get multi-trajectory advancing.*
| `post_event_evaluation` | Evaluatie na afloop | person | single | no | — |
| `incident_report` | Incident-melding | person | multiple | no | — |
| `signature_contract` | Contract-ondertekening | user | single | no | — |