Closed DonovanMaillard closed 4 years ago
Oui @jbrieuclp avait déjà remonté le problème avec une solution qui allait bien mais je ne retrouve plus le ticket...
J'avais pas vu passer, désolé! je vais chercher ça et voir la solution qu'il proposait :) Merci!
pas directement abordé à priori, mais rejoint un peu les réflexions à avoir de manière globale suite à #659
Oui, je proposais qu'en fonction des droits de l'utilisateur (pas de droit d'écriture ou edition) dans le JDD ou alors JDD non actif, la zone de liste soit remplacée par du texte. Ce qui permet d'avoir l'info sans la modifier. Le reste (l'occurrence) pouvant toujour l'être.
Au top, on retombe donc sur la proposition de figer le jdd et ne pas pouvoir le modifier :)
Fait
Le cas des relevés associés à un JDD qui ne sont plus associé au module n'est pas géré. Ces données ne devrait pas être éditables, voir supprimées d'occtax ?
A mon sens, les données ne devraient plus être éditables quand jdd_actif=false.
En revanche les supprimer du module de saisie me surprendrait. Ca rendrait l'inactivité d'un jdd irréversible, or on peut imaginer des programmes suspendus, des études renouvelées, ou des jdd cloturés sur lesquels on appercoit une erreur qu'on veut corriger pour ne pas fausser des analyses à posteriori etc.
+1 avec la remarque de Donovan. Il suffirait de seulement désactiver le bouton d'édition pour permettre au moins l'accès à la page info/ d'occtax
Oui mais il y a deux cas: JDD = inactif (cas d'un JDD historique, on peut toujours vouloir revenir sur une donnée pour la corriger, mais pas en ajouter de nouvelle) JDD non associé au module (dans ce cas les données n'ont pas a avoir été saisie dans Occtax)
Hmm... je reste dubitatif. Si les données sont arrivées dans un module c'est qu'à un moment, le jdd a été associé. Ou alors que les données ont été changées de jdd à un moment. Dans les deux cas c'est des cas un peu tordus, sur lesquels une erreur en bdd deviendrait irréversible.
Si par exemple on se plante en bdd en modifiant le jdd d'une donnée, alors ca la supprime du module de saisie et en ricochet, ca la supprime de la synthèse via les triggers. L'erreur devient irréversible.
A voir si le fait de les garder dans le module complique les choses niveau développeemnt, mais concrètement ce rattachement entre jdd et module pour moi pourrait se limiter à un filtrage des jdd remontés en interface sans impacter les données.
Hmm... je reste dubitatif. Si les données sont arrivées dans un module c'est qu'à un moment, le jdd a été associé.
Dans ce cas tu dis simplement que le JDD est inactif, mais si il a des données OCCTAX, c'est qu'il est associé, ou a été associé à OCCTAX. Donc tu le laisse dans cor_dataset_module, mais tu dis que le JDD est inactif dans t_datasets
Si par exemple on se plante en bdd en modifiant le jdd d'une donnée, alors ca la supprime du module de saisie et en ricochet, ca la supprime de la synthèse via les triggers.
Non, non j'ai jamais dis ça !
mais concrètement ce rattachement entre jdd et module pour moi pourrait se limiter à un filtrage des jdd remontés en interface sans impacter les données
C'est le cas.
Je dis juste qu'il ne faut pas supprimer de "cor_dataset_module" un module qui possède des données dans occtax. Sinon on ne pourra plus les modifier.
Par contre je pense qu'il est important de pouvoir modifier des données dont le JDD est inactif (cas d'une correction). Par contre le champs JDD est figé.
J'étais resté sur ça :
Ces données ne devrait pas être éditables, voir supprimées d'occtax ?
En revanche sur un jdd inactif tu penses que les données doivent rester éditables? Un jdd inactif n'est pas supposé contenir que des données elles-mêmes figées?
Si le but d'actif/inactif est uniquement de remonter le jdd dans le module de saisie, alors le rattachement du jdd au module suffit, cette notion d'actif/inactif n'est peut être plus nécessaire ?
Ces données ne devrait pas être éditables, voir supprimées d'occtax ?
Oui je parlais plutôt manuellement par l'administrateur.
En revanche sur un jdd inactif tu penses que les données doivent rester éditables? Un jdd inactif n'est pas supposé contenir que des données elles-mêmes figées?
On en a rediscuté avec Gil, oui je pense qu'il est important de pouvoir revenir/corriger une données d'un JDD inactif. D'ou les 2 notions
Ça c'est cool comme apport !
Forcement on donne la main, on demande le bras...
J'aurais comme petite suggestions les choses suivantes :
Dans le cas où le JDD est désactivé mais que l'utilisateur a des droits de modifs sur le relevé, je verrais bien un petit bouton édition à côté du JDD pour switcher sur la liste d'édition des JDD de base.
Le relevé peut être bon, mais le JDD pas correctement renseigné. De plus j'ajouterai une tooltip sur le JDD indiquant "La modification de ce jeu de donnée n'est pas activée actuellement."
ou un truc dans le genre pour expliquer pourquoi c'est juste du texte.
Si l'utilisateur n'a pas de droits de modif car pas associé au JDD, la tooltip pourrait être affichée (est-ce qu'il faut un icone i à côté ?) indiquant "Il ne vous est pas possible d'éditer ce jeu de données, vous n'en êtes pas personnellement associé"
En passant mes données historiques dans occtax, je me rends compte d'un cas qui est géré de façon un peu spécial.
Si je saisis en 2017 une donnée dans un JDD propre a une étude, et que le JDD est devenu inactif :
Ce qui semblerait le plus cohérent serait :
En attendant, on se retrouve avec des données modifiables pour lesquelles occtax n'arrive pas à récupérer toutes les infos. A discuter :)