Mise à jour majeure 20.10

La procédure ci-dessous décrit les étapes de migration de la version 20.03 à la version 20.10.

Attention

Si vous êtes sur une version plus ancienne que la 20.03, il faut faire toutes les migrations version par version jusque la 20.03. (il ne faut donc pas aller sur la branche 20.10 directement)
Voir la documentation des migrations antérieures si tel est le cas.

Nouveaux pré-requis

Version minimum requise de PHP : 7.3
Navigateurs internet compatibles : Firefox ESR >= 68 ou Firefox >= 76 ou Chrome >= 84
Version minimum requise de Microsoft Office : 2013

  • Installation de p7zip-full (Utilisé pour décompresser les archives 7z lors de l'export SEDA) :
    apt-get install p7zip-full
    

Mise à jour des sources de l'application

git fetch
git checkout tags/$(git tag --sort=committerdate | grep -E '20.10.+([0-9])$' | tail -1) -b $(git tag --sort=committerdate | grep -E '20.10.+([0-9])$' | tail -1)

Script SQL

Cette action est à exécuter sur toutes vos instances (customs).

  • Passer le script 2010.sql qui se trouve dans migration/20.10

Script BASH

Cette partie doit être faite uniquement si le script précédent s'est terminé sans erreurs.
Cette action n'est à exécuter qu'une seule fois, le script migrera tous les customs présents dans le dossier custom.

  • Lancer le script migrate.sh qui se trouve dans migration/20.10

BREAKING CHANGES

Fichier de configuration

  • Le fichier de configuration de l'application apps/maarch_entreprise/xml/config.xml devient un fichier json apps/maarch_entreprise/xml/config.json

Configuration des custom

  • Le fichier de configuration des custom custom/custom.xml devient un fichier json custom/custom.json
  • Un nouveau privilège permet maintenant de pouvoir créer une nouvelle instance (nouveau custom). Sans ce privilège, il n'est plus possible de créer une nouvelle instance.
    Ce nouveau droit fait apparaître le menu "Créer une nouvelle instance" chez la personne concerné. Pour plus d'informations, voir la documentation d'exploitation

Personnalisation

  • Les images de fond d'écran de la page de connexion, et le logo de l'application sont maintenant dans le dossier custom/{custom_id}/img/. Il est aussi possible de les modifier via l'application. Voir la documentation.

Prérequis

  • Il n'est plus obligatoire d'activer le paramètre short_open_tags dans la configuration PHP
  • Il maintenant nécessaire de retirer simplement les notices pour le paramètre error_reporting dans la configuration PHP : E_ALL & ~E_NOTICE

Mode "admin"

  • Un mode "admin" existe maintenant dans le paramètrage des utilisateurs. Il confère tous les pouvoirs au sein de l'application (les mêmes que l'utilisateur superadmin auparavant).
  • Seul un utilisateur ayant ce pouvoir peut le donner ou le retirer à un autre utilisateur.
  • Il existe 2 configurations pour ce mode "admin".
    • La configuration "visible" qui rend cet utilisateur visible dans l'application au même titre qu'un utilisateur lambda.
    • La configuration "invisible" qui le cache partout hormis dans l'administration des utilisateurs.
  • Superadmin devient donc maintenant un utilisateur "classique" avec ce mode "admin invisible" activé.
  • Lorsqu'une méthode d'authentification est activée, l'utilisateur superadmin ne contourne plus l'authentification. Il faut donc, soit créer superadmin dans votre portail d'authentification, soit activer le mode "Admin" pour un autre utilisateur réel de Maarch Courrier.
  • N'oubliez pas : "Un grand pouvoir implique de grandes responsabilités".

Statistique

  • Le module statistique (reports) a été supprimé de l'application. Etude en cours pour trouver un connecteur permettant de faire des requêtes sur la base de données

Notifications

  • Les scripts de notification utilisent maintenant le fichier config.json général de l'application
  • Tous les batchs de notification ont été regénérés dans le dossier bin/notification/scripts/
    Dans la crontab du serveur, il faut donc modifier les chemins vers les nouveaux scripts de notifications.
  • Les logs des scripts sont maintenant visible dans le fichier technique.log. L'emplacement dépend de la configuration faite dans log4php.xml.
    Si vous aviez un script de rotation de logs, il faut supprimer l'action qui était faite pour nettoyer le dossier modules/notifications/batch/logs
  • Pour que l'envoi des notifications fonctionne (uniquement quand un mot de passe est renseigné dans l'administration du serveur de courriel), il est important de renseigner la variable MAARCH_ENCRYPT_KEY dans le fichier /etc/environment (debian) avec la même valeur que dans le vhost.
    MAARCH_ENCRYPT_KEY="Security Key Maarch Courrier 2008"
    
  • Il faut redémarrer le serveur pour que les variables du fichier soient prises en compte.

Parapheur externe

  • Le script permettant de récupérer les documents envoyés au parapheur externe a été regénéré dans le dossier bin/signatureBook/scripts/
    Si le script était lancé dans la crontab du serveur, il faut modifier le chemin vers le nouveau script bin/signatureBook/scripts/retrieveMailFromExternalSignatoryBook.sh.
  • Les logs du script sont maintenant visible dans le fichier technique.log. L'emplacement dépend de la configuration faite dans log4php.xml.
    Si vous aviez un script de rotation de logs, il faut supprimer l'action qui était faite pour nettoyer le dossier modules/visa/batch/logs

Parapheur IxBus

  • Dans le cas où vous utilisez le parapheur IxBus, le paramétrage technique doit être modifié. Voir la documentation ici.

Export Seda

  • Le script permettant de récupérer les réponses du SAE a été regénéré dans le dossier bin/exportSeda/scripts/
    Si le script était lancé dans la crontab du serveur, il faut modifier le chemin vers le nouveau script bin/exportSeda/scripts/checkAllReplies.sh.
  • Le script permettant de purgé les courriers envoyé au SAE a été regénéré dans le dossier bin/exportSeda/scripts/
    Si le script était lancé dans la crontab du serveur, il faut modifier le chemin vers le nouveau script bin/exportSeda/scripts/purge.sh.
  • La page d'action système "Purger le courrier après l'archivage" a été supprimée. Il faut mettre en place le batch bin/exportSeda/scripts/purge.sh pour que les courriers soient supprimés automatiquement.
  • Les courriers doivent obligatoirement avoir une durée d'utilité courante dépassée pour que le courrier soit archivé (Paramétrable dans les types de courrier).
  • Toutes les pièces jointes d'accusé de réception liés à l'archivage ont maintenant le type "Accusé de réception (Archivage)" (attachment_type = acknowledgement_record_management)
  • Toutes les pièces jointes de réponse au transfert liés à l'archivage ont maintenant le type "Réponse au transfert (Archivage)" (attachment_type = reply_record_management)

Connexions

  • La connexion "Shibboleth" est maintenant associée à la connexion SSO, il faut donc modifier le fichier apps/maarch_entreprise/xml/login_method.xml pour activer la méthode SSO. Puis définir l'en-tête dans l'administration des connexions

Installeur

  • L'installeur a été complétement revu, il ne crée plus automatiquement les notifications et ne propose plus la configuration du serveur email directement.
  • A la fin de l'installation, un didacticiel sera proposé en se connectant avec superadmin, il permettra de configurer entre autres les notifications ou le serveur email.

Bannettes

  • Dans l'onglet Liste de résulats de l'administration des bannettes, le paramètre Pouvoir modifier le document principal intégré au parapheur a été modifié en Pouvoir modifier modifier les documents intégrés au parapheur. Ainsi, si ce paramètre est activé, l'utilisateur pourra modifier tous les documents visible dans son parapheur. A cet endroit, le privilège Modifier ou supprimer des pièces jointes n'est plus pris en compte

Sécurité

  • La déconnexion après un temps d'inactivité a été supprimé. Un nouveau système de jeton de connexion a été mis en place. Ce jeton se réinitialise automatiquement toutes les 30 minutes lorsque l'utilisateur est connecté.
    Aussi, l'utilisateur devra se reconnecter tous les X jours. Ce temps de reconnexion forcé est paramétrable dans la balise cookieTime du config.json. Par défaut, la valeur est mise à 7 jours.

Recherche

  • La recherche rapide ne recherche plus dans les annotations du courrier
  • Il n'est plus possible de rechercher sur une bannette en particulier
  • Les champs personnalisés présents dans les recherches sauvegardées personelles ne sont pas repris lors de la migration

Langue

  • Toutes les variables de langues visible dans l'interface sont maintenant disponible dans le fichier src/lang/. Voir la documentation pour les personnaliser.
  • Les anciens fichiers de langue apps/maarch_entreprise/lang/fr.php et modules/*/lang/fr.php ont été supprimés.

Synchronisation Ldap

  • La synchronisation LDAP à été revu et le paramétrage a un peu évolué. Il faut se référer à la documentation LDAP pour remettre en place la synchronisation.
  • La balise "group" dans les filtres n'est plus utilisée

Modifications des colonnes impactantes dans la base de données

Les colonnes considérées impactantes listées ci-après ont été supprimées de la base de données.

Colonne Table Informations
loginmode users transféré dans la colonne "mode". Toutes les valeurs 'restMode' présentes dans la colonne seront affiliées au mode 'rest'

Les colonnes considérées impactantes listées ci-après ont été modifiées de la base de données.

Colonne Table Informations
typist res_attachments Correspond maintenant à l'identifiant technique de l'utilisateur users.id, et non plus à son login users.user_id
dest_user res_letterbox Correspond maintenant à l'identifiant technique de l'utilisateur users.id, et non plus à son login users.user_id
item_id listinstance Correspond maintenant à l'identifiant technique de l'utilisateur users.id (ou de l'entité), et non plus à son login users.user_id

Toutes les tables de la base de données utilisent maintenant l'identifiant technique de l'utilisateur, et non plus le login.

L'ensemble des modifications sql sont visibles dans les scripts sql qui se situent ici : migration/20.10/
Pensez également à modifier les outils externes exploitants ces colonnes, comme Maarch AutoImport par exemple.

Webservices

  • Le paramètre "loginmode" dans les routes POST /rest/users et PUT /rest/users/{id} doit être remplacé par le paramètre "mode"
  • Le paramètre "typist" dans les routes POST /rest/attachments et PUT /rest/attachments/{id} Correspond maintenant à l'identifiant technique de l'utilisateur users.id, et non plus à son login users.user_id
  • La route POST /rest/resourcesList/users/{userId}/groups/{groupId}/baskets/{basketId}/summarySheets est remplacée par la route POST /rest/resourcesList/summarySheets. Les paramètres dans le body restent les même
  • La route POST /rest/resourcesList/users/{userId}/groups/{groupId}/baskets/{basketId}/exports est remplacée par la route POST /rest/resourcesList/exports. Les paramètres dans le body restent les même

ScanToMaarch

La version scanToMaarch 1.0 n'est pas compatible avec MaarchCourrier 20.10. Il faut télécharger la nouvelle version scanToMaarch 1.1 disponible ici

results matching ""

    No results matching ""