---
phase: 01-registration-form-update
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
  - _rejestracja/controller/IndexController.php
  - _rejestracja/core/_model/MfParticipant.class.php
  - _rejestracja/template/partial/Index/Index.tpl
  - _rejestracja/template/partial/Index/IndexSent.tpl
  - _rejestracja/Admin/controller/CalcController.php
  - _rejestracja/Admin/template/partial/Calc/Reg.tpl
  - _rejestracja/Admin/template/partial/Calc/RegEdit.tpl
  - _rejestracja/sql/2026-04-24-registration-form-update.sql
autonomous: false
---

<objective>
## Goal
Update the Aktualia registration flow so the public form matches the client DOCX for XXXV Konferencja, all submitted values are saved in `mf_participant`, and the admin panel displays the new data.

## Purpose
The client needs the registration form at `https://aktualia.com.pl/_rejestracja/` to collect the updated conference options and expose them after submission for administration, invoicing, and participant handling.

## Output
- Updated public registration form and confirmation summary/email.
- Updated participant model and save mapping.
- SQL migration for new `mf_participant` columns.
- Updated admin list/detail screens showing new fields.
</objective>

<context>
## Project Context
@.paul/PROJECT.md
@.paul/ROADMAP.md
@.paul/STATE.md

## Client Source
@D:/temp/pomysloweprezenty.pl/Rejestracja na XXXV Konferencję poprawki.docx

## Source Files
@_rejestracja/controller/IndexController.php
@_rejestracja/core/_model/MfParticipant.class.php
@_rejestracja/template/partial/Index/Index.tpl
@_rejestracja/template/partial/Index/IndexSent.tpl
@_rejestracja/Admin/controller/CalcController.php
@_rejestracja/Admin/template/partial/Calc/Reg.tpl
@_rejestracja/Admin/template/partial/Calc/RegEdit.tpl
</context>

<acceptance_criteria>

## AC-1: Public Form Matches DOCX
```gherkin
Given a visitor opens /_rejestracja/
When they review the registration form
Then it contains the participant, invoice, talk/poster, consent, fee timing, conference duration, one-day date, lodging surcharge, accompanying person, dietary preference, and calculated price fields requested in the DOCX.
```

## AC-2: Submitted Values Are Persisted
```gherkin
Given a visitor submits a valid registration
When the form is processed
Then all new and existing values from the DOCX-backed form are stored in mf_participant and can be read back through MfParticipant getters.
```

## AC-3: Pricing And Day Options Are Correct
```gherkin
Given a visitor selects reduced or regular fee and a participation option
When they change lodging, accompanying person, one-day-with-lodging, one-day-without-lodging, or dietary options
Then the visible price and saved fee data reflect the selected options without losing existing full/three-day/two-day behavior.
```

## AC-4: Admin Panel Shows New Registration Data
```gherkin
Given an administrator opens Calc=Reg or a registration detail
When they inspect a submitted registration
Then the new fields are visible, readable, and grouped with participant, invoice, presentation, consent, participation, lodging, dietary, and payment information.
```

## AC-5: Confirmation Output Includes New Data
```gherkin
Given a visitor completes registration
When the confirmation page/email is generated
Then the summary includes the newly selected fields and the final net/gross price.
```

</acceptance_criteria>

<tasks>

<task type="auto">
  <name>Task 1: Add participant persistence fields and SQL migration</name>
  <files>_rejestracja/core/_model/MfParticipant.class.php, _rejestracja/controller/IndexController.php, _rejestracja/sql/2026-04-24-registration-form-update.sql</files>
  <action>
    Extend `MfParticipant` with explicit fields, constructor parameters, getters, setters, and `$fields` mappings for all new DOCX-backed values that are not safely represented today:
    - invoice fields already present: institution, address, post_code, city, nip; keep these names.
    - presentation fields already partly present: referat, poster, message/title, autor; keep these names.
    - add fields for participation duration/type, selected days/dates, one-day-with-lodging vs one-day-without-lodging, diet type, special diet text, accompanying person, single-room surcharge where needed beyond current serialized `fee_full`.
    - ensure existing calls such as `setLocation(1)` and admin display do not rely on missing model accessors; add `location` if the database already uses it.
    Update `IndexController` to read the new POST names, validate required values from the DOCX, populate the model, and save them.
    Create a SQL migration with `ALTER TABLE mf_participant ADD COLUMN ...` statements using conservative nullable `VARCHAR/TEXT/TINYINT` fields so existing registrations are not broken.
    Avoid: removing or renaming existing columns, because old registration records and admin templates depend on them.
  </action>
  <verify>Run `php -l _rejestracja/core/_model/MfParticipant.class.php` and `php -l _rejestracja/controller/IndexController.php`; inspect the SQL migration for only additive ALTER TABLE statements.</verify>
  <done>AC-2 satisfied: every new submitted value has a model field, save assignment, getter, and SQL column.</done>
</task>

<task type="auto">
  <name>Task 2: Update public form, client price logic, and confirmation summary</name>
  <files>_rejestracja/template/partial/Index/Index.tpl, _rejestracja/template/partial/Index/IndexSent.tpl, _rejestracja/controller/IndexController.php</files>
  <action>
    Update `Index.tpl` to reflect the DOCX wording and options:
    - use "Dane do wystawienia faktury" for invoice data.
    - update fee deadline text to 03.10.2026.
    - rename kongres wording to konferencja where the DOCX requests it.
    - support full conference, three days, two days, one day with lodging (3/4 listopada, 4/5 listopada), and one day without lodging (3 listopada, 4 listopada, 5 listopada).
    - add dietary preferences: standard diet, special diet, and free-text "jaka?" field shown when special diet is selected.
    - keep consent text aligned with the DOCX and keep required personal-data consent validation.
    Adjust JavaScript `calculatePrice()` and server-side price calculation in `IndexController` so visible totals and saved totals stay consistent for the supported participation options.
    Update `IndexSent.tpl` so the confirmation page and email include the selected duration/day(s), lodging/accompanying-person flags, diet preference, consent flags, and net/gross total.
    Avoid: hard-coding prices in only JavaScript while the server calculates a different total; if price IDs in `mf_parameters` do not cover new options, document required admin price records in the migration or plan summary.
  </action>
  <verify>Open the form locally or on staging, switch every participation option, and confirm the visible price and conditional fields update; submit a valid test registration and confirm `IndexSent.tpl` contains the new values.</verify>
  <done>AC-1, AC-3, and AC-5 satisfied.</done>
</task>

<task type="auto">
  <name>Task 3: Update administrator list/detail display and payment edit flow</name>
  <files>_rejestracja/Admin/controller/CalcController.php, _rejestracja/Admin/template/partial/Calc/Reg.tpl, _rejestracja/Admin/template/partial/Calc/RegEdit.tpl</files>
  <action>
    Update admin registration views:
    - `Reg.tpl` should show the new form values compactly in the registration list: invoice fields, presentation title/author, selected participation option/days, lodging/accompanying person, diet, consents, total, and payment status.
    - `RegEdit.tpl` should show the same data in grouped detail sections and preserve payment status editing.
    - `CalcController` should actually support the RegEdit POST flow if payment status editing is expected; update the participant status and redirect back to the registration list.
    Remove references to getters that are not part of `MfParticipant` unless they are implemented in Task 1.
    Avoid: changing unrelated admin menu items or content editing behavior.
  </action>
  <verify>Run `php -l _rejestracja/Admin/controller/CalcController.php`; open admin registration list and one registration detail after a test submit, then confirm all new values are visible and payment status can still be saved.</verify>
  <done>AC-4 satisfied.</done>
</task>

<task type="checkpoint:human-verify" gate="blocking">
  <what-built>Client-facing registration form and admin display changes.</what-built>
  <how-to-verify>
    1. Deploy/apply the SQL migration to a staging copy of the database.
    2. Visit `https://aktualia.com.pl/_rejestracja/` or the staging equivalent.
    3. Submit at least three registrations: full conference, one day with lodging, one day without lodging plus special diet.
    4. Confirm confirmation email/summary and admin panel show all selected data and prices.
  </how-to-verify>
  <resume-signal>Type "approved" to continue to UNIFY, or describe the issues to fix.</resume-signal>
</task>

</tasks>

<boundaries>

## DO NOT CHANGE
- `_rejestracja/core/lib/**`
- `_rejestracja/Admin/plugins/**`
- `_rejestracja/_Admin/**`
- compiled Smarty cache under `temp/compile`
- unrelated content-management modules

## SCOPE LIMITS
- This plan does not redesign the page visually beyond fields required by the DOCX.
- This plan does not change SMTP configuration, captcha keys, or admin authentication.
- This plan does not delete old registration data.
- This plan does not deploy SQL automatically to production; it creates the migration file and requires a staging/production database apply step.

</boundaries>

<verification>
Before declaring plan complete:
- [ ] `php -l _rejestracja/controller/IndexController.php`
- [ ] `php -l _rejestracja/core/_model/MfParticipant.class.php`
- [ ] `php -l _rejestracja/Admin/controller/CalcController.php`
- [ ] SQL migration contains only additive schema changes unless explicitly approved.
- [ ] A test registration persists all DOCX-backed fields.
- [ ] Admin list/detail show the same submitted values.
- [ ] Confirmation page/email shows the same submitted values and final price.
- [ ] Human verification checkpoint completed.
</verification>

<success_criteria>
- Public form matches the client DOCX for XXXV Konferencja.
- New fields are stored in `mf_participant`.
- Administrator can inspect the new fields.
- Confirmation output includes the new fields.
- Existing registration/payment status behavior remains intact.
</success_criteria>

<output>
After completion, create `.paul/phases/01-registration-form-update/01-01-SUMMARY.md`.
</output>

