# \[IGN-15470\]Is it possible to reset a tag property to default in scripting? **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [February 9, 2026, 1:33pm UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849 "2026-02-09T13:33:14Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 6, 2026, 2:28pm UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/21 "2026-03-06T14:28:47Z")
> [@JVDM](#): > > My first step in the process was to get it done in any way, to see if it was possible. Step 2 would be to do it programmatically. 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. ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [March 7, 2026, 5:49am UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/22 "2026-03-07T05:49:04Z")
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. > [@nminchin](#): > > `isAvailable` expression function which is an absolute necessity 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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 7, 2026, 6:40am UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/23 "2026-03-07T06:40:20Z")
> [@ggross](#): > > The currently `isAvailable` expression in the module will take any qualified value and return true/false based on the Quality code. 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 > [@ggross](#): > > An `overridesOnly` parameter has been added to `system.tag.getConfiguration` and will be part of the 8.3.5 release. This is awesome and will be extremely useful! Thanks for adding and the update ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [March 9, 2026, 3:09pm UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/24 "2026-03-09T15:09:10Z")
> [@nminchin](#): > > 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 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. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 9, 2026, 4:58pm UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/25 "2026-03-09T16:58:26Z")
> [@nminchin](#): > > Without having this in a single function requires a surprisingly difficult and overly complicated expression! I recall [a version](https://inductiveautomation.canny.io/ignition-features-and-ideas/p/add-expression-function-to-check-if-tag-is-valid-found-and-not-disabled) that was more complicated: ```javascript indexOf(toStr(qualityOf({tag})), 'Bad_NotFound') = -1 && indexOf(toStr(qualityOf({tag})), 'Bad_Disabled') = -1 ``` But, as of around 8.1.10: > [@How to locate the number 'value' of a Tag's Data Quality](https://forum.inductiveautomation.com/t/how-to-locate-the-number-value-of-a-tags-data-quality/26840/16): > > Reviving this thread because of changes that landed in the latest nightly build/8.1.10: The gist: In addition to isGood, we've added new expression functions to test each different level (isBad, isUncertain, isError). As a further mechanism to allow direct comparison, e.g. if you want to find out if something is disabled, you can use the new qualityOf expression; this will return the QualityCode object from the input. The equality operator has been 'overloaded' for QualityCodes in expressions… This [simplified version](https://forum.inductiveautomation.com/t/ignition-extensions-convenience-utilities-for-advanced-users/64615/95) makes everything a **tad** more manageable: ```javascript qualityOf({tag}) != 'Bad_NotFound' && qualityOf({tag}) != 'Bad_Disabled' ``` 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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 9, 2026, 9:45pm UTC](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849/26 "2026-03-09T21:45:51Z")
> [@Chris\_Bingham](#): > > While it does feel a bit use-case-specific to port over the `isAvailable` function…I’d certainly use it as well. T 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 [Previous page](https://forum.inductiveautomation.com/t/ign-15470-is-it-possible-to-reset-a-tag-property-to-default-in-scripting/113849.md?page=1)