OnlyOffice et perte occasionnelles de données

Salut,

J’ai 2 structures bénéficiaires avec des équipes à plein de temps de 30 à 50 personnes et avec des connexions internet instables qui font état de pertes occasionnelles des dernières données saisies en utilisant OnlyOffice+Nextcloud en collaboration spécifiquement sur la partie tableur.

Je me demande quels est votre retour d’expériences avec OnlyOffice à ce sujet ?

Mes autres bénéficiaires ne font pas états de ces problèmes, idem chez sans-nuage (que je co-gère avec d’autres membres d’ARN) où personne ne semble trop s’en plaindre…

Voilà je sais c’est flou, pas de log etc. En fait ce qui m’interresse c’est plutôt votre sentiment général vis à vis de la solution (mais si vous savez ce qui peut être le soucis, je suis intéressé).

NB: pour ces 2 structures, la conduite du changement pour les 2 équipes est un peu complexe (face à la solution de Google :confused: ).

Salut !

Pour notre propre usage, on a observé de telles pertes de données quelques fois il y a un an ou deux (on n’avait pas un usage intense), sans jamais avoir compris d’où ça avait pu venir. Pas eu de soucis depuis, et pas eu non plus ce genre de retour à l’échelle de Framaspace, même si ce n’est pas la solution de bureautique choisie par défaut.

On avait d’ailleurs mentionné le risque de perte de données dans la FAQ du service : Framaspace - Quelques questions pour découvrir Framaspace…

Quelques fois par an on a ce genre de retour :

Au secours, je viens de perdre mes 3h de boulot de ce matin sur ce doc
Le nuage me dit que la dernière version date d’il y a 3 jours. Est-ce que j’ai moyen de récupérer mon travail de ce matin ? Ou est-ce qu’il est juste méga déconseillé de bosser directement sur le nuage ? Genre il vaut mieux bosser en local et charger les docs une fois le travail fait ?
Ce qui m’étonne, c’est que jusqu’à présent le nuage m’indiquait quand le doc n’était pas « connecté » et cela m’empêchait d’ajouter des contenus. Il était comme bloqué jusqu’à ce que je recharge la page. La, tout est juste parti d’un coup.

Avec très souvent une piste qui ne mène à rien (dur de savoir quel type de connexion utilisée, si le doc était ouvert depuis longtemps, etc).

Je partage ton sentiment @ljf ça fait partie des soucis qui rendent la conduite du changement particulièrement complexe, avec une solution qu’on propose qui passe pour « pas crédible », surtout que notre capacité à débugger est limitée.

Il y a quelques années on avait identifié des soucis de notre côté, mais depuis on cherche sans trouver de trucs qui permettrait de l’expliquer.

Il est possible aussi que le souci provienne non pas de OnlyOffice mais du serveur WOPI de NextCloud.

Collabora/OnlyOffice travaillent avec un serveur WOPI, qui est une sorte d’API Microsoft qui permet à CO/OO de récupérer le fichier / l’enregistrer. Il y a basiquement 3 routes sur ce serveur WOPI : récupérer les infos du fichier, récupérer le contenu du fichier, écraser le contenu du fichier.

Il est donc possible, même si normalement le serveur CO/OO est sensé gérer les conflits entre versions/utilisateurs, qu’une version en écrase une autre. Exemple : un onglet resté « bloqué », l’utilisateur en ouvre un autre fait ses modifs, le premier onglet se débloque et écrase les modifs.

Je ne connais pas les mécanismes à l’œuvre dans CO/OO pour prévenir ça, mais tu dois pouvoir loguer ce qui se passe en loggant les URLs de l’API WOPI de NextCloud. Je ne sais pas si NextCloud propose du log spécifique à ce niveau, mais au niveau de ton serveur web tu peux logger les URLs qui contiennent la regexp /wopi[^/]*/files/[^/]+/contents pour des requêtes de type POST. La partie entre files/ et /contents te donnera l’ID du fichier, tu pourra donc voir qu’est-ce qui s’est passé au niveau des enregistrements du contenu du fichier.

Pour info la doc des endpoints WOPI est ici : WOPI REST endpoints | Microsoft Learn

Normalement NextCloud possède une stratégie de versionnement de fichiers, donc si ça n’a pas été désactivé, la personne peut aller récupérer sa version (si CO/OO a bien enregistré le fichier à un moment, et qu’il a été écrasé) dans l’historique des versions :slight_smile:

Pour revenir au point initial, il est possible que l’API WOPI de NextCloud autorise qu’une version plus ancienne écrase une version plus récente.

3 Likes

Addendum: je viens de relire les docs et il semble que NextCloud n’implémente pas les mécanismes prévus par WOPI, OnlyOffice ou Collabora pour empêcher l’écrasement d’un fichier (oups, Paheko non plus, edit : c’est bon).

Mais depuis NextCloud Hub 7 il semble que NC implémente sa propre logique de verrouillage pour qu’un document en cours d’édition dans OO/CO ne puisse pas être écrasé, par exemple par une synchro depuis un client desktop/mobile : https://www.youtube.com/watch?v=YohQfObl3I8&t=595s

Je n’avais pas pensé à ce cas de figure, qui pourrait expliquer la disparition des modifications :

  1. L’édition dans CO/OO modifie le document
  2. Un client desktop/mobile NC ne détecte pas que le document a été modifié, et écrase la nouvelle version avec une ancienne version, sans les modifications apportées dans CO/OO

Donc 2 scénarios possibles à priori avant NC 28 : conflit WOPI, et conflit entre éditeur WOPI et client local.

3 Likes

Merci pour toutes ces pistes, ça donne des outils pour creuser lors du prochain souci !

Il faut qu’on partage plus en détails, mais on a plein de soucis aussi :confused:

Et on a déjà passé des jours de travail dessus…

La perte des derniers edits, on a ça aussi je crois, en tout cas, certaines personnes nous le remontent, quand tu ouvres, le doc est blanc (on a eu une salve aujourd’hui, du a l’instabilité du cluster minio) (Hugo a regardé et pas de check de code http ici , donc on pense que ton backend dit 500, oo dit ok, pas de soucis, je vais en créer un nouveau, et quand le backend réponds, je le sauvegarde \o/), la cette aprem, j’avais encore un nouveau truc ou le docker-compose de oo démarre pas bien…

Il parait qu’il y a des blobs opensource dans le projet… (deso, j’ai pas la source). Mais dans tous les cas, le code est écrit et built en Russie de ce que je comprends.

On pense migrer sur collabora quand on aura le temps.

1 Like

Tiens on a jamais eu ce souci, sauf quand on a eu des indisponibilités de OO derrière un proxy qui répond ok (ynh).

Oué OnlyOffice… c’est pas la joie ces derniers temps.

D’autres histoires sympathiques:

Il y a un monde où des personnes sont sur le même document mais pas sur une même version… (A voir si c’est toujours le cas)

Et pas de pertes de données mais celle là rend la collaboration sur un document quasi impossible:

Deux issues qui commencent à dater…

Pour le bug du document vide c’est quand le cluster de stockage devient indisponible et renvoie une erreur, OnlyOffice considère que le document n’existe pas, en créé un nouveau et donc écrase le document d’origine.

Ça fait-il plusieurs que j’ai migré presque l’ensemble de mes clients sur Collabora en lieu et place d’onlyoffice.
Il en sont tous globalement satisfait, en terme de rapidité , exploitabilité et stabilité