Corrections et semaines validées

Deux mécanismes complémentaires : la demande de correction permet à un employé de faire corriger ses heures, la validation de semaine permet à un manager de déclarer une semaine vérifiée, et donc de la figer.

Les demandes de correction

Un employé ne modifie jamais ses heures lui-même. S'il a oublié de pointer, il demande une correction, avec un motif. Son manager l'examine, et c'est lui qui l'applique.

Ce que contient une demande

Champ	Contenu
work_date	le jour à corriger
issue	missing_clock_out, missing_clock_in, wrong_arrival, wrong_departure ou wrong_break
correct_time	l'heure juste, telle que l'employé la voit (heure locale)
correct_end_time	la fin de la pause, pour wrong_break seulement
reason	le motif, obligatoire (500 caractères au plus)
client_id	pour l'application : une demande envoyée deux fois n'est enregistrée qu'une fois

Les règles

Règle	Erreur
On ne demande que pour ses propres heures	403
Le jour n'est pas dans le futur	422 in_future
Le jour est dans les 4 dernières semaines (depuis le lundi d'il y a 3 semaines, avec un jour de marge pour les fuseaux)	422 too_old
Le jour n'est pas dans une semaine validée	409 week_validated
Une demande n'est décidée qu'une fois	409 conflict

Accepter une demande

Le manager ne se contente pas de « cocher » : il donne les heures à appliquer (start, end, et éventuellement la journée à modifier, working_time_id, avec ses pauses). L'API, dans une seule transaction :

1. verrouille la demande : deux managers ne peuvent pas décider en même temps ;
2. vérifie qu'elle est encore en attente ;
3. modifie (ou crée) la journée, avec les mêmes règles que toute modification de manager (pas de chevauchement, semaine non validée…) ;
4. ajoute la ligne du journal, liée à la demande (correction_request_id) ;
5. marque la demande acceptée, avec qui et quand.

Si une étape échoue, rien n'est enregistré, et la demande reste en attente. L'employé est ensuite prévenu que sa demande a été examinée. Il ne reçoit pas, en plus, l'avis « tes heures ont changé » : un seul message pour une seule décision.

Qui examine quoi

Qui	Examine
Manager	les demandes de ses gens, jamais la sienne
General Manager	toutes, la sienne comprise : personne n'est au-dessus de lui. Il ne modifie pourtant toujours pas ses heures directement : sa correction passe par une demande, motivée et journalisée

Les semaines validées

À la fin d'une semaine, le manager vérifie les heures d'une personne, puis valide la semaine. Elle est alors verrouillée.

Une semaine validée bloque	Erreur
créer, modifier ou supprimer une journée de cette semaine	409 week_validated
enregistrer ou supprimer une absence de cette semaine	409 week_validated
envoyer ou accepter une demande de correction sur cette semaine	409 week_validated
un pointage du téléphone daté de cette semaine (envoyé en différé)	409 week_validated

Les règles

Règle	Erreur
Une semaine commence un lundi	422 not_monday
On ne valide qu'une semaine terminée	422 not_over
Une semaine n'a qu'une validation en vigueur	422 taken
Valider : les managers de la personne, ou le GM, jamais soi	403
Rouvrir : le manager qui l'a validée, ou le GM	403

Rouvrir n'efface rien

Rouvrir une semaine remplit reopened_at (et qui l'a fait) ; la ligne reste. On garde ainsi la trace qu'une semaine a été validée, puis rouverte. La semaine peut ensuite être validée à nouveau : c'est une nouvelle ligne, et l'index week_validations_in_force_index garantit qu'une seule est en vigueur à la fois.

Le jour d'une heure

« Cette journée est-elle dans une semaine validée ? » dépend du jour de son début dans le fuseau de la mairie : une arrivée le lundi à 00:30 à Paris est encore dimanche en UTC. La conversion est faite par PostgreSQL (AT TIME ZONE 'Europe/Paris'), dans WeekValidations.locked_on?/2.

Les fichiers

Fichier	Rôle
lib/timemanager/corrections.ex	envoyer, rejouer, accepter, refuser
lib/timemanager/corrections/correction_request.ex	les règles d'une demande (4 semaines, futur, pause)
lib/timemanager/week_validations.ex	valider, rouvrir, le verrou (check_unlocked/2)