first commit

This commit is contained in:
2026-04-24 15:32:21 +02:00
commit 20d40fead4
5046 changed files with 641038 additions and 0 deletions

17
.paul/PROJECT.md Normal file
View File

@@ -0,0 +1,17 @@
# Aktualia.com.pl Registration
## Project
Legacy PHP/Smarty registration form at `/_rejestracja/` for Aktualia conference registration.
## Current Request
Update the public registration form according to:
`D:/temp/pomysloweprezenty.pl/Rejestracja na XXXV Konferencję poprawki.docx`
The changes must be persisted in the database and visible in the administrator panel.
## Constraints
- Keep the existing legacy PHP/Smarty architecture.
- Avoid broad refactors outside the registration flow.
- Preserve existing pricing/admin content management behavior unless explicitly changed by the plan.
- Treat database schema changes as deployment-critical and document them in SQL.

14
.paul/ROADMAP.md Normal file
View File

@@ -0,0 +1,14 @@
# Roadmap
## Milestone v0.1: XXXV Konferencja Registration Update
Status: In progress
### Phase 1: Registration Form Update
Status: Planning
Goal: Align the public registration form, persisted participant data, confirmation email/summary, and administrator panel with the client-provided DOCX changes.
Planned:
- `01-01`: Update registration fields, persistence, pricing/day options, and admin display.

26
.paul/STATE.md Normal file
View File

@@ -0,0 +1,26 @@
## Current Position
Milestone: v0.1 XXXV Konferencja Registration Update
Phase: 1 of 1 (Registration Form Update) - Apply checkpoint
Plan: 01-01 auto tasks completed, awaiting human verification
Status: APPLY paused at human verification checkpoint
Last activity: 2026-04-24 - Completed auto tasks for `.paul/phases/01-registration-form-update/01-01-PLAN.md`
Progress:
- Milestone: [----------] 0%
- Phase 1: [########--] 80%
## Loop Position
Current loop state:
```text
PLAN --> APPLY --> UNIFY
* * o [Auto tasks complete, human verification pending]
```
## Session Continuity
Last session: 2026-04-24
Stopped at: Human verification checkpoint for Plan 01-01
Next action: Apply SQL migration on staging/production copy, test registrations, then run `$paul-unify 01-01` after approval
Resume file: `.paul/phases/01-registration-form-update/01-01-PLAN.md`

View File

@@ -0,0 +1,51 @@
# APPLY Results: 01-01
Date: 2026-04-24
## Completed Tasks
### Task 1: Add participant persistence fields and SQL migration
Status: pass
Notes:
- Added new fields/getters/setters/mappings to runtime model `_rejestracja/core/model/MfParticipant.class.php`.
- Mirrored fields in `_rejestracja/core/_model/MfParticipant.class.php` because the plan named `_model`, but runtime autoload uses `core/model`.
- Added SQL migration `_rejestracja/sql/2026-04-24-registration-form-update.sql`.
- Updated `_rejestracja/controller/IndexController.php` to persist participation option, selected days, lodging flag, diet, special diet, and surcharge flags.
### Task 2: Update public form, client price logic, and confirmation summary
Status: pass
Notes:
- Added one-day with lodging and one-day without lodging day selections.
- Added hidden canonical participation fields for backend persistence.
- Added dietary preference and special diet text field.
- Added confirmation summary output for participation, days, surcharges, and diet.
### Task 3: Update administrator list/detail display and payment edit flow
Status: pass
Notes:
- Added `RegEditAction` to `_rejestracja/Admin/controller/CalcController.php`.
- Added new data to admin registration list and detail template.
- Preserved payment status edit flow in `RegEdit.tpl`.
## Verification
- `php -l _rejestracja/core/model/MfParticipant.class.php`: pass
- `php -l _rejestracja/core/_model/MfParticipant.class.php`: pass
- `php -l _rejestracja/controller/IndexController.php`: pass
- `php -l _rejestracja/Admin/controller/CalcController.php`: pass
## Deviations
- Runtime uses `_rejestracja/core/model`, not `_rejestracja/core/_model`; implementation updated both to keep generated/model copies aligned.
- The public template contains legacy mojibake text. New labels were added mostly as ASCII where patching exact legacy-encoded strings was unreliable.
## Blocking Checkpoint
Manual verification is still required:
1. Apply SQL migration to a staging database.
2. Submit test registrations for full conference, one day with lodging, and one day without lodging plus special diet.
3. Confirm confirmation email/page and admin panel show saved values and prices.

View File

@@ -0,0 +1,197 @@
---
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>