[grisbi-user-french] Opération dans archive clonée

[R1]

Pierre Biava wrote on lundi 11 octobre 2010 21:25:

>   R1 écrivait le 11/10/2010 20:53 :
>> J'ai voulu retrouver une opération de l'année dernière, pour prévoir dans
>> mon budget sa charge puisque c'est récurent.
>> Sachant que mes opérations de 2009 sont dans une archive, j'ai déployé
>> l'archive, sélectionné l'opération en question et fait "cloner". ensuite
>> j'ai changé la date pour avoir 2010.
>> Tout allait bien jusqu'à ce que je constate que la dite opération était
>> déjà dans mon échéancier: ben oui j'avais déjà trouvé l'an passé la
>> fonction qui permet de mettre une opération à périodicité annuelle.
>> Bref, que devais-alors faire? Simplement supprimer l'opération clonnée me
>> riez vous!
>> Ben mon Grisbi 0.6.0 GTK 2.20.1 du 05/05/2010 à 22:28:42 sous Debian
>> squeeze ne feut pas effacer une opération archivée.
>> Effectivement, en pratique l'opération clonée est empaquetée dans
>> l'archive, ce qui fait qu'elle n'est plus visible quand l'archive est
>> repliée...
> 
> Je pense qu'il faut considérer ça comme un bug car l'opération clonée ne
> devrait pas être archivée.
> 
> Merci de déclarer un bug sur mantis.

j'irai y faire un tour prochainement (pas ce soir!)

>> Comment faire pour corriger cette erreur de saisie qui doit avoir des
>> impacts sur, par exemple, les rapprochements, avec un tel décalage dans
>> l'archive?
> 
> Il suffit de retrouver l'opération en question et de modifier le numéro
> d'archive. Dans l'exemple ci-dessous le numéro de l'opération est 1850
> et le numéro d'archive est 2 il suffit de le remplacer par 0 pour
> accéder à l'opération et la supprimer.

(...)

> Enregistrer puis ré-ouvrir le fichier avec grisbi normalement
> l'opération devrait pouvoir être supprimée.
> 
Gagné, l'opération est désormais éditable et peut être supprimée.
Merci pour la démarche: vive les logiciels libres qui stockent leurs données 
dans un format éditable!