Strictly speaking to the ‘by any means’ portion of this problem…
I often use the Tag Report Tool in order to get the list of tags which I want to modify in bulk (able to query for tags which are UDT instances, contain a property, have overrides, etc.), I then highlight any/all tags –> Right Click –> Edit, which opens up the tag editor for multiple tags. There, you can ‘click the little green dot’ to remove overrides across all selected tags. When you change a property, you’ll notice a checkmark appear next to any properties which will be written to all selected tags. All others will be left alone.
This became my go-to for editing in bulk…as it handles most-all of the edge cases without the prior-knowledge required for a scripted approach.
An overridesOnly parameter has been added to system.tag.getConfiguration and will be part of the 8.3.5 release. It will be in the 8.3 nightly as of tomorrow morning. When you get dev and QA annoyed at how frustrating it is to do something, they sometimes will just get it implemented, especially when we realized how easy the change was.
There is a separate ticket for this (IGN-15507). There is some disagreement on how it should be implemented. The currently isAvailable expression in the module will take any qualified value and return true/false based on the Quality code. This means you have to try and evaluate a value for a tag which is inefficient. Some are pushing for a tag path to be the object passed to the expression, but then this limits the usability to only tags. There is also a bit of back and forth on if this would be useful anywhere other than tags based on the quality codes the expression is looking for. We do want this useful, so any thoughts can be passed along.
I use this function with prop values that are bound to a tag binding, so the arg to the isAvailable function is a binding to a prop, if that helps. I don’t know if I'd ever use it with non-tag values
This is awesome and will be extremely useful! Thanks for adding and the update
This helps. If the main use case is a value that is a qualified value already, then a direct port would probably be the most beneficial. I will make sure the information is added to the discussion.
I am using the above in several views (Edge projects). While it does feel a bit use-case-specific to port over the isAvailable function…I’d certainly use it as well. To echo your use, I would be pointing the function at an existing property (which is bound to a tag) as well.
I disagree. The only time you want to hide something in the UI if you're using it to hide tags between 1) different but similar UDTs or 2) the same UDT with manually disabled tags (both of which are very common practices), is by checking if the tag is either not there or disabled, which is the exact reason for the function. Otherwise you’ll be hiding it on valid error conditions. It's a convenience function for sure, but in the same vein as dateIsAfter/Before, etc. are which would be painful to replicate without. They also remove human errors in copy pasting / replicating the logic in all the places you need it