Gabarit d'édition d'un évènement de calendrier customisé (Evénement de Calendrier - Réservation de ressources - Plugin Calendrier)

Jean-Marc Brun · le 19/04/16 à 11:38

Bonjour,

Est-il possible, sans créer un nouveau gabarit d'édition, d'utiliser le gabarit d'édition du front office des événements de calendrier pour un événement de calendrier étendu ?

Je suppose que la réponse doit être non.

Pour préciser ma demande :

Nous avons étendu le type de contenu "Evénement de Calendrier" en créent un nouveau type qui en hérite et possédant des champs supplémentaires basiques. Cependant lors de l'ajout de d'un événement customisé depuis le calendrier en front office le gabarit d'édition utilisé est non pas celui de l'Evénement de calendrier par défaut qui est à base de pop up  :

CapturePopUpCalendarEvent

, mais celui utilisé pour une édition depuis le back office. 

Or ce gabarit assez basique ne donne pas accès à certaines fonctionnalités du gabarit front office comme par exemple, la plannification de ressources : https://community.jalios.com/upload/docs/image/png/2014-10/ressource.png

 

J'ai essayé de spécifier le handler comme indiqué sur la page du module Calendrier :

https://community.jalios.com/jcms/jc_129309/fr/module-calendrier-4-3?cid=jc1_199010

en ajoutant l'attribut suivant dans la déclaration du type dans le fichier xml

formhandler="com.jalios.jcmsplugin.calendar.EditCalendarEventHandler"

Sans plus de résultat.

Je n'ai d'ailleurs pas bien compris, ni vu, ce que l'ajout de cet attribut changeait au résultat. 

 

J'ai même également essayé l'attibut suivant :

 

customformhandler="com.jalios.jcmsplugin.calendar.EditCalendarEventHandler"

mais j'arrive à une erreur. 

 

Merci par avance

Cordialement,

JM Brun

 

 

6 pts
Jean-Marc Brun · le 19/04/16 à 15:12

Pour information :

Après investigation j'ai finalement découvert que les gabarits d'éditions avec l'usage Modal (editModal) étaient en réalité bien générés automatiquement et tout simplement pas utilisés car pas déclarés.

Il sufffit donc de bien les déclarer dans le plugin.xml (en faisant attention à l'arborescence pour bien aller chercher le gabarit généré côté projet) ou a défaut dans le fichier customType-templates.xml associé au type, afin qu'il soit utilisé en front office par les boutons d'ajouts du calendrier.

Reste un problème, le fait que par défaut le type utilisé lors d'un double click sur le calendrier est l'évènement de calendrier classique. Je ne sais pas si l'on peut imposer le nouveau type par defaut.

#1

Finalement, les gabarits par défaut sont correctement générés mais à reprendre car ils n'utilisent pas la capacité de planning des ressources, et donc le problème reste le même.

Jean-Marc Brun · le 19/04/16 à 16:47
1 pt
Pierre MORIN · le 18/11/16 à 17:43

Il semble que la surcharge d'un évènement de calendrier ne soit pas possible en natif.

En effet, le gabarit d'édition en popin ne s'applique pas sur le type hérité.

De plus, plus grave, la gestion des ressources d'évènements est cassée ! Par exemple, si on crée un événement du type hérité et qu'on lui assigne une ressource d'évènement, celle-ci n'apparaitra pas dans la liste des ressources déjà réservées, et les tests associés ne seront pas joués (une même ressource pourra donc être utilisé par plusieurs évènement en même temps).

2 pts