Visualiser les détails du résultat
| Identifiant | Projet | Catégorie | Visibilité | Date de soumission | Dernière mise à jour |
|---|---|---|---|---|---|
| 0001242 | SIC | EdiSic Géométrie | public | 2016-02-12 14:46 | 2016-03-16 17:20 |
| Rapporteur | dorch | Assigné à | dorch | ||
| Priorité | urgente | Impact | critique | Reproductibilité | toujours |
| Statut | fermé | Résolution | corrigé | ||
| Version du produit | |||||
| Version ciblée | 5.36a | Résolu dans la version | 5.35j | ||
| Résumé | 0001242: Les profils prédéfinis sont perdus lors d'un copier-coller d'un projet à un autre | ||||
| Description | Si un profil prédéfini avec un nom identique n'existe pas dans le projet destination, la géométrie des sections copiées est perdue. Comme les données de géométrie existent au niveau des sections y compris pour les profils prédéfinis, il est possible de faire un test au moment du collage pour vérifier l'inexistence du profil prédéfinie dans le projet destination et le créer automatiquement. | ||||
| Balises | Aucune balise n'est associée. | ||||
| Temps projeté (jours) | |||||
|
|
Ajout d'une balise NomModel dans le profil pour pouvoir vérifier que le nom du modèle lors du "Coller" existe dans la bibliothèque du fichier destination. Si le nom n'existe pas, une nouvelle section modèle est créée. Si la balise NomModel existe alors c'est elle qui détermine la section modèle à utiliser dans la bibliothèque, si elle n'existe pas (Version < 5.36) alors c'est le numéro de modèle qui est utilisé. J'en ai profité pour accélérer la lecture dans le cas d'utilisation de sections modèles dont le modèle existe dans la bibliothèque en chuintant la lecture du profil qui est inutile dans ce cas précis. |
|
|
Il faudrait aussi vérifier que la géométrie de la section modèle importée est identique à la géométrie de la section modèle présente dans la bibliothèque du projet destination, et, dans le cas où la géométrie est différente, renommer le nom de la section modèle importée. Cela pose plusieurs problèmes : - C'est dans la routine de lecture du XML que se trouve la vérification de l'existence de la section prédéfinie dans la bibliothèque et c'est un peu contre-productif de vérifier la conformité de la géométrie de la section Modèle de la bibliothèque à la lecture de chaque section dans le cas de la lecture du fichier XML du projet (Ça oblige à lire les données de géométrie des sections et de lancer le test d'égalité à chaque section, alors que la conformité est forcément assurée dans ce cas précis). Il faudrait un indicateur permettant de connaitre le contexte d'appel de la routine LitXML. - Lors d'une importation par copier/coller de plusieurs sections prédéfinies ayant un nom identique à la section modèle de la bibliothèque mais avec une géométrie différente, à la première section, on va créer une nouvelle section modèle avec le même nom suivi d'un numéro d'ordre, à la seconde et aux suivantes, le même test aura lieu mais il faudra en plus vérifier que le modèle renommé existe déjà et vérifier que la géométrie correspond pour ne pas recréer autant de modèle que de sections importées. |
|
|
Je ferme le ticket car le bug est résolu. L'amélioration de la gestion de la bibliothèque de profil sera gérée au niveau de 0001243 |
| Date de modification | Nom d’utilisateur | Champ | Changement |
|---|---|---|---|
| 2016-02-12 14:46 | dorch | Nouveau bogue | |
| 2016-02-12 14:46 | dorch | Statut | nouveau => affecté |
| 2016-02-12 14:46 | dorch | Assigné à | => dorch |
| 2016-02-15 11:47 | dorch | Note ajoutée: 0001301 | |
| 2016-02-15 11:47 | dorch | Statut | affecté => fermé |
| 2016-02-15 11:47 | dorch | Résolution | ouvert => corrigé |
| 2016-02-15 11:47 | dorch | Résolu dans la version | => 5.36a |
| 2016-02-17 12:09 | dorch | Note ajoutée: 0001302 | |
| 2016-02-17 12:09 | dorch | Statut | fermé => retour d'informations |
| 2016-02-17 12:09 | dorch | Résolution | corrigé => réouvert |
| 2016-03-10 17:21 | dorch | Note ajoutée: 0001303 | |
| 2016-03-10 17:21 | dorch | Statut | retour d'informations => affecté |
| 2016-03-10 17:21 | dorch | Statut | affecté => fermé |
| 2016-03-10 17:21 | dorch | Résolution | réouvert => corrigé |
| 2016-03-16 17:20 | dorch | Résolu dans la version | 5.36a => 5.35j |
