Projet

Général

Profil

Actions

Bug #7586

fermé

Export ICS non conforme

Ajouté par David Lesimple il y a environ 8 ans. Mis à jour il y a environ 8 ans.

Statut:
Closed
Priorité:
Normal
Assigné à:
Début:
23/02/2016
Echéance:
% réalisé:

100%

Temps estimé:
Navigateur:
Tous
Votre version de Silverpeas:
5.15
Système d'exploitation:
Votre base de données:
PostgreSQL
Livraison en TEST:
Livraison en PROD:

Description

Depuis que nous avons synchronisé via le lien ICS un calendrier Silverpeas avec le gestionnaire de calendrier de Zimbra, nous avons provoqué un ralentissement significatif de notre messagerie.
La synchronisation est programmée toutes les 5 mn et celle-ci provoque à chaque fois suppression et rénscription des rendez vous sur la bdd Zimbra.
Quand on consulte le fichier texte généré par le lien ICS du calendrier Silverpeas, on constate que l'UID de chaque rendez vous change à chaque consultation parce que cet UID est manifestement timestampé, malgré pourtant que le timestamp de la synchronisation soit indiqué dans la variable DTSTAMP.
Chaque rendez vous est donc considéré comme différent du précédent qui est donc supprimé et recréé.
Les modifications entraînées sur la bdd zimbra sont donc trop importantes et ralentissent la messagerie.

Merci de m'indiquer ce que vous pouvez faire par rapport à ce mode de fonctionnement qui semble t'il n'est pas conforme aux modes de synchronisations des calendriers par ICS.

Mis à jour par Nicolas Eysseric il y a environ 8 ans

  • Sujet changé de synchronisation des calendriers via ics avec un système de messagerie impacte la messagerie groupware à Export ICS non conforme
  • Statut changé de New à In progress...
  • Assigné à mis à Nicolas Eysseric
  • Version cible mis à Version 5.15.2

L'UID de chaque événement est en effet différent à chaque export.

SUMMARY:Test bug #7586
UID:20160309T165908Z-UID@XXX.XXX.XXX.XXX

SUMMARY:Test bug #7586
UID:20160309T170407Z-UID@XXX.XXX.XXX.XXX

Cela n'est pas correct en effet.

L'UID sera généré à partir de l'identifiant de l'événement (unique au sein de la plate-forme). Cette donnée associée à l'adresse IP assurera que l'identifiant iCal sera unique et qu'il ne changera pas.

Mis à jour par Nicolas Eysseric il y a environ 8 ans

  • Statut changé de In progress... à Resolved
  • % réalisé changé de 0 à 100
Les Uid ne changent donc plus entre deux exports iCal. Ils sont désormais de la forme suivante : Traité par PR :

Mis à jour par Miguel Moquillon il y a environ 8 ans

  • Statut changé de Resolved à Integration in progress...

Mis à jour par Miguel Moquillon il y a environ 8 ans

  • Statut changé de Integration in progress... à Closed

Intégré en 5.15 et en 6.0

Actions

Formats disponibles : Atom PDF