La revue de sécurité a relevé que les écritures de TimeEntry (Post/Patch/Delete)
étaient gardées par time-tracking.entries.view : une permission de lecture
accordait l'écriture (confusion lecture/écriture, least-privilege).
- Ajout de la permission time-tracking.entries.manage (catalogue cohérent avec
les autres modules en view/manage).
- Écritures TimeEntry recâblées sur entries.manage ; self-service conservé
(object.getUser() == user). Lecture inchangée (entries.view).
Les formulaires d'ajout/édition client et prospect ne conservent que le champ
« Nom société ». Les coordonnées (email, téléphone) et les champs prospect
(société, statut, source, notes) sont retirés : ils seront gérés via Contact.
Le statut prospect prend son défaut New à la création ; DTO assouplis, payload
réduit à { name }.
Les ressources métier (ProjectManagement, Directory, TimeTracking) étaient
gardées par is_granted('ROLE_USER')/'ROLE_ADMIN', ignorant les permissions
RBAC granulaires déclarées par les modules : un utilisateur sans permission
voyait quand même projets, tâches, clients, etc.
- PermissionVoter : le regex excluait les tirets, donc project-management.* et
time-tracking.* n'étaient supportées par aucun voter (refus pour tous, admin
compris car le bypass ROLE_ADMIN est interne au voter). Ajout du tiret.
- Câblage des permissions *.view (lecture) / *.manage (écriture) sur les 17
ressources métier. Métadonnées tâches lisibles via projects.view OR tasks.view.
Directory partagé client/prospect via clients.* OR prospects.*. TimeEntry
conserve le self-service (object.getUser() == user).
- Sidebar : gating par permission effective des onglets Projets / Mes tâches /
Suivi du temps (config/sidebar.php).
- Test fonctionnel ProjectAccessControlTest (0 perm -> 403, view -> 200,
view ne donne pas l'écriture -> 403).
Matthieu