Projet

Général

Profil

Anomalie #2111

[Array et visibilité] Lorsque la frame encadrante est en S la visibilité du tableau passe en S même si il est en U initialement

Ajouté par Charles Bonnissent il y a plus de 8 ans. Mis à jour il y a plus de 8 ans.

Statut:
Intégré
Priorité:
Bas
Assigné à:
-
Version cible:
Début:
11/10/2011
Echéance:
% réalisé:

100%

Version source:
Solution proposée:

Deux solutions possibles :

  • changer les priorités pour rendre le U prioritaire mais cela risque d'être source de confusion
  • intégrer la notion de U dans le S actuel du tableau, un tableau en S serait alors statique sur sa structure (impossible de changer le nombre de ligne) et son contenu (visibilité des attributs)

Solution retenue :
Si le tableau est en 'U', la visibilité des attributs est lié au père du tableau.
S - U - W => S
W - U - W => W
R - U - W => R
I - U - W => I

Modification de computeVisibility pour avoir le grand père.

Principaux fichiers impactés:
Complexité:
Moyen
Contrôle:

TAUFU: Suite Document
Class Visibilité
Tests sur la méthode computeVisibility

Thème:
Régression:
Non
Jalons:

Description

Étant donné que la visibilité en U n'est pas équivalente à celle en S et que celle en S n'est pas plus restrictive que celle en U, on a une dégradation du comportement du formulaire.

Si on prend le scénario suivant :

  • un document dans un état alpha propose un tableau T (contenant des attributs en visibilité W) en visibilité U dans une frame F dans une visibilité W. Là le tableau se comporte comme prévu c'est à dire qu'on ne peut pas ajouter de ligne (tableau statique)
  • on passe le document à l'état bêta et on lui applique, un masque qui change la visibilité de la frame F à S. Alors le tableau T prend la visibilité S et on peut donc lui ajouter des lignes (ce qui n'est pas prévu à l'origine) sans pour autant pouvoir éditer le contenu de ces lignes (car la visibilité de son contenu passe en S).

On peut facilement contourner le problème de manière locale en forçant dans le masque la visibilité du tableau en U lors de la création du masque mais cela à deux défauts :

  • c'est fastidieux et source d'erreur (un tableau peut facilement devenir non statique)
  • il faut penser à toutes les interactions possibles lors de la maintenance et de l'héritage

Demandes liées

Lié à Core - Evolution #1275: [array] Intérêt de U pour un array Nouveau 14/10/2010
Lié à Core - Anomalie #2327: [report 2111] [Array et visibilité] Lorsque la frame encadrante est en S la visibilité du tableau passe en S même si il est en U initialement Intégré 11/10/2011

Historique

#1 Mis à jour par Charles Bonnissent il y a plus de 8 ans

  • Solution proposée mis à jour (diff)

#2 Mis à jour par Éric Brison il y a plus de 8 ans

  • Priorité changé de Normal à Bas
  • Version cible mis à 3.1.2
  • Solution proposée mis à jour (diff)

La visibilité 'U' n'est pas équivalent à 'S'.
Si un tableau est en U et ses attributs en W, ces derniers restent à 'W'.
Si un tableau est en S et ses attributs en W, ces derniers passent à 'S'.

#3 Mis à jour par Charles Bonnissent il y a plus de 8 ans

  • Sujet changé de [Array et visibilité] Le U n'est pas toujours pris en compte à [Array et visibilité] Lorsque la frame encadrante est en S la visibilité du tableau passe en S même si il est en U initialement
  • Description mis à jour (diff)
  • Solution proposée mis à jour (diff)

#4 Mis à jour par Charles Bonnissent il y a plus de 8 ans

  • Solution proposée mis à jour (diff)

Le S actuel a quand même peut d'utilité => que faire d'un tableau dont on peut ajouter des lignes mais dont on ne peut pas modifier le contenu de la ligne

#5 Mis à jour par Éric Brison il y a plus de 8 ans

  • Complexité mis à Moyen

#6 Mis à jour par Éric Brison il y a plus de 8 ans

  • Solution proposée mis à jour (diff)
  • Contrôle mis à jour (diff)

#7 Mis à jour par Éric Brison il y a plus de 8 ans

  • Statut changé de Nouveau à Intégré
  • % réalisé changé de 0 à 100

Appliqué par commit commit:3396b3d12b19335ed730e36bde257cea42ec8cdc.

Formats disponibles : Atom PDF