8. Migrations - Mises à jour

La migration consiste à passer d’une version à une autre. Durant cette phase, les données actuelles sont adaptées pour fonctionner dans la nouvelle version. Suivant la taille de la base de données, cette opération peut durer entre 1 heure et plusieurs jours.

8.1. Version 2.3 vers 3.0

Les changements apportés par la nouvelle versions sont précisés dans la section Journal des modifications.

Afin de préparer la migration et d’adapter les données correctement, il est nécessaire de nous communiquer à l’avance certains choix de fonctionnalités…

Des vidéos explicatives (extraites d’une présentation effectuée sur le sujet) détaillent les points repris ci-dessous.

📽️ Cette vidéo d'introduction donne des informations générales sur la migration vers la 3.0.

Email entrant:

📽️ Cette vidéo sur la fonctionnalité "email entrant" explique les points repris ci-dessous.

  • Nous filtrons les emails transférés manuellement vers l’application afin que n’importe qui ne puisse pas ajouter du contenu dans l’outil. Pour ce faire, nous rejetons tout email dont l’adresse email ne correspond pas à un modèle prédéfini (par exemple « *@macommune.be » représente toutes les adresses de « macommune.be »). => Veuillez nous indiquer avant migration qui pourra transférer vers iA.docs…

  • L’option de l’étape jusqu’à laquelle le mail pourra avancer est configurable dans la section Email entrant. => Veuillez nous indiquer l’option qui vous convient le mieux

  • L’email de l’agent qui transfère est recherché dans les fonctions occupées internes. Voir l’explication détaillée dans Transfert manuel d’un email par un agent. L’orientation correcte de l’email dépend donc de la « bonne » configuration de cette partie (Gestion du personnel interne).

Email sortant:

📽️ Cette vidéo sur la fonctionnalité "email sortant" explique les points repris ci-dessous.

  • Pour ne pas utiliser la fonctionnalité d’email sortant, il faut désactiver le type « email » dans la configuration des modes d’envoi (Courrier sortant). => Veuillez nous indiquer si l’aspect Email sortant vous intéresse

  • Afin que nous réalisions le modèle de signature de l’email, => Nous envoyer à l’avance le modèle actuel que vous utilisez.

  • Les modèles de contenu d’email peuvent être rédigés via l’onglet « Modèles », comme expliqué dans la section Gestion des modèles, partie « Email sortant ».

  • Le nouveau champ « forme d’envoi » peut éventuellement faire double emploi avec le champ « Type de courrier » (suivant son contenu). Durant la migration, nous remplaçons les types de courrier s’ils correspondent à des formes d’envoi et nous désactivons ce champ (sauf s’il contient des types complémentaires).

  • Nous devons utiliser le serveur de mail de votre administration pour envoyer les emails sortants. => Veuillez nous envoyer avant la migration les accès smtp comme indiqué dans la section Configuration du serveur de mail.

  • La forme d’envoi peut être affichée dans les modèles de documents bureautiques si nécessaire.

  • Pour information, l’état optionnel « Pour impression » est remplacé par l’état « validé » intégré par défaut dans le workflow.

Classification (gestion de dossiers / arbre de classement):

📽️ Cette vidéo sur la fonctionnalité "gestion de dossiers" explique les points repris ci-dessous.

  • La gestion de dossiers et de classement (Gestion de dossiers) peut être désactivée. => Veuillez nous indiquer avant la migration si cet aspect vous intéresse

  • L’importation éventuelle (après migration) d’arbres de classement ou de dossiers doit être supervisée par nos soins dans un premier temps. => Nous envoyer les fichiers de classement éventuels

Divers:

📽️ Cette vidéo sur des points divers détaille les points repris ci-dessous.

  • Si le nom de domaine actuel de l’outil est de la forme « …-ged@imio-app.be », il sera migré vers « …-docs@imio-app.be ». Si vous avez rajouté le nom de domaine dans votre firewall interne, il faudra rajouter également le nouveau.

  • Si vous n’utilisez pas encore la partie « courrier sortant » dans l’application, le passage à la version 3.0 est une bonne opportunité pour le faire. Veuillez nous le signaler également.

  • Vérification des groupes N+1. Au début de l’outil, le niveau N+1 était obligatoire. Ce n’est plus le cas depuis la version 2.3. Il est donc possible d’enlever totalement le niveau N+1 ou de le gérer service par service (si un groupe N+1 contient des utilisateurs, il y aura validation dans ce service, sinon cette étape sera passée automatiquement). Revenez vers nous pour modifier éventuellement la configuration.