We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

Comportement étrange sur les événements périodiques

Benoit Chapel · on 1/14/14 at 9:14 AM

Bonjour,

Nous observons le comportement suivant :

Nous créeons un évenement périodique le vendredi de 8h à 10h avec une périodicité hebdomadaire.

L'événement mère (le premier) est OK.

En revanche, sur les occurences suivantes, deux personnes apparaissent systématiquement comme ayant refusé le dit évènement.

Nous avons regardé le code et il semblerait que les évenements "suivants" sont calculés. 

Avez vous déjà observé un tel comportement ?

Avez vous une idée de ce qui conduirait à ce comportement ? et des pistes pour le régler ?

 

9 pts
Ludovic Smadja · on 1/15/14 at 1:28 PM

La gestion des acceptations/refus est faite au niveau de l'événement de base et reporté sur les autres événements. Il n'est pas possible de saisir des acceptations/refus par occurrence d'événements périodiques.

0 pts
Benoit Chapel · on 1/15/14 at 3:21 PM

Merci d'avoir répondu.

Effectivement, c'est bien ce qu'on avait ramarqué en usage normal, les acceptations/refus sont ceux de l'évènement mère.

Le problème dans notre cas, c'est que les occurences suivantes d'un évènement périodique ont deux refus alors qu'il n'y en a pas dans l'évènement de base !

Nous pensons qu'il y a eu un effet de bord à un moment car ce comportement se reproduit pour TOUS les évènements périodiques de TOUS les membres !!!

Un avis ?

0 pts
Ludovic Smadja · on 1/15/14 at 3:25 PM

Les acceptations/refus sont stockés dans la base de données (table P_CALENDAR_ATTENDEE_DATA). Est-ce que les données de cette table sont corrompues ou invalides ? 

0 pts
Benoit Chapel · on 1/16/14 at 3:46 PM

J'ai regardé dans la table P_CALENDAR_ATTENDEE_DATA et les deux membres qui étaient marqués comme "declined" dans tous les évenements périodiques calculés avaient une ligne de cette table avec un event_id à null.

Après avoir supprimé ces deux lignes, si le problème demeure pour les événements périodiques dont l'événement de base est dans le passé, cela ne se produit plus pour les événements périodiques dont l'événement de base est dans le futur.

Je pense qu'il n'est pas normal d'avoir des lignes avec un event_id à null mais il doit y avoir des conditions où cela se produit quand même.

Qu'en pensez vous ?

 

#2

J'ai les erreurs suivantes :

An exception occurred when calling method afterWrite() for DataController com.jalios.jcmsplugin.calendar.schedule.EventScheduleController@4e10128 java.lang.NoSuchMethodError: com.jalios.jcms.db.HibernateUtil.deleteQuery(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/Object;)I at com.jalios.jcmsplugin.calendar.schedule.EventScheduleManager.deleteEventScheduleVote(EventScheduleManager.java:246) at com.jalios.jcmsplugin.calendar.schedule.EventScheduleController.afterWrite(EventScheduleController.java:65) at com.jalios.jcms.Data.controlWrite(Data.java:2840) at com.jalios.jcms.Data.controlAfterWrite(Data.java:2819) at com.jalios.jcms.Data.performDelete(Data.java:2796) at com.jalios.jcms.Publication.performDelete(Publication.java:5899) at com.jalios.jcms.Data.performDelete(Data.java:2769) at com.jalios.jcmsplugin.calendar.schedule.DeleteEventScheduleAlarmListener.handleTransactionalAlarm(DeleteEventScheduleAlarmListener.java:22) at com.jalios.jcms.db.TransactionalAlarmListener.handleAlarm(TransactionalAlarmListener.java:55) at com.jalios.jdring.AlarmManager.notifyListeners(AlarmManager.java:422) at com.jalios.jdring.AlarmWaiter.run(AlarmWaiter.java:124) at java.lang.Thread.run(Thread.java:662)

et

An exception occurred when calling method afterWrite() for DataController com.jalios.jcmsplugin.calendar.CalendarDataController@8a92ee0 java.lang.NoSuchMethodError: com.jalios.jcms.db.HibernateUtil.deleteQuery(Ljava/lang/Class;[Ljava/lang/String;[Ljava/lang/Object;)I at com.jalios.jcmsplugin.calendar.CalendarDataController.doCalendarPart(CalendarDataController.java:187) at com.jalios.jcmsplugin.calendar.CalendarDataController.afterWrite(CalendarDataController.java:174) at com.jalios.jcms.Data.controlWrite(Data.java:2840) at com.jalios.jcms.Data.controlAfterWrite(Data.java:2819) at com.jalios.jcms.Data.performDelete(Data.java:2796) at com.jalios.jcms.Publication.performDelete(Publication.java:5899) at com.jalios.jcms.handler.EditPublicationHandler.internalPerformDelete(EditPublicationHandler.java:690) at com.jalios.jcms.handler.EditPublicationHandler.performDelete(EditPublicationHandler.java:680) at com.jalios.jcms.handler.EditPublicationHandler.processAction(EditPublicationHandler.java:269) at com.jalios.jcms.handler.JcmsFormHandler.validate(JcmsFormHandler.java:256)

Benoit Chapel · on 1/17/14 at 11:36 AM
#3

Quelle version précise (avec la révision SVn ou le build number) de JCMS et du plugin calendrier avez-vous ?

Ludovic Smadja · on 1/17/14 at 11:47 AM
#4

JCMS 7.1.2 (build-20121012122143) Module Calendrier 2.6 Révision SVN: 62418

Benoit Chapel · on 1/17/14 at 11:57 AM
0 pts
Benoit Chapel · on 2/6/14 at 1:41 PM

Le comportement revient, je vais créer un ticket.

1) Des lignes sont créées dans la table 'p_calendar_attendee_data' avec des j_event_id à null.
Nous pensons qu'il y a un comportement qui produit ce bug mais nous n'avons pu l'identifier.

2) Ces lignes avec un j_event_id à null font que ces acceptations/refus apparaissent dans TOUS les événements fils des événements périodiques de TOUS le monde qui ont été créés après l'ajout de ces lignes en base !

Cependant, le problème demeure pour les événements périodiques posés avant la suppression de ces lignes en base.
On a vidé les caches de JCMS et le problème persiste !

 

 

 

0 pts