Details
-
Bug
-
Status: New
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
Navigate Terms
-
Modifiers
Description
This ticket reports two separate but related bugs which leads to a visual contradiction given certain parameter combinations in the metadata.
Bug # 1:
The first bug involves the improper visual representation of a modifier in an ontology when the C_HLEVEL is incorrect. So far, my understanding of the interaction between M_APPLIED_PATH and C_HLEVEL is that M_APPLIED_PATH specifies the root from which the modifier should hang, and in respect to the modifier treats this path as a new root with "C_HLEVEL = 0". This requires that the modifier have a C_HLEVEL value of 1. If the C_HLEVEL value is greater than 1, the modifier shows up as a regular leaf node. What I expect to happen is that the modifier should not be visible at all, since there is a gap between the "modifier root" specified by M_APPLIED_PATH and the ontological entry specified by C_FULLNAME.
Bug # 2:
This bug builds upon the first bug and occurs when we wish to create modifier folders or containers and to populate them with modifier leaf nodes. The C_FULLNAME for these modifier leaf nodes must include the C_FULLNAME of the modifier parent folder and the C_HLEVEL must be one greater than the modifier parent folder, similar to how regular folders/containers and leaf nodes are nested. However, the M_APPLIED_PATH must be the value of the C_PATH of the parent folder in order for the modifier to nest, essentially "skipping" over a level we have created. If M_APPLIED_PATH is any other value, including the C_FULLNAME of the parent folder, the modifier will not appear within the modifier folder. I expected that the rules for M_APPLIED_PATH would extend to modifier folders as well as regular folders, but it seems that there are no support for modifier concepts for this field.
Bug # 1:
The first bug involves the improper visual representation of a modifier in an ontology when the C_HLEVEL is incorrect. So far, my understanding of the interaction between M_APPLIED_PATH and C_HLEVEL is that M_APPLIED_PATH specifies the root from which the modifier should hang, and in respect to the modifier treats this path as a new root with "C_HLEVEL = 0". This requires that the modifier have a C_HLEVEL value of 1. If the C_HLEVEL value is greater than 1, the modifier shows up as a regular leaf node. What I expect to happen is that the modifier should not be visible at all, since there is a gap between the "modifier root" specified by M_APPLIED_PATH and the ontological entry specified by C_FULLNAME.
Bug # 2:
This bug builds upon the first bug and occurs when we wish to create modifier folders or containers and to populate them with modifier leaf nodes. The C_FULLNAME for these modifier leaf nodes must include the C_FULLNAME of the modifier parent folder and the C_HLEVEL must be one greater than the modifier parent folder, similar to how regular folders/containers and leaf nodes are nested. However, the M_APPLIED_PATH must be the value of the C_PATH of the parent folder in order for the modifier to nest, essentially "skipping" over a level we have created. If M_APPLIED_PATH is any other value, including the C_FULLNAME of the parent folder, the modifier will not appear within the modifier folder. I expected that the rules for M_APPLIED_PATH would extend to modifier folders as well as regular folders, but it seems that there are no support for modifier concepts for this field.