#873 [Relaunch] rework: two-button relaunch widget and direct reminder form

[evarisk-kilyan]

Proposition pour la refonte des boutons de relance. Les trois cases de l'issue sont couvertes : refonte des boutons, deux boutons gauche/droite avec leurs interactions, et refonte du panneau d'ajout de rappel direct.

Le parti pris

Le texte de l'issue et les annotations de la maquette ne décrivent pas la même chose : le texte décrit la création (gauche = événement complet + rappel, droite = rappel direct), les annotations décrivent le contenu (gauche = le passé avec une alerte sur les éléments en retard, droite = les événements à venir à faire). Les deux se réconcilient si le compteur et le panneau portent la dimension temporelle, et le + la dimension création. C'est ce qui est implémenté.

• Bouton gauche — le passé. Compteur de tout ce qui est daté avant maintenant, avec un badge du nombre d'éléments jamais réalisés. Deux niveaux d'alerte : ambre dès le dépassement, rouge au-delà du seuil natif de l'agenda (MAIN_DELAY_ACTIONS_TODO, surchargeable par REEDCRM_RELAUNCH_LATE_DELAY_DAYS). Son + ouvre le formulaire complet existant, inchangé.
• Bouton droit — à venir. Compteur des événements futurs encore à faire, en style creux quand il n'y en a aucun : une opportunité sans prochaine étape est l'anomalie à repérer en balayant la colonne. Son + ouvre le nouveau formulaire de rappel direct.
• Panneau. Reprend le format de la maquette, date – type – qui – quoi – statut, avec la puce colorée du type et les lignes en retard surlignées.
• Rappel direct. Objet, type, quand (avec raccourcis demain / 3 jours / 1 semaine), qui. Rien d'autre.

Architecture

Le nouveau lib/reedcrm_relaunch.lib.php devient la source unique de vérité et remplace les quatre copies divergentes du markup des pastilles (helper de liste saturne, hook de fiche, hook de liste native, barre PWA) ainsi que les trois implémentations du comptage. Les surfaces ne choisissent plus qu'un habillage.

Le comptage passe d'un ActionComm::getActions() par ligne, qui charge chaque événement en entier pour n'incrémenter que des compteurs (1 + 2N requêtes par ligne de liste), à une seule requête agrégée mémoïsée. Le panneau tient en deux requêtes quel que soit le volume.

La lecture unionne enfin les deux catégories, relance et rappel. Sans cela le bouton droit serait structurellement vide : les rappels sont volontairement exclus du tag de relance pour ne pas gonfler les compteurs, et ce sont les seuls événements que le module crée avec une date future et un statut à faire.

Corrections embarquées

• Le rappel est créé sur un nouvel ActionComm. L'ancien code mutait et re-créait l'objet de l'événement principal, ce qui laissait le rappel avec le fk_action de l'événement alors que son code disait AC_OTH, et écrivait une ressource socpeople/0 parasite quand aucun contact n'était choisi.
• Un rappel en échec ne fait plus échouer l'événement : $result n'est plus réutilisé pour trois créations successives avant de conditionner la mise à jour de l'opportunité.
• Les handlers de modale ne sont plus liés deux fois. Le fichier est chargé une fois dans le bundle et une fois en clair par chaque page hôte, et event() ne dégageait pas ses liaisons : un clic sur un + déclenchait deux GET parallèles sur procard.php.
• La colonne « Qui » du panneau se remplit enfin. Elle lisait a.fk_contact, que le handler n'écrit jamais — seul socpeopleassigned est renseigné.
• dol_time_plus_duree() était appelée sans date.lib.php : fatal latent selon la page hôte.
• Les libellés du panneau ne sont plus des chaînes françaises en dur dans le JS ; ils passent par data-dialog-title, attribut déjà émis mais jamais consommé.

Fichiers

Nouveaux : lib/reedcrm_relaunch.lib.php, core/tpl/view/eventpro/view_eventpro_reminder.tpl.php, core/tpl/view/eventpro/relaunch_list_panel.tpl.php, css/scss/pages/_relaunch-widget.scss.

Modifiés : class/actions_reedcrm.class.php, lib/reedcrm_fields.lib.php, ajax/get_relaunches_list.php, core/tpl/view/eventpro/eventpro_actions.tpl.php, core/tpl/frontend/reedcrm_pwa_relaunch_bar.tpl.php, view/procard.php, view/frontend/pwa_relaunch.php, js/modules/eventpro.js, css/scss/pages/_pages.scss, les deux .lang.

js/reedcrm.min.js n'est pas régénéré dans cette PR. Le bundle était déjà en retard sur eventpro.js et toutes les pages hôtes rechargent le fichier en clair par-dessus, donc le comportement est correct sans rebuild — mais un npm run build reste à passer avant release.

Test

1. Fiche projet, liste des opportunités, liste projets native et page opportunité de la PWA : les quatre pastilles sont remplacées par les deux boutons, avec les mêmes totaux qu'avant.
2. Un projet avec un rappel passé non réalisé affiche le badge d'alerte sur le bouton de gauche.
3. Survol d'un bouton : le panneau liste sa période, les lignes en retard surlignées avec le nombre de jours.
4. + du bouton de droite : le formulaire de rappel direct, un raccourci de date, valider, puis vérifier que le compteur de droite s'incrémente et que l'événement créé porte bien le tag de rappel et un statut à faire.
5. Vérifier que le + du bouton de gauche ouvre toujours le formulaire complet et que la case « rappel » y fonctionne comme avant.

Points à arbitrer avant de fermer l'issue

L'issue dit « il faudra définir les interactions » et la maquette laisse une question ouverte. J'ai tranché pour livrer quelque chose de testable, mais trois décisions appartiennent au client :

1. Les passés non réalisés restent à gauche avec l'alerte, sans action de ligne. « Fait », « Reporter » et « Sans suite » sont volontairement hors de cette PR : reporter en déplaçant la date ou en créant un nouvel événement n'est pas la même décision d'audit, et il faut choisir avant d'écrire le chemin d'écriture.
2. Le statut « Non applicable » (percent = -1) est compté comme passé et jamais en retard.
3. Le rouge démarre au seuil natif de l'agenda, 7 jours sur cette installation, pas au lendemain de l'échéance.

Refs #873