[BUG-15001] Bad_AccessDenied error on all calls to system.tag.configure() in latest 8.0.5-nightly

Just upgraded our development server from 8.0.3-rc2 to 8.0.5-nightly (b2019091302) today.

All calls to system.tag.configure in our gateway scripts are now failing for Bad_AccessDenied. I just skimmed the nightly release notes between those two versions, and there were a few things around tag configuration, but nothing that looks directly related.

I have verified that I can configure the tags in the Designer GUI, but I get the error if I call system.tag.configure() from the Designer’s script console.

Is this an issue anyone else is bumping into or are we special? :slight_smile:

If it matters, the tags are from the MQTT Engine provider. I had upgraded that module to the latest nightly build at the same time as I upgraded Ignition, but then downgraded it back to the prior version when I noticed this error. The error is still sticking around, so I’m less inclined to blame MQTT Engine.

Maybe MQTT Engine isn’t in the clear just yet… I am able to call system.tag.configure() on tags from other providers… Still experimenting…

Hi Justin,

I see that you got in contact with support and we have filed a ticket for this issue.

I’ll let you know when we have a fix.

Hi,

Just wanted to say, this is an issue in the platform, not the CL modules. We recently modified the tag security model, and in this case, changes from scripts get marked as “new” configs. In a normal provider, the “overwrite” policy would let it work, but users aren’t allowed to create new tags in the MQTT provider, so it’s incorrectly failing, instead of treating it like an edit.

Fix is pending for 8.0.5, will let you know when it makes it into a build!

This issue was fixed in the 8.0.5 nightly build that was uploaded today (9/27).

1 Like

Hi @awalker, I am on 8.0.5-rc1 (b2019100115) and I am still getting this error when trying to edit MQTT tags through scripting.

I think I have located the problem, I was thinking I had to do an “a” in the collision policy because “o” changed the MQTT tag value to stale, but after triggering a rebirth it seems to be working correctly now!

1 Like

@mitchell-ACS
That would make sense. The changes Colby made above are specific to the evaluation of edits, and with an abort or rename collision policy, the edit can’t go through. Either overwrite mode should work, as you noticed.

1 Like