Allow substitution parameters in attribute template description
As a user, I want to be able to use substitution parameters in attribute template descriptions, so that when elements are created from template, the attribute template description can be substituted with pertinent information.
Note: This was previously Enhancement 116200.
We use string child attributes in templates (PI tag names) provide the pi point reference in the parent attribute. It would be nice to be able to load this Tag name into the parent attribute description at run time. PI Tag names are instrument IDs and equipment numbers and it would be nice to see this as additional information in PI Vision when a user hovers over an attribute with their mouse.
I have the same issue. Normally the description for the PI tag should be good enough also for the attribute and should be the best description for it. So I think it should be a standard to substitute the attributes description with the tag description.
Yes that would be a very useful feature as of now we can only have generic useless comments in templates.
The specific functionality that I am looking for is when an AF Attribute is pointing at a PI tag, the Description needs to come directly from the PI tag rather than being a separate static thing that you have to manage and maintain separately and manually.
Is there an expectation that the description reflects the substitution pattern automatically after initial creation?
For example, Name substitution patterns defined in the template are applied on initial creation, otherwise, must be manually re-applied.
Also, for this to work at the attribute level, AF would have to enable attribute override of description - which is currently not possible (although often requested and on our radar). There are performance and storage implications for this feature that have to be considered. We are cautious when a simple feature such as this can lead to surprising and drastic changes in performance and scale.
Dynamic re-evaluation of description substitution is difficult because it impacts features like search which work best with a fixed index-able value.
This would also include Element and Event Frame description fields correct?