Règles d’éditabilité d’une candidature

Traduction

Cette page est une traduction de la version anglaise, qui fait foi.

Contexte

Après la soumission d’une candidature, toutes les données associées ne restent pas éditables. Ce document définit quels champs deviennent modifiables ou immuables en conséquence du cycle de vie d’une candidature.

Principe

Une fois qu’une candidature atteint l’état submitted :

• les données structurelles sont figées
• les données contextuelles restent éditables
• les données liées au cycle de vie n’évoluent qu’au travers de transitions d’état explicites

Ces règles permettent de préserver l’exactitude historique tout en autorisant un enrichissement progressif.

Matrice des champs éditables

Champ	Entité	Nature	Éditable après soumission
title	Position	Structurelle	Non
company	Position	Structurelle	Non
location	Position	Contextuelle	Oui
notes	Position	Contextuelle	Oui
notes	Application	Contextuelle	Oui
status	Application	Cycle de vie	Oui (contrôlé)
applied_at	Application	Cycle de vie	Non

Interaction avec le cycle de vie

Les règles d’éditabilité s’appliquent à partir de l’état submitted.

Les états terminaux (rejected, accepted) n’assouplissent pas ces contraintes. Les données structurelles restent figées pour l’ensemble du cycle de vie.

Justification

• préserver l’exactitude historique de l’offre d’emploi
• permettre un enrichissement progressif au fil du processus de recrutement
• éviter une complexité inutile des modèles dans les versions initiales

Notes d’implémentation

• l’application des règles se fait au niveau des services métier
• les policies gèrent la propriété des données, pas leur éditabilité
• les modèles ne contiennent aucune logique conditionnelle liée à l’éditabilité