Anomalie #15651
ferméFIX : notifications d’annotations
Description
Bonjour,
Les notifications d’annotations ne fonctionnaient pas en sélectionnant le type de diffusion « liste de diffusion », destinataire ou copie.
Version de Maarch Courrier : 20.03.13 chez le client, mais le code n’a pas été modifié après vérification sur le labs en 20.03.16.
Je mets ce ticket comme bloquant car le code actuel envoie parfois des notifications aux mauvaises personnes à propos de courriers ne les concernant pas, ce qui est un problème de confidentialité et de sécurité des données.
De plus, la solution est simple à comprendre et implémenter.
Modifications effectuées :
Pour les notifications AND (utilisateurs destinataires du courrier)
Dans le fichier /modules/notifications/diffusion_types/dest_user.php
, lignes 24 à 31 :
case 'notes':
$from .= ' JOIN notes ON notes.identifier = li.res_id';
$from .= ' JOIN res_letterbox lb ON lb.res_id = notes.identifier';
// remplacement de
// $where .= ' AND notes.id = :recordid AND us.id != notes.user_id'
// par
$where .= ' AND notes.identifier = :recordid AND us.id != notes.user_id'
.' AND ('
.' notes.id not in (SELECT DISTINCT note_id FROM note_entities) '
// remplacement de
// .' OR us.user_id IN (SELECT ue.user_id FROM note_entities ne JOIN users_entities ue ON ne.item_id = ue.entity_id WHERE ne.note_id = :recordid)'
// par
.' OR us.user_id IN (SELECT ue.user_id FROM note_entities ne JOIN users_entities ue ON ne.item_id = ue.entity_id WHERE ne.note_id = notes.id)'
.')';
:recordid
fait référence à un res_id
de courrier et non une notes.id
.
Il faut donc remplacer notes.id
par notes.identifier
quand on compare à :recordid
pour la cohérence.
Et à la fin de la requête, il faut utiliser l’identifiant de la notes notes.id
plutôt que l’identifiant du courrier :recordid
pour comparer avec ne.note_id
.
La même modification est à appliquer dans le fichier /modules/notifications/diffusion_types/copy_list.php
, par deux fois, une fois des lignes 28 à 36, une seconde des lignes 73 à 81.
Mis à jour par Support Maarch il y a environ 4 ans
- Statut changé de A qualifier à A traiter
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Statut changé de A traiter à R&D - A planifier
- Priorité changé de 0-Bloquant à 1-Majeur
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Echéance mis à 14/12/2020
- Statut changé de R&D - A planifier à Etude planifiée
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Statut changé de Etude planifiée à R&D - A planifier
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Projet changé de 298 à 299
- Echéance changé de 14/12/2020 à 15/02/2021
- Statut changé de R&D - A planifier à R&D - En cours
- vérifier en 20.10
Mis à jour par Emmanuel DILLARD il y a environ 4 ans
- Echéance changé de 15/02/2021 à 08/02/2021
Mis à jour par Guillaume HEURTIER il y a environ 4 ans
- Assigné à mis à Guillaume HEURTIER
Mis à jour par Guillaume HEURTIER il y a environ 4 ans
- Statut changé de R&D - En cours à R&D - Terminé
Après analyse, dans cette partie du code :recordid correspond bien à un identifiant de notes, il ne faut donc pas comparer avec le resId.
Vu avec Quentin, l'anomalie initiale est déjà résolu chez le client.
Mis à jour par Emmanuel DILLARD il y a plus de 3 ans
- Projet changé de 298 à Backlog Courrier
- Version cible changé de 20.03 (Fin de vie) à 20.03 (Sécurité)