Incompatibilité de fullcalendar 3.1 avec le plugin scheduler

[Francois (François Genestin)]

Oui le search est fait par le front, comme le montre l’exemple de code précédent.

Recherche une valeur fixe :
{ myDate: '2020-03-17' }

Null :
{ myDate: 'is not null' }
{ myDate: 'is null' }

Date minimum (depuis le)
{ dmin__myDate: '2020-03-17' }

Date maximum (jusqu’au)
{ dmax__myDate: '2020-03-20' }

ou période en abrégé:
{ myDate: '2020-03-17;2020-03-20' }
équivalent à :
{ dmin__myDate: '2020-03-17', dmax__myDate: '2020-03-20' }

Rien de spécifique au fullcalendar, c’est la syntaxe de la couche Ajax des objets.

[guithel (Guillaume Thelohan CRB)]

Bonjour,

Le paramètre FULLCALENDAR_VERSION et les librairies front-end “non standard simplicité” (les librairies js de fullcalendar que nous utilisons et qui ne sont pas incluses dans la plateforme) disparaissent au moment des sim upgrade. Le paramètre est renseigné dans un de nos modules. Les fichiers suppirmés sont dans /home/gdr/tomcat/webapps/gdr/scripts/fullcalendar/v4/

@Francois

Dans ce cas il faut veiller à ce que le module soit ré-importé après chaque upgrade du template.
Sinon le paramètre sera écrasé. Je pensais qu’un patch post upgrade avait été mis en place pour changer d’autres choses sur vos environnements.

Si c’est trop compliqué, on va retirer le paramètre des patch V4 en attendant la V5.

En V5, on va ajouter un champ sur les paramètres systèmes pour pouvoir surcharger la valeur éditeur.
Elle sera prise en priorité si elle est renseignée, ne sera pas écrasée par nos livraison. Ca permettra de gérer ce genre de cas plus simplement.

Si je comprends bien votre post, pour le parmètre système, vous nous conseillez d’ajouter ces valeurs dans un patch qui sera appelé via le hook post-upgrade (qui chez nous contient actuellement 2 traitements, config WAF et config jdbc) ? A moins que vous ne la supprimiez pour ne pas qu’elle soit réécrasée ?

Pour les fichiers, comment les conserver lors de l’upgrade du tomcat ? Pour info, ils sont bien copiés dans tomcat.upgrade.bak, mais pas dans le répertoire tomcat upgradé.

Merci,

Guillaume

Release :

[Francois (François Genestin)]

FULLCALENDAR_LIBS a été retiré des patch V4, il est bien utilisé si présent / ajouté manuellement.
Par contre FULLCALENDAR_VERSION est toujours forcé à 3 par défaut.
Il sera retiré au prochain release car dans le moteur c’est bien 3 par défaut s’il est absent (mais on peut forcer un patch xml via post-upgrade pour le mettre à 4).

Par contre pour vos JS additionnels à la plateforme écrasés à chaque upgrade, il faut les avoir toujours disponible en dehors de tomcat (genre /usr/local/share/fullcalendar/v4) :

• soit spécifier des chemins absolus dans le FULLCALENDAR_LIBS : le user tomcat devra avoir un droit de lecture sur le répertoire des libs
• ou soit les recopier vers tomcat avec les bons droits après chaque upgrade : cp -rf dans le post-upgrade

[david (David AZOULAY)]

Le SIM a un desscripts “hooks” que Benjamin connait bien et qui permettent notamment d’ajouter des choses (JARs, JS, etc.) au template d’instance standard lors des creations et des mises à jour

[guithel (Guillaume Thelohan CRB)]

Bonjour,

Merci. Je vais faire ceci :

• Mettre les libs spécifiques dans /var/crb/libs/fullcalendar/v4 (j’utilise déjà /var/crb/dbdoc pour stocker des documents en filesystem).
• Dans le hook “post-ugrade” :
  • passer FULLCALENDAR_VERSION à 4
  • si /var/crb/libs/fullcalendar/v4 existe sur le sim, passer FULLCALENDAR_LIBS à /var/crb/libs/fullcalendar/v4

Je voudrais spécifier ces paramètre dans un fichier “xml simplicité”. Comment appeler un tel fichier et l’exécuter en bash ?

[david (David AZOULAY)]

via un appel curl de type xmlimport cf. https://docs.simplicite.io/documentation/02-integration/io-commandline.md#imports