10 KiB
10 KiB
phase, plan, type, wave, depends_on, files_modified, autonomous
| phase | plan | type | wave | depends_on | files_modified | autonomous | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 01-registration-form-update | 01 | execute | 1 |
|
false |
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_participantcolumns. - Updated admin list/detail screens showing new fields.
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
<acceptance_criteria>
AC-1: Public Form Matches DOCX
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
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
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
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
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>
Task 1: Add participant persistence fields and SQL migration _rejestracja/core/_model/MfParticipant.class.php, _rejestracja/controller/IndexController.php, _rejestracja/sql/2026-04-24-registration-form-update.sql 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. 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. AC-2 satisfied: every new submitted value has a model field, save assignment, getter, and SQL column. Task 2: Update public form, client price logic, and confirmation summary _rejestracja/template/partial/Index/Index.tpl, _rejestracja/template/partial/Index/IndexSent.tpl, _rejestracja/controller/IndexController.php 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. 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. AC-1, AC-3, and AC-5 satisfied. Task 3: Update administrator list/detail display and payment edit flow _rejestracja/Admin/controller/CalcController.php, _rejestracja/Admin/template/partial/Calc/Reg.tpl, _rejestracja/Admin/template/partial/Calc/RegEdit.tpl 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. 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. AC-4 satisfied. Client-facing registration form and admin display changes. 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. Type "approved" to continue to UNIFY, or describe the issues to fix.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.
<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>