Custom Inherited Fields

[tfranklin]

I was playing around with Geo SCADA today and trying to figure out a good way to create inherited fields such as default view link/alarm view link, but there doesn't appear to be a good way to do it.  Has anybody implemented something like this in the past?

My use case here is to create something like an area of interest, but at a group level instead of a point level and where it would also inherit from parent if not explicitly configured on a point.  Regions could potentially be used here, but the issue is that things in these "groups" might not always fall into the explicit geographic region.  I kicked around the idea of just setting a fake location that falls into a region, but if there ever was a case for configuring lat/long down the road then this would no longer be valid or apply. 

What would be ideal is if AOI could be configured at a group level, but it doesn't appear to be possible.  I'm debating creating a link/reference field and creating some logic to populate this nightly, but wasn't sure if there was another way or something that I'm missing. 

Side-note and unrelated -- there should be a label for Metadata when submitting a forum post. 

[BevanWeiss]

My understanding is that AOI only really applies to an Alarm Instance (normally based upon the configured Alarm AOI, but redirections can change this too I think).

There's not many ways I can think of doing this really.

1) via SQL.  If you have a Metadata field configured with a 'null' value defined (easy for Object References, tricky for things like integers), then you could sort by the LEN of the FullName, and have the query like:
   SELECT TOP(1) FullName, MyField
   FROM CDBObject
   WHERE MyMetaField <> {NULL} AND {MyObjectFullName} LIKE FullName || '.%'

   ORDER BY LEN(FullName) DESC

2 Via calculation point, but you'd be limited to only having a group level reference (which would contain the Calculation point)..

   IIF(".MetadataField" <> {NULL}, ".MetadataField", "..MetadataFieldCalc")

   and this would need to be in EVERY group... so it seems horrible

It might be worth raising a feature request for what you're after.  Although it does seem quite niche.

I try to avoid using AOI.  It always seems to be a real maintenance nightmare compared to the relatively small benefits that it provides.  Better in recent versions where imports don't SPAM the AOI list with hundreds of foreign language entries... but such erroneous entries still seem to find their way into the databases.

(apparently trying to add a tag automatically posts the message... this forum software is painful)

[sbeadle]

Thanks guys. Thinking aloud, what about a Metadata field which has an expression to set its value. So you have one metadata field which has an optional value, such as "SetProperty", and another based on an expression "SetPropertyInherit" which reads its value or the parent value if blank if(".SetProperty"='',"..SetProperty",".SetProperty")

You could implement as a string variable/constant now, and use a single Logic program on a daily/scheduled basis to modify it as config changes (take care only to write new values if changed).

[tfranklin]

It sounds like what I'm asking for is not something OOB, which I kind of assumed.  I don't think this feature would be a niche feature at all though.  For the purpose of this thread, it's a topic regarding creating a "group" type field that is pushed down to all children who inherit from parent, similar to default view.  However, I think the use cases for this could be rather large if it were a configurable metadata type that could be added.

I think the route I'll end up going here is to create a search key metadata field instead.  This seems simple enough to implement with a logic program that runs periodically. 

For the purpose of this thread topic specifically, I think expressions as they work today would be more work than it's worth  I would probably go this route if it was easier to set the properties on groups throughout the system.  Right now I don't believe there's a method to do this via script (please let me know if I'm just missing it!).  I haven't looked into the API yet to see if it's possible there (I'm sure it is). 

Stop reading here if you only care about the thread and not my feature requests! lol

I think template expressions in general leave a bit to be desired.  I've raised my desires about this with support before.  Early on my assumption was that I could configure the expressions to reference properties or objects relative to the template that you set them in, but that's just not the case. I believe right now the only properties you can assume from the template level are name, fullname, and parent.  Being able to create an expression at the template level for these would allow for a lot of automatic configuration of objects and properties. 

An example would be to set the alarm source for points to relatively reference certain attributes within the template level.

"..Name" + ' << ' + "Name" + ' >> ' "..objCommDeviceName"

Example 2:  Imagine a scenario where you have a station grouped up as such:
Device

  Run 1

    GQ

  Run 2

    GQ

  Station

  Valve XYZ

By setting RTU level specific properties at the device level, there would be no need to try and figure out how many parent folders you need to jump to in order to access properties from the Device folder.  These would be auto-magically pushed down and accessible using something like ".PropertyName".  Whether by inheritance or expressions, you could make this much simpler and take the guess work out.  Expressions could be set at the template and no further configuration would be required.  If you had inherited properties rather than expressions, it would have the same affect and depending on the class could be an accessible attribute on the objects themselves.  The result would be if I query a point, I can get the device level properties in the same query without the need to jump through parentgroupid->parentgroupid->______. 

I guess I'm envisioning something like dynamic bindings rather than something that has to be explicitly defined per object.