```
Une fois que vous avez trouvé quel schedule est le coupable, vous pouvez essayer de l’effacer via les API (éviter de le faire via la BD)
Si vous voulez vraiment garder cette schedule et corriger le problème, il va me falloir chacun des objet (incall, group, queue, outcall) relié à cette schedule. Si c’est ce que vous voulez, laissez moi le savoir et je vous fournirez les requêtes pour le faire
---
### Author:  [@ymolinet](https://wazo-platform.discourse.group/u/ymolinet)
#### Post date: [May 22, 2020, 7:45pm UTC](https://wazo-platform.discourse.group/t/resolu-schedule-en-erreur-de-18-03-vers-19-12/395/3 "2020-05-22T19:45:11Z")
Concernant le bug cité, j’applique les informations fournies ici [Upgrade 18.03 to 19.1x (pelican-stretch) - #11 by SIP-Online](https://wazo-platform.discourse.group/t/upgrade-18-03-to-19-1x-pelican-stretch/223/11) pour corriger le problème du mot de passe dans **wazo-auth-cli** qui n’est pas stocké dans le backup.
Voici mon script de restauration de mes bases de données:
> #!/bin/bash
>
> wazo-service stop
>
> tar xvfp /root/backups/wazo-data-backup-18.03.tgz -C /
> tar xvf /root/backups/wazo-db-backup-18.03.tgz -C /var/tmp
> cd /var/tmp/pg-backup
> sudo -u postgres psql -c ‘ALTER DATABASE asterisk RENAME TO asterisk\_previous’
> sudo -u postgres pg\_restore -C -d postgres asterisk-\*.dump
> sudo -u postgres pg\_dump -c -t dhcp -t netiface -t resolvconf asterisk\_previous | sudo -u postgres psql asterisk
> xivo-update-keys
> source /etc/profile.d/xivo\_uuid.sh
> systemctl set-environment XIVO\_UUID=$XIVO\_UUID
> systemctl daemon-reload
>
> dpkg --purge --force-all wazo-auth
> rm -r ~/.config/wazo-auth-cli
> sudo -u postgres psql -d asterisk -c “DELETE FROM public.auth\_user WHERE username = ‘wazo-auth-cli’;”
> apt-get install wazo-auth
>
> wazo-service start
Je viens de regarder la table schedule et tester les URL en passant les id.
Il y a trois entrées dans la table, et c’est seulement l’id 1 qui pose problème.
En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule\_path, ce qui m’a permis de voir que le schedule est utilisé par un utilisateur, un groupe, et une file d’attente.
Par rapport à ceux qui fonctionnent, je ne vois pas d’incohérence (caractère spéciaux par exemple)
Pour les schedules que je peux éditer, j’ai constaté que la référence vers les fichiers audio n’était pas maintenu dans wazo-ui alors qu’ils apparaissent dans la base. Je me demande si la table n’aurait pas loupé un upgrade.
Je préférais que l’on trouve la solution pour corriger au cas où cela se produise durant les updates de mes instances de production.
Merci,
Yannick
---
### Author:  [@fblackburn](https://wazo-platform.discourse.group/u/fblackburn)
#### Post date: [May 22, 2020, 8:35pm UTC](https://wazo-platform.discourse.group/t/resolu-schedule-en-erreur-de-18-03-vers-19-12/395/4 "2020-05-22T20:35:16Z")
> [@ymolinet](#):
>
> Concernant le bug cité, j’applique les informations fournies ici Upgrade 18.03 to 19.1x pour corriger le problème du mot de passe dans **wazo-auth-cli** qui n’est pas stocké dans le backup
Jamais testé cette procédure, seulement testé plusieurs fois le workaround décrit dans le ticket JIRA ci-dessus. Mais si ton upgrade a passé, ca devrait être bon
> [@ymolinet](#):
>
> En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule\_path, ce qui m’a permis de voir que le schedule est utilisé par un utilisateur, un groupe, et une file d’attente.
Est-ce que tu peux vérifier que le group et la queue qui est rattaché existe bel et bien? Le `pathid` est l’ID de la ressource. Si la ressource n’existe pas, tu peux supprimer l’entré dans la table `schedule_path`
> [@ymolinet](#):
>
> En voulant la supprimer, je vois qu’il y a une clé étrangère vers schedule\_path
Tu as essayer de la supprimer directement dans la DB ou passant par les API?
> [@ymolinet](#):
>
> Pour les schedules que je peux éditer, j’ai constaté que la référence vers les fichiers audio n’était pas maintenu dans wazo-ui alors qu’ils apparaissent dans la base. Je me demande si la table n’aurait pas loupé un upgrade.
Je ne vois pas de quel relation tu parles? Dans les destinations d’heure ouvré fermé?
---
### Author:  [@ymolinet](https://wazo-platform.discourse.group/u/ymolinet)
#### Post date: [May 22, 2020, 8:57pm UTC](https://wazo-platform.discourse.group/t/resolu-schedule-en-erreur-de-18-03-vers-19-12/395/5 "2020-05-22T20:57:09Z")
> [@fblackburn](#):
>
> Tu as essayer de la supprimer directement dans la DB ou passant par les API?
Depuis la base de données directement pour vérifier les implications de clé étrangère. L’utilisateur ne semble plus exister. J’ai supprimer l’entrée en base de données, et c’est tout bon de ce coté là.
> [@fblackburn](#):
>
> Je ne vois pas de quel relation tu parles? Dans les destinations d’heure ouvré fermé?
Je parle du champs fallback\_actionid qui contient le path local vers le fichier audio (fallback\_action = sound)
J’en profite pour avoir une information, le changement de version en 19.12 a aussi changer le nom de mes interfaces réseaux sur ma debian (de eno1 vers eth0). Est-ce normal ?
---
### Author:  [@fblackburn](https://wazo-platform.discourse.group/u/fblackburn)
#### Post date: [May 22, 2020, 9:21pm UTC](https://wazo-platform.discourse.group/t/resolu-schedule-en-erreur-de-18-03-vers-19-12/395/6 "2020-05-22T21:21:47Z")
> [@ymolinet](#):
>
> Depuis la base de données directement pour vérifier les implications de clé étrangère. L’utilisateur ne semble plus exister. J’ai supprimer l’entrée en base de données, et c’est tout bon de ce coté là.
Ouais supprimer la relation dans la table `schedule_path` n’est pas trop risqué pour supprimer les relations. Donc maintenant le list des schedules fonctionne?
> [@ymolinet](#):
>
> Je parle du champs fallback\_actionid qui contient le path local vers le fichier audio (fallback\_action = sound)
Dans ce cas, ça se peut que l’interface ai un petit soucis d’affichage. Pour vérifier, tu peux utiliser un API
```auto
curl -X GET --header 'Accept: application/json' --header 'X-Auth-Token: ' 'https://:9486/1.1/schedules?recurse=false'
```
Ou tu peux utiliser la documentation interactive sur le site:
> **[Console - Application - Wazo Platform](https://wazo-platform.org/documentation/console/application/)**
> [@ymolinet](#):
>
> J’en profite pour avoir une information, le changement de version en 19.12 a aussi changer le nom de mes interfaces réseaux sur ma debian (de eno1 vers eth0). Est-ce normal ?
Normal? Je sais pas, je crois avoir déjà observé ce comportement lors d’upgrade majeur. De mémoire j’ai pas souvenir qu’on ai fait de code et/ou travaux pour changer explicitement ça.
Sinon je te l’accorde que cette partie là est un peu dommage, car on a aucun moyen de changer cette valeur via des API.
La seule façon de faire est de le faire via la BD dans la table `netiface`
Pour l’interface dans la table `dhcp` elle peut etre configuré via l’api /dhcp
Après avoir modifié dans la DB il faut rouler les commandes:
```auto
xivo-create-config
xivo-update-config
```
**Attention** : c’est de mémoire, mais ça devrait te permettre d’avancer
---
### Author:  [@ymolinet](https://wazo-platform.discourse.group/u/ymolinet)
#### Post date: [May 22, 2020, 9:42pm UTC](https://wazo-platform.discourse.group/t/resolu-schedule-en-erreur-de-18-03-vers-19-12/395/7 "2020-05-22T21:42:01Z")
Je vais ajouter un contrôle de cohérence des schedules dans mon script de mise à jour de 18.03 vers 19.12, pour supprimer l’erreur avant la mise à jour. J’ai constaté aussi des erreurs dans les scripts de post-traitement. Avant de travailler dessus, je voulais m’assurer d’avoir résolu ce problème qui peut avoir des conséquences dans l’évolution du schéma de la base de données.
Je te remercie pour ton aide. J’ouvrirai un autre thread si j’ai encore des problèmes.
EDIT : Je confirme qu’en corrigeant la table dans Wazo 18.03, le process de mise à jour vers wazo 19.12 fonctionne parfaitement.