| Current Path : /var/git/cesa-v3/docs/specs/ |
| Current File : /var/git/cesa-v3/docs/specs/echasl23-admin-login-requirements.md |
# ECHASL23 (PHPMaker) users — login and admin requirements **System:** cesa-v3 **Status:** Approved for implementation **Related:** `cesa_main.echasl23` (PHPMaker7 admin users), `echasl23/` on cesa-main ## Background Legacy PHPMaker7 staff accounts live in `echasl23` with MD5-hashed passwords (`adminpassword = md5(plain)`). cesa-v3 already has `UserList` accounts and Sonata admin, but many staff still exist only in `echasl23`. They must be able to sign in to cesa-v3 and be manageable from Sonata without migrating every row to `user_list` first. ## User stories ### US-1: Sign in with echasl23 credentials As a staff member with an active `echasl23` account, I want to log in to cesa-v3 with my existing username and password so I can use the admin area without a separate account. ### US-2: Manage echasl23 users in Sonata As a CESA super admin, I want Sonata screens to list, create, edit, and disable echasl23 users so I can administer legacy accounts from cesa-v3. ### US-3: Password updates stay MD5-compatible When an admin sets or changes a password in Sonata, the stored value must remain MD5-compatible with PHPMaker (`md5(plain)`), so the same user can still use echasl23 on cesa-main if needed. ## Acceptance criteria 1. Form login tries `user_list` first, then `echasl23` (same username in both tables resolves to `user_list`). 2. Only users with `activated = 1` can authenticate via the echasl23 provider. 3. Password verification uses MD5 of the submitted password compared to `adminpassword` (case-sensitive, matching PHPMaker `EW_MD5_PASSWORD`). 4. Deactivated users cannot log in. 5. Users with `level < 0` receive super-admin Symfony roles (`ROLE_ADMIN`, `ROLE_SONATA_ADMIN`, etc.). 6. Other active users receive at least `ROLE_ADMIN` and `ROLE_SONATA_ADMIN` so they can reach `/admin` (aligned with legacy staff access). 7. Sonata group **System**, label **PHPMaker Users**, route prefix `echasl23-users`, fields: username, email, access level, activated, password (optional on edit), password changed date (read-only on edit). 8. `echasl23` table is mapped in Doctrine; business logic for hashing and roles lives in `Echasl23UserService`. 9. Unit tests cover MD5 verification and role mapping. ## Out of scope - Changing PHPMaker-generated files under `cesa-main/echasl23/`. - Migrating all echasl23 users into `user_list` (existing `iga:user:sync` command remains available). - Upgrading MD5 to bcrypt for echasl23 rows (future migration).