Adihshats monde, bonjour à tous.
Ceci est un message d'informations qui peut sauver des données, et aussi un coup de gueule.
Je tiens ma comptabilité personnelle sur une feuille de calcul Opencalc. Et j'utilise le tri, bien entendu. Ce qui a fonctionné correctement, jusqu'à la version 4.3.
M'apercevant que le tri disfonctionne(*) avec cette version, je cherche un peu, et je trouve le rapport de bug 81633.
My english is not good, mais, si j'ai bien compris, un nouveau comportement du tri (mise à jour automatique des références relatives) a été implanté.
Fort bien, mais tous ceux (dont moi) qui utilisent le fait que lors du tri les références relatives ne sont PAS mises à jour voient leurs documents possiblement corrompus.
Le contournement, retourner à la version 4.1.
Je doute fortement que ce genre de modifications plaise aux utilisateurs lambda.
(*) Oui, "disfonctionne" avec un "i", car pour moi un tri qui fonctionne mal ne fonctionne pas du tout !
# c'est configurable dans la 4.4 :D
Posté par fearan . Évalué à 9.
donc début 2015 si j'ai bien suivi le fil (ou dans la daily build)
C'est tout le problème de corriger un bug qui est utilisé par les utilisateurs (une grosse partie des soft windows qui ne fonctionnent plus sont dus à ce genre de blague)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: c'est configurable dans la 4.4 :D
Posté par patrick_g (site web personnel) . Évalué à 10.
Référence obligatoire : http://xkcd.com/1172/
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lgmdmdlsr . Évalué à 5.
C'est-à-dire que l'ancien comportement n'est pas perçu comme un bug.
Quand la cellule B2 contient la formule "=A2+B1", implicitement on pense que le tableur ajoute le contenu de la cellule du dessus à celui de celle de gauche. Et si la cellule change de place par un tri, on s'attend à ce qu'elle continue d'additionner le contenu de la cellule du dessus à celui de celle de gauche …
Quand je veux pointer vers une cellule, même si elle est déplacée, j'ai appris à utiliser les références absolues ($A$2).
Donc je ne saisis pas l'intérêt de ce changement de comportement.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par Matthieu Moy (site web personnel) . Évalué à 8.
À peu près toutes les opérations ajustent les références. Par exemple, si tu supprimes une ligne et que ça décale des cases, les références sont ajustées (et les références aux cellules effacées deviennent invalides). Si tu coupe-colle pour déplacer des cellules, idem. Ça parait assez logique de faire pareil pour un tri.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lolop (site web personnel) . Évalué à 2.
Reste plus à lgmdmdlsr qu'à utiliser des références absolues là où elles doivent l'être (ou à utiliser un logiciel de compta perso :-)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par fmaz fmaz . Évalué à 1.
J'avoue que je ne comprends pas ce qu'ajuster les références veut dire.
Pour moi, il y a les références absolues et les références relatives.
Si la case a1 contient la formule b2+1, j'interprète ça comme « prends le contenu de la case à droite d'une case et en bas d'une case et ajoute 1 ». Donc pour moi, si on insère une ligne avant la ligne A, la case devient B1 et elle doit contenir c2+1.
C'est un peu comme la différence entre « cp /tmp/toto.txt . » et « cp ../toto.txt . »
Mais bon, je n'utilise des tableurs qu'à un niveau très basique.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ce que tu décris est un comportement possible, mais pas celui qu'implémente LibreOffice dans la plupart des cas. Si tu écris =B2+1 dans une cellule, et que plus tard tu déplaces des cellules (par exemple, tu coupe B2, et tu colles la cellule en C3) le « B2 » de la formule est ré-écrit (dans l'exemple, il devient C3).
Le fait que la référence soit absolue ou non ne change rien, je viens de refaire l'essai, $B$2 est réécrit de la même manière que B2.
Si tu veux une analogie avec le filesystem, ça serait plutôt inode contre nom de fichier. Le fait qu'on déplace le fichier ne change pas les références aux numéros d'inode.
C'est souvent très pratique (quand on déplace des choses pour la mise en forme, les références s'adaptent toutes seules), et parfois très pénible comme le cas de l'auteur du journal.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par GG (site web personnel) . Évalué à 2. Dernière modification le 01 novembre 2014 à 21:33.
Tu m'as fait peur.
J'utilise la version LibreOffice 4.3.2.2.0 430m0(Build:2)
Si je fais un copier/coller d'une cellule avec des références absolues, ces références absolues ne sont pas changées (j'ai testé avec un $B2).
Heureusement que ça fonctionne ainsi.
Concernant ce que dit l'auteur du journal je n'ai pas encore compris.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lgmdmdlsr . Évalué à 1.
Pour comprendre le problème, j'ai rédigé un exemple .
[^] # Re: c'est configurable dans la 4.4 :D
Posté par GG (site web personnel) . Évalué à 2.
Dans ton exemple, je ne comprends pas pourquoi tu tries la colonne C.
Ta colonne C contient les formules qui consistent à additionner la cellule en colonne-1 avec celle au dessus.
Dans la doc, je vois bien un semblant de solution avec des formulaires pour prendre la référence de la cellule actuelle, et de prendre celle à la colonne-1 additionnée à la celle de la ligne-1. J'ai pas trop cherché à jouer avec les fonction Adresse(), Indirect(), Ligne() et Colonne().
J'utilise Dolibarr qui fait ce genre de chose très bien tout seul, et plein d'autres trucs.
Je suis sur que d'autres logiciels de gestion de trésorerie le font aussi : Grisbi etc.
Bonne journée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lgmdmdlsr . Évalué à 0.
Peut-être n'était-ce pas suffisamment assez clair, en effet. La colonne A représente en fait la date de l'opération. Et comme on peut être amené à entrer ultérieurement des opérations antérieures, le tri se justifie.
La colonne C (solde après opération) doit être triée aussi, pour correspondre à la date et au montant de l'opération …
(document exemple modifié pour clarifier cette histoire de date)
[^] # Re: c'est configurable dans la 4.4 :D
Posté par GG (site web personnel) . Évalué à 3.
Bonsoir,
si tu compares les formules de la colonne C tel que tu le souhaites, tu vois bien que la colonne C ne doit pas être triée.
J'insiste, et je t'invite à faire un test en ne triant que les colonnes A et B selon les valeurs de A. Oh, tiens, tout rentre dans l'ordre.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lgmdmdlsr . Évalué à 0.
Mais non, tout ne rentre pas dans l'ordre. Car si le tri est fait uniquement sur les colonnes A et B, les indications des colonnes B et C ne correspondent plus.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par GG (site web personnel) . Évalué à 3.
ça va devenir à rallonge….
Il faut sélectionner les colonnes A et B.
et effectuer le tri selon la colonne A (c'est la première colonne sélectionnée par défaut).
Il ne faut pas toucher à la colonne C.
Ainsi, ça fonctionne très bien.
Si la colonne C fait partie de la sélection pour le tri, c'est normal que le contenu des cellules de la colonne C soient déplacés.
Quand une cellule est déplacée, son contenu ne change pas.
Quand une cellule est recopiée, les références relatives sont adaptées, bien sur.
Le tri effectuant des déplacements, et non pas des copier/coller, ça fout le boxon si la colonne C est aussi triée. Ce qui est tout à fait logique.
Bonne soirée
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: c'est configurable dans la 4.4 :D
Posté par lgmdmdlsr . Évalué à -1.
J'ai l'impression que nous n'avons pas les mêmes logiques d'utilisation d'un tableur, au moins dans ce cas précis. Quoi qu'il en soit, indépendemment de cela, les faits sont qu'il y a eu un changement fondamental de comportement de la fonction tri, qui, et je ne suis pas le seul à le dire, provoque d'énormes soucis dans certains cas.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
… et la colonne C sera ajustée automatiquement par LibreOffice
(cf. mon autre message dans ce thread), et ça fout effectivement le boxon dans la colonne C, même si elle n'est pas sélectionnée : les cellules de la colonne C ne pointent plus vers celles de la colonne B qui sont sur la même ligne !
Quand une cellule est déplacée, les formules qui utilisaient cette formule sont adaptées.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ah, OK, on ne parle pas de la même chose. Si tu copie-colle la cellule qui contient la formule, oui. Si tu déplace la cible de la cellule à coup de couper/coller, la formule est adaptée pour continuer à pointer sur la cellule que tu viens de déplacer. Si tu tries la cible avec un vieux libreoffice, les références ne sont pas ajustées. Si tu tries la cible avec un 4.3, les références sources sont ajustées.
C'est un peu de ça que parle le journal d'ailleurs, si tu lis bien ;-).
[^] # Re: c'est configurable dans la 4.4 :D
Posté par zurvan . Évalué à 3.
sauf que pour un tri ça ne rajoute ni n'enlève rien, du coup ça justifie moins de casser les références, mais pareil tout dépend du point de vue, et le mieux c'est d'avoir l'option pour choisir le comportement que l'on souhaite. Et surtout, ne pas modifier un tel comportement en le laissant par défaut pour ne pas casser les méthodes de travail de ceux qui utilisent le tri.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: c'est configurable dans la 4.4 :D
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Si tu fais ton tri à la main à coup de couper/coller, les références sont ajustées. Si tu fais ton tri automatiquement, ça parait logique de s'attendre au même comportement.
Maintenant, je suis d'accord sur le fait qu'avoir une option pour permettre aux habitués de l'ancien comportement de le garder aurait été une bonne chose.
[^] # Re: c'est configurable dans la 4.4 :D
Posté par qdm . Évalué à 8.
J'étais un de ceux qui ont ouvert un des multiples doublons de ce bug il y a des années. Dans l'intervalle, j'ai fini par migrer cette feuille sur Google Drive. Si tous les utilisateurs de la fonction ont migre, il ne doit plus rester que des utilisateurs du bug.
# gné ?
Posté par barmic . Évalué à 10.
C'est pas faux !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Not a big deal
Posté par mael . Évalué à 9.
Ce commentaire est assez magique :
5 mois, c'est rien. Surtout si tu utilises le logiciel tous les jours.
[^] # Re: Not a big deal
Posté par Zenitram (site web personnel) . Évalué à 5.
C'est rien du moment où tu as une solution de secours, et la tu en as une grosse de solution (utiliser la version précédente, celle qui te plaisait).
Rien de "magique".
[^] # Re: Not a big deal
Posté par zurvan . Évalué à -5.
C'est la magie du logiciel libre. On peut répondre cela aux utilisateurs parce que ça ne leur a rien coûté et qu'ils n'ont qu'à faire la modif eux-même (qui ne sera peut-être pas acceptée upstream). J'imagine la même chose sur un logiciel proprio :
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Not a big deal
Posté par lolop (site web personnel) . Évalué à 7.
Dans le logiciel pas libre, on peut simplement… ne pas te répondre (souvenir d'un bug dans les MFC que j'avais essayé de faire remonter…).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Not a big deal
Posté par BAud (site web personnel) . Évalué à 1.
ah mais euh, ne t'inquiète pas, dans le proprio c'est pareil ;-) (ou parfois on te propose un "patch" abscons "mais il n'y aura plus de support", sympa si ça casse un truc à côté, t'es obligé de faire de la rétro-ingénierie pour démontrer que le bug est de leur côté…).
[^] # Re: Not a big deal
Posté par Chris K. . Évalué à 9.
C'est bien connu dans le monde merveilleux du proprio les éditeurs sont gentils : ils font des patch en moins de 8 mois et n'envoient jamais chier leurs clients.
2 000 licences donnent du poids mais ce n'est pas une garantie d'acceptation. Tu payes pour un soft tel qu'il est édité généralement, pas pour du sur mesure. Dans le cas des bugs exploités par les utilisateurs ça craint au moins tout autant, surtout si t'es un petit client.
Puis tu perds toute possibilité de modifier le soft toi même si l'éditeur dit niet, te ballade ou met 1 an à proposer le patch.
[^] # Re: Not a big deal
Posté par Lebas Sébastien . Évalué à 10.
Si tu as une DSI incompétente, tu as un problème beaucoup plus important que le type de réponse. Et migrer un outil majeur sur tous tes postes sans vérifier qu'il convient toujours à ta chaîne de travail est un indicateur sûr d'incompétence.
[^] # Re: Not a big deal
Posté par Zenitram (site web personnel) . Évalué à -1.
Je te vire, pour incompétence, c'est tout. La faute revient à toi, qui n'a pas validé ta chaine de travail avec la nouvelle version avant de déployer (ou à l'inverse : si ça n'a pas été mis dans les tests, c'est que ce ne casse pas ta chaine de travail en réalité).
Ca n'a rien à voir avec le libre ou pas libre (le coût de la licence n'est q'uun élément parmi plein d'autre du coût), je ne vois pas où tu veux en venir.
[^] # Re: Not a big deal
Posté par barmic . Évalué à 10.
Un jour (peut être) tu travaillera en entreprise et tu pourras en parler.
Faire l'inventaire de l'utilisation des logiciels dans une entreprise un minimum conséquente est très très compliqué et demande un investissement de la part de la dite entreprise conséquent en temps et en argent (il faut aller regarder les usages des employés (qui n'aiment pas ça), inventorié, analyser l'inventaire (sinon ça ne sert à rien de le faire), le maintenir (sinon ça ne sert à rien de le faire) et former les utilisateurs pour adopter des conventions mutualiser les usages (ce que les utilisateurs n'aiment pas et ça ne sert à rien de faire un inventaire sans faire ça ensuite)).
Bref sous tes grands airs droit dans tes botes "si tu fais une erreur, j'te vire", tu ne semble pas comprendre de quoi tu parle. Aujourd'hui (en 2014 comme tu aime à le rappeler) très très peu d'entreprise ont conscience de ça et encore moins font le boulot en question même à échelle réduite.
Elles préfèrent généralement se tourner vers des applications de gestions soit clef en main, soit créer par la SS2I du coin (mais si on a pas inventorié les besoins/usages autant pisser dans un violon…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Not a big deal
Posté par kna . Évalué à 3.
Je ne serait pas aussi binaire que vous.
Franchement, si tu fais une migration de ce type sans avoir fait aucun test avant, tu es quand même un sacré boulet.
Mais en pratique, effectivement tu n'auras pas pu tester à 100% que tout est OK, et tu vas avoir des soucis à gérer post-migration ; parce que pour raison historique tu n'as pas des configs homogènes à la base ; parce que tu n'en as pas un inventaire complet, parce que tes utilisateurs vont t'avoir dit que c'est OK, mais te remonter tout de même des problème post-migration, parce qu'on est des humains et parfois on oublie des choses, parce que le truc marche bien en test, mais s'effondre passé X utilisateurs.
[^] # Re: Not a big deal
Posté par claudex . Évalué à 7.
Si ça pète toute la chaîne de travail, c'est que c'était quand même testable avant. Et que ce n'a pas seulement une implication dans un cas particulier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Not a big deal
Posté par Zenitram (site web personnel) . Évalué à -7.
attaque personnelle, tu fais comme si tu connaissais mon parcours… Dommage pour toi, le "un jour" est arrivé il y a bien longtemps, j'ai déjà fait du déploiement à grande échelle (avec ses petits bonheurs), et pas qu'un peu (avec ses belles merdes, et je ne dirai pas que je suis parfait, ça m'est arrivé de bien planter des choses).
On parle de "ça pète toute notre chaîne de travail" la…
Tu n'as pas compris une chose : on ne parles pas d'erreur pour quelques personnes (ça arrive, moi en premier, de louper des cas), mais de "ça pète toute notre chaîne de travail après qu'on ai déployé tout".
si tu penses que tu ne peux pas tester ça, tu peux être licencié pour incompétance, car c'est la base du travail d'un chef de projet (savoir ce qu'est ta chaine de travail, ne pas déployer sur 2000 postes d'un coup puis regarder si ça se passe bien etc, pas pour rien qu'on a des phases pilotes que tu n'as pas l'air de connaitre).
Puisque tu es dans le personnel (au passage, souvent signe d'un manque d'argumentation), je te retourne le compliment.
PS : sans doute que comme d'hab, en pratique "ça pete toute la chaine de travail" est la réaction de quelques perdus à qui ça pete leur chaine de travail dont ils n'ont pas parlé car ce n'est pas leur rôle de définir la chaine de travail. pas de pitité donc (et c'est complètement différent : la chaine de travail de l'entreprise va bien, le chef de projet déploiement s'en est assuré). Bref, on n'est justement pas dans des cas du petit gars dans son coin, on a 2 cas, un cas où le déploiement est très mal fait et il faut filer des baffes, et un cas où un utilisateurs ne suit pas la chaine de travail qui lui est définie et il faut filer des baffes (pas à la même personne). Je penche perso sur le gars qui est dans son coin mais qui considère que c'est "la chaine de travail" qu'on doit ne pas oublier (même si il l'a caché car sinon il aurait pris des baffes bien avant)
[^] # Re: Not a big deal
Posté par barmic . Évalué à 6.
Dixit celui qui juge la compétence de son interlocuteur…
En fait bien souvent "ça pète toute la chaine de travail" ça veut dire "ça casse au moins un peu le workflow à divers endroits dans la boite suffisamment pour que ça nuise à al productivité voir que ça fasse faire des erreurs".
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Not a big deal
Posté par Zenitram (site web personnel) . Évalué à -7.
Pas mal le fait de ne pas savoir faire la différence entre la critique de ce que tu es et la critique de ce que tu fais. Ca en dit long…
[^] # Re: Not a big deal
Posté par mael . Évalué à 1.
Ben si, le commentaire.
# contournements possibles
Posté par Jean-Baptiste Faure . Évalué à 10.
Il y a plusieurs contournements possibles selon ce que vous savez faire sur le code LibreOffice :
1/ juste l'installer : revenir à la 4.2.6.3 (secfix), c'est la dernière version à ne pas implémenter le changement induit par fdo#81309
2/ utiliser les daily builds de la branche 4.3 pour avoir une preview de la 4.3.4 : là il faut changer l'option cachée UpdateReferenceOnSort à false au lieu de true
3/ utiliser les daily builds de la branche master pour avoir une version alpha de la future 4.4.0 : là il faut changer la même option, mais c'est une simple case à cocher
4/ compiler soi-même l'une des branches 4.2, 4.3 ou master : hier a été fait un backport de l'implémentation de l'option cachée UpdateReferenceOnSort dans la branche 4.2 mais la 4.2.7 était déjà sortie. Cette option sera disponible dans une 4.2.8 si la décision d'en produire une était prise, ce dont je doute, ou dans une version maison, par exemple si une institution la prend en charge (MIMO ?)
Pour ma part, j'utilise déjà la 4.4.0 alpha pour bosser au quotidien, mais je la compile moi-même.
J'ai ouvert un "metabug" pour recenser les différents use-cases en matière de tri portant sur des cellules contenant des références : fdo#85490.
Le travail n'est pas terminé.
JBF
[^] # Re: contournements possibles
Posté par xcomcmdr . Évalué à 3.
Merci beaucoup
Le processus de dév de lo a l'air geniale (je dis ça sincèrement) <3
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.