Toujours débuter par un dry‑run ou activer le mode verbose pour les commandes potentiellement destructrices. Conservez un journal des exécutions (timestamps + opérateur) et planifiez les commandes lourdes en dehors des fenêtres de production sensibles.

Résumé :

• Commande CLI : php artisan app:auto-sales-document-reminders

• Rôle : orchestre l’envoi quotidien de rappels pour factures impayées et de notifications pour les devis arrivant à échéance (comprend deux flux principaux : invoicesReminder et quotesReminder).

• Comportement clé : parcourt les apps (mode multi‑tenant) ou une app ciblée, détermine les destinataires en priorité depuis les adresses attachées au document (recipients) ; si aucune n’est présente, il consulte ensuite la liste fournie par available_recipients_emails exposée par le contrat du document (méthode du SalesDocumentContract retournant des adresses pertinentes liées au document, par ex. contacts commerciaux ou emails associés) ; si toujours aucun destinataire n’est trouvé, il utilise les contacts du siège social (“headquarters”) du client. Il n’effectue pas une recherche exhaustive parmi tous les contacts clients. Correction importante : la sélection des destinataires et le calcul des intervalles de relance ont été corrigés — la commande n’enverra des messages qu’aux adresses retournées par getDocumentRecipients (qui prend désormais en compte available_recipients_emails en plus des destinataires directement attachés au document et du headquarters), et calcule désormais correctement les délais de rappel (y compris le rappel « mid‑term » des devis) en se basant sur les dates pertinentes du document (par ex. date d’envoi du devis et date d’échéance). L’envoi est réalisé en s’authentifiant temporairement en tant qu’auteur du document (impersonation/login de l’utilisateur auteur) puis délégué au contrôleur d’e‑mail (EmailController) via la fonction sendDocument ; les actions sont journalisées.

• Note technique : available_recipients_emails est une méthode définie par le SalesDocumentContract. Les modèles de documents (factures/devis) doivent implémenter cette méthode pour fournir des adresses de secours ; la commande l’interroge directement lors de la résolution des destinataires. Si la méthode retourne vide ou null, la résolution passe au niveau suivant (headquarters) et, en l’absence d’adresses, l’envoi est ignoré pour ce document.

Avertissement important (nouveau comportement) :

• Le job s’exécute en impersonnant temporairement l’utilisateur auteur du document lors de la construction et de l’envoi du message. Cette impersonation permet au contrôleur d’e‑mail d’agir avec le contexte utilisateur (vérifications d’accès, génération de pièces jointes, etc.). Les événements d’impersonation et les envois sont enregistrés dans les journaux pour audit. Tenez‑en compte pour les audits et les règles d’accès : les actions seront attribuées à l’auteur dans les traces.
• Ce comportement d’impersonation a été stabilisé par la correction récente : l’utilisateur auteur est explicitement « loggé » pour la durée de la préparation/envoi afin que les contrôles d’accès et la génération des pièces jointes soient cohérents avec l’identité attendue.

Effets secondaires et scope d’application :

• Impersonation : les vérifications de permission et l’accès aux pièces jointes sont évalués sous l’identité de l’auteur du document. Si l’auteur n’a pas accès à certains éléments, l’envoi peut échouer ou les pièces jointes être absentes ; ces erreurs sont loggées et identifiables dans les journaux (raison de l’échec + utilisateur impersonné).
• Timing des relances : les intervalles et seuils ont été corrigés — les relances sont désormais calculées selon la configuration de l’app et en tenant compte des dates du document (ex. date d’envoi et date d’échéance pour les devis). En conséquence, certains documents peuvent être traités à un moment légèrement différent par rapport à la version précédente (correction d’un bug de calcul). Vérifiez les dates (emailed_at, due_date, valid_until) pour vous assurer du bon calendrier des envois.
• Portée : par défaut le job parcourt toutes les apps en multi‑tenant ; utilisez --app=APP_ID pour cibler une app spécifique et éviter un traitement global.
• Comportement pour documents sans destinataires : le job ne tente d’envoyer le message que si getDocumentRecipients retourne une liste d’e‑mails après avoir consulté, dans l’ordre, les destinataires du document, la liste available_recipients_emails exposée par le contrat du document, puis les contacts du siège social du client. Si aucune adresse n’est trouvée (liste vide), le job saute l’envoi pour ce document et n’appelle pas le système d’envoi — aucune tentative d’envoi d’un message sans destinataires n’est effectuée. Il n’existe pas d’option pour forcer l’envoi vers une liste vide. Ce comportement de sélection a été corrigé pour éviter les envois vers des destinataires non souhaités ou des résolutions erronées.

Journaux et supervision :

• Les actions sont loggées pour audit et diagnostic : on retrouve les traces d’impersonation, les tentatives d’envoi (par document), les raisons de saut (ex. aucun destinataire, permissions manquantes), les erreurs et les exceptions dans les logs applicatifs (ex. storage/logs/laravel.log).
• L’historique des e‑mails envoyés est également disponible dans l’interface d’administration (section Emails / Activité) pour vérifier destinataires et contenus envoyés.
• En mode --verbose, la commande produit des sorties détaillées incluant les informations d’impersonation, les motifs de non‑envoi et les envois document‑par‑document. En --dry-run, les envois ne sont pas effectués et l’état n’est pas muté (utile pour valider le comportement avant exécution réelle).

Options et modes d’exécution usuels :

• –app=APP_ID : exécuter uniquement pour l’app identifiée (recommandé pour relancer un traitement ciblé).
• –dry-run : simuler les envois sans envoyer d’e‑mails ni muter l’état (utile pour validation).
• –verbose : sortie détaillée pour débogage et suivi en temps réel.
• Par défaut la commande peut être planifiée quotidiennement via le scheduler (cron) pour traitement multi‑tenant.

Supervision et relance depuis l’administration :

• Vérifier les logs applicatifs (ex. storage/logs/laravel.log) et les journaux d’exécution des tâches planifiées pour identifier erreurs et exceptions.
• Consulter l’historique des e‑mails envoyés dans l’interface d’administration (section Emails / Activité) pour valider les destinataires et les contenus envoyés.
• Pour relancer le flux sur une app spécifique, utiliser la commande CLI avec --app=APP_ID depuis l’interface d’administration si elle expose l’exécution de commandes, ou exécuter la commande directement sur le serveur.
• En cas d’erreurs répétées, examiner les logs détaillés (mode verbose), corriger la configuration du mailer/tenant/contacts, puis relancer uniquement l’app impactée pour éviter retraitements globaux.

Notes opérationnelles :

• La commande regroupe l’envoi de rappels pour factures et devis : relancer manuellement pour une app ciblée évite de réexécuter l’ensemble des apps.
• Assurez‑vous que les documents (factures/devis) ont des destinataires configurés, que la méthode available_recipients_emails du document (définie par le SalesDocumentContract) renvoie bien des adresses pertinentes, ou que le client possède des contacts au niveau du siège social (“headquarters”) : sans ces adresses, le message sera ignoré pour ce document.
• Conserver les journaux d’exécution et les identifiants d’opération pour faciliter les investigations post‑incident.

• Nouvelle commande : php artisan app:count-qonto-clients

  • Rôle : effectue un comptage et un rapport des clients associés à Qonto (par ex. comptes Qonto connectés ou clients dont le moyen de paiement principal est Qonto) au travers des apps. Utile pour audits, réconciliations et vérifications opérationnelles liées à l’intégration bancaire Qonto.
  • Portée : multi‑tenant par défaut ; utiliser --app=APP_ID pour cibler une application.
  • Modes usuels : supporte les mêmes bonnes pratiques que les autres commandes (test en --dry-run, sortie détaillée en --verbose, exécution planifiée).
  • Résultat : fournit un résumé exploitable pour les rapports opérationnels ; exécutez en mode verbose pour obtenir le détail par client.

• Nouvelle commande : php artisan app:stats-naf-codes

  • Rôle : génère des statistiques et un rapport agrégé sur les codes NAF/APE utilisés par les clients (nombre de clients par code, répartition par app, détections d’anomalies). Utile pour analyses métier, reporting réglementaire et contrôle de qualité des données d’activité.
  • Portée : multi‑tenant par défaut ; utiliser --app=APP_ID pour cibler une application.
  • Modes usuels : supporte --dry-run pour simuler la collecte et --verbose pour obtenir le détail par client et par code.
  • Résultat : exportable en CSV/JSON selon les options (résumé global + détail par app), et conçu pour être consommé par des outils d’analyse ou des pipelines d’ingestion.

• Mise à jour importante : ExportPartnersWeekly (export hebdomadaire des partenaires)

  • La commande d’export hebdomadaire des partenaires a été modifiée récemment. Vérifiez le format de sortie et les options disponibles avant de l’intégrer à des pipelines automatisés (notamment si vous avez des scripts qui consomment un format/ordre de colonnes précis).
  • Recommandation : lancer l’export avec --dry-run ou --verbose après mise à jour pour valider les en‑têtes/colonnes et les critères de filtrage, et ajuster vos parsers/ingestions si nécessaire.