Mes réponses

[JérômeAdmin bbPress]

Bonjour,

Il faut cocher la case « fermeture » pour les jours qui ne doivent pas être décomptés.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

Oui, les anciens plannings de présence disparaissent et c’est normal.
Techniquement, les informations ne sont pas enregistrées à la même place. Vous devez donc refaire la saisie après activation du paramètre Planning Hebdo, mais ensuite ça ne bougera plus.

Une fois l’option Planning Hebdo activée, on ne revient jamais en arrière.
Les nouveaux plannings de présences remplacent les anciens partout dans l’application.

Planning Hebdo permet une gestion plus souple des heures de présence (anticipation de changement d’horaires dû à la modification d’un contrat ou au passage en horaires restreints par exemple).
Et il est nécessaire pour la gestion des congés car on a besoin de valeurs sûres, valables sur les périodes choisies pour le calcul des crédits.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

Vous devez activer le module « Planning_Hebdo » depuis le menu administration / configuration / Heures de présence.

Ensuite vous devrez vous octroyer les droits « gestion des heures de présences » (onglet « droits d’accès de votre fiche).

Puis, vous devrez saisir les heures de présence dans le menu administration / plannings de présence.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

J’ai apporté une correction ce matin. Pour en profiter, installez la version 19.10.04 disponible sur github.

Bonne réception,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

Les motifs d’absences utilisés ne peuvent pas être supprimés.

Si vous tenez vraiment à les supprimer, vous devez rechercher toutes les absences qui utilisent ces motifs, les modifier en choisissant un autre motif. Ensuite une corbeille apparaîtra face aux motifs inutilisés et vous pourrez les supprimer.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Nouveau correctif, plus complet, pour régler les problèmes d’encodage.

Suivre la procédure suivante :

NB : sauvegardez votre base de données avant toute opération.

• téléchargez le fichier 20191203_fix_encoding.php à cette adresse https://drive.google.com/open?id=1oOfgFwehULoxRnOBAqUF_4FLwnBuHmKJ
• placez-le dans le dossier setup/atomicupdate
• • si le dossier atomicupdate n’est pas présent dans setup, créez-le au préalable
  • si le dossier atomicupdate contient déjà des fichiers, supprimez-les
• ensuite, exécutez la commande suivante depuis le dossier setup
• php -f updatedatabase.php
• Vérifiez depuis l’interface web si les erreurs sont corrigées

Ce correctif sera intégré aux prochaines mises à jour.

Merci de faire un retour en commentant ce sujet.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Nouveau correctif, plus complet, pour régler les problèmes d’encodage.

Suivre la procédure suivante :

NB : sauvegardez votre base de données avant toute opération.

• téléchargez le fichier 20191203_fix_encoding.php à cette adresse https://drive.google.com/open?id=1oOfgFwehULoxRnOBAqUF_4FLwnBuHmKJ
• placez-le dans le dossier setup/atomicupdate
• • si le dossier atomicupdate n’est pas présent dans setup, créez-le au préalable
  • si le dossier atomicupdate contient déjà des fichiers, supprimez-les
• ensuite, exécutez la commande suivante depuis le dossier setup
• php -f updatedatabase.php
• Vérifiez depuis l’interface web si les erreurs sont corrigées

Ce correctif sera intégré aux prochaines mises à jour.

Merci de faire un retour en commentant ce sujet.

Cordialement,
Jérôme

• Cette réponse a été modifiée le il y a 6 mois par  Jérôme.

[JérômeAdmin bbPress]

L’erreur n’est pas gênante (mais merci de l’avoir notifiée, elle sera écartée).

L’erreur est liée au fait qu’on demande l’itération d’un tableau qui n’existe pas dans votre cas (visiblement, vous n’avez aucun modèle enregistré, vrai ?).

[JérômeAdmin bbPress]

Bonjour,

Pour régler les problèmes d’encodage, vous pouvez suivre la procédure suivante :
NB : sauvegardez votre base de données avant toute opération.

• téléchargez le paquet encoding.zip à cette adresse : https://drive.google.com/open?id=1gGioUUwz-3PZR1qbb2mx6HFgZklO-c88
• décompressez-le dans le dossier setup/atomicupdate
• • si le dossier atomicupdate n’est pas présent dans setup, créez-le au préalable
  • si le dossier atomicupdate contient déjà des fichiers, supprimez-les
• ensuite, exécutez la commande suivante depuis le dossier setup
• php -f updatedatabase.php
• Vérifiez depuis l’interface web si les erreurs sont corrigées

Ce correctif sera intégré aux prochaines mises à jour ainsi qu’un travail plus approfondi sur l’encodage de caractères.

Merci de faire un retour en commentant ce sujet.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

Il y a effectivement des différences au niveau des tables mais le problème d’encodage ne vient pas de là. Ceci sera uniformisé par la suite.

Pour régler les problèmes d’encodage, vous pouvez suivre la procédure suivante :
NB : sauvegardez votre base de données avant toute opération.

• téléchargez le paquet encoding.zip à cette adresse : https://drive.google.com/open?id=1gGioUUwz-3PZR1qbb2mx6HFgZklO-c88
• décompressez-le dans le dossier setup/atomicupdate
• • si le dossier atomicupdate n’est pas présent dans setup, créez-le au préalable
  • si le dossier atomicupdate contient déjà des fichiers, supprimez-les
• ensuite, exécutez la commande suivante depuis le dossier setup
• php -f updatedatabase.php
• Vérifiez depuis l’interface web si les erreurs sont corrigées

Ce correctif sera intégré aux prochaines mises à jour ainsi qu’un travail plus approfondi sur l’encodage de caractères.

Merci de faire un retour en commentant ce sujet.

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonsoir,

Je viens de faire quelques essais et j’ai pu reproduire l’erreur.
J’ai pu constater des erreurs d’encodage dans les zones commentaires de la configuration, après importation des données en provenance d’une ancienne installation.

Tout d’abord, ignorez ma réponse précédente, elle ne corrige pas le problème et en créé d’autres.

J’ai corrigé les erreurs d’encodage de la page configuration à l’aide de ce script :

< ?php
  
$version = 'update_db';

include_once(__DIR__.'/include/config.php');

$req = "select nom,commentaires from config;";

$db = new db();
$db->query($req);

$sql = array();

foreach ($db->result as $elem) {
        $name = $elem['nom'];
        $comment = $elem['commentaires'];

        $encoding = mb_detect_encoding($comment, 'UTF-8', true);

        if ($encoding === false) {

                echo $encoding;
                echo " : ";
                echo $comment;
                echo "\n";

                $comment = utf8_encode($comment);
                $sql[] = "update config set commentaires = '$comment' where nom='$name';";
        }
}

foreach ($sql as $elem) {
        $db = new db();
        $db->query($elem);
}

Script à déposer à la racine de l’installation Planning Biblio sous le nom update_db.php, et à exécuter comme suit :

php -f update_db.php

Encore une fois, traitez ceci avec prudence et sur une base de test uniquement.
Je le ferai valider et s’il passe les tests, il sera intégré à la prochaine mise à jour de Planning Biblio.

Explications :
Ce script récupère tous les commentaires dont l’encodage n’est pas de l’UTF-8 pur, puis il les convertit.

Le même schéma peut être reproduit pour les motifs d’absences par exemple.
Merci de lister en réponse tous les champs sur lesquels vous constatez des erreurs d’encodage.
Merci également de dire si ce script a corrigé vos erreurs, ou si il les a aggravées (-;

Cordialement,
Jérôme Combes

[JérômeAdmin bbPress]

Bonjour,

Oui,
Le bug (introduit en version 19.04.00) est corrigé à partir de la version 19.04.04

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Bonjour,

Avez-vous la possibilité de faire quelques essais avec vos anciennes données (sans les transformations indiquées ci-dessus) ?

Si oui,
Pouvez-vous SVP modifier le fichier init_entitymanager.php, se trouvant à la racine de l’installation Planning Biblio, et y ajouter les lignes suivantes :

    'charset'  => 'utf8',
    'driverOptions' => array(
        1002 => 'SET NAMES utf8'
    )

Ce qui donne :

$dbParams = array(
    'driver'   => 'pdo_mysql',
    'host'     => $config['dbhost'],
    'user'     => $config['dbuser'],
    'password' => $config['dbpass'],
    'dbname'   => $config['dbname'],
    'charset'  => 'utf8',
    'driverOptions' => array(
        1002 => 'SET NAMES utf8'
    )
);

Le but de cet essai et de voir si le problème ne vient pas de l’initialisation d’entitymanager, intégré à partir de la version 19.04.
Les données stockées dans la base sont (et doivent rester) en UTF-8. On ne devrait pas avoir à les modifier.

Jérôme

[JérômeAdmin bbPress]

Bonjour,

Oui, c’est le même problème.
Il faut installer au minimum la version 19.04.04

Cordialement,
Jérôme

[JérômeAdmin bbPress]

Pardon, il faut installer la 19.04.04

[Auteur]

Messages