Open vladbalcanu opened 7 months ago
Hi @vladbalcanu
Thanks for highlighting your enhancement needs.
It seems this is not obvious or quick fix from our side, so please could you log this issue to MSTR TechSupport and share here CS ID number so we can plan priorities and capacity for work related to this item internally.
For each attribute form there is a field named category that can only be set in the creation phase. This field can't be altered later and this is also specified in the details of the AttributeForm class. Through testing we have found out that this category influences the ability to link attributes and as a consequence the ability to use target visualizations. To be more specific, it seems like the key form of an attribute must have the category as ID (this is default when creating from workstation). Also, if there is a second attribute form, this seems to be set to DESC in the workstation. From experiments, after having 2 attribute forms, adding other attribute forms will set the category in different fashion using the attribute name in some way. We know that not having the category of the key-form set to ID causes linking issues with other attributes inside a dossier (i.e. no attribute recommendations or options are given when trying to link, even if you have 2 identical attributes just with different names). This is not documented anywhere even though we've tested this multiple times and it seems to be the case. Possibly even the second attribute form's category not being set to "DESC" could cause problems as well. This can be solved by just setting the category when creating the attributes however, for already created attributes, this problem is irreversible.
Can the Python API be updated in order for the Category class parameter of an attribute form to be available for updating/changing? This would be very needed in order to fix existing attributes.
Steps to reproduce problem with linking Attributes in Workstation: