I suspect security issues. Even without allowing overrides, you should be able to change the datareference of an attribute, configstring, and properties.
2 of 2 people found this helpful
You might be better off in the long run to structure it slightly different.
Have your top level container "Basic_Report_Template" but then have child elements from "Basic_Report_Item_Template" below (defined by a Reference Type). Then you could have a few Attributes in the Basic_Report_Item_Template derived elements (Data Stream, Stream Description, ...) but the big benefit is that your users can create as many child elements as they need to monitor, which will vary vastly. Then your logic for parsing the structure into a report is to simply retrieve the child elements from a users report container element.
Just a thought.
Thinking out loud again...you should be able to edit the Data Reference or Config String so it might be security related like Roger said.
Unless you're using an AF Collective connected to a secondary?
3 of 3 people found this helpful
Attribute names and Description from an element template cannot be overridden in the element instance. It would be weird to allow overriding the Attribute template name. For example, let's say you have an element template called "Pump" and you have an attribute template called "Temperature". Every instance of that pump template should have a temperature attribute. Otherwise it's not much of a template :-). We have had a couple of users requesting the ability to override the attribute description in an element instance. However, there's a cost associated with that as it negatively affects our ability to scale. For now, we have not implemented this feature request.
You are able to override the PI Point data reference configstring in an attribute template. That's by design.
1 of 1 people found this helpful
I once had to delete an entire hierarchy and re-export it WITHOUT templates in order to edit the descriptions. Now that hierarchy has to be maintained without templates If a template for the description could be defined using substitution parameters this would be better than not being able to edit the descriptions.
The use case was, users did not like AF names "temperature" "pressure" etc. so we put the tag name (eg. PI-10111.PV) in the descriptor so they saw this in the trends instead of the Tag descriptor (which had to follow a standard, and didn't contain tag name!)