8.0.13 : tag permissions issue after upgrade from 8.0.12

I’ve upgraded a gateway from Ignition 8.0.12 to 8.0.13

when I write to the tag, in the tag browser, the designer freeze
I have the following error in the gateway:

My user source for a vision projet is a database user source:

When I test login, role seem ok

The security level is empty. Perhaps because data com from the legacy user source ?

Permission have been migrated in 8.0.13:

8.0.12 was:

But when I write to the tag, the designer freeze.

If I check “Public”, I can’t write to the tag, and when I try to browse the available permission, the role are not available anymore, WHY ??? and I only have:


For Tag Permissions in 8.0.13, we are leveraging the Permissions model we implemented for Perspective. Because Identity Providers (IdP) are now supported and we don’t have insight into all the roles for every IdP setup, it is a manual process (even for the Ignition IdP).

The complication then arose that Tags would have had existing security and we needed to support it even if the Gateway had not been completely setup with Security Levels. On upgrade to 8.0.13, the permissions for the tag are maintained and you will be able to visually see roles available in the Designer when editing a tag as if they were configured, but on change they will be removed (as you saw when you changed them to Public).

It is expected that anyone wishing to use Tag Permissions will manually add Roles to the Config > Security > Security Levels area of the Ignition Gateway as is noted at the top of your last screen shot.




Thanks for those clarifications, but for migrated tags writes command are failed.
I’ve tried to add the roles in the security levels, but writes command are failed too.

If I create a new tag with the same permissions as displayed, it’s ok for the new tags.

the gateway message for the error:

09Jun2020 17:40:50
Error during blocking read of tags through scripting.

java.util.concurrent.TimeoutException: null

at java.base/java.util.concurrent.CompletableFuture.timedGet(Unknown Source)

at java.base/java.util.concurrent.CompletableFuture.get(Unknown Source)

at com.inductiveautomation.ignition.gateway.script.GatewayTagUtilities.readBlockingImpl(GatewayTagUtilities.java:172)

at com.inductiveautomation.ignition.common.script.builtin.AbstractTagUtilities.readBlocking(AbstractTagUtilities.java:358)

at jdk.internal.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)

at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.base/java.lang.reflect.Method.invoke(Unknown Source)

at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:188)

at com.inductiveautomation.ignition.common.script.ScriptManager$ReflectedInstanceFunction.__call__(ScriptManager.java:520)

at org.python.core.PyObject.__call__(PyObject.java:480)

at org.python.core.PyObject.__call__(PyObject.java:484)

at org.python.pycode._pyx1419.valueToDetail$6(:261)

at org.python.pycode._pyx1419.call_function()

at org.python.core.PyTableCode.call(PyTableCode.java:171)

at org.python.core.PyBaseCode.call(PyBaseCode.java:308)

at org.python.core.PyFunction.function___call__(PyFunction.java:471)

at org.python.core.PyFunction.__call__(PyFunction.java:466)

at org.python.core.PyFunction.__call__(PyFunction.java:456)

at org.python.core.PyFunction.__call__(PyFunction.java:451)

at com.inductiveautomation.ignition.common.script.ScriptManager.runFunction(ScriptManager.java:814)

at com.inductiveautomation.ignition.gateway.project.ProjectScriptLifecycle$TrackingProjectScriptManager.runFunction(ProjectScriptLifecycle.java:687)

at com.inductiveautomation.ignition.common.expressions.functions.ScriptFunction.execute(ScriptFunction.java:91)

at com.inductiveautomation.ignition.common.expressions.FunctionExpression.execute(FunctionExpression.java:69)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.BoundPropEvalPropertySet$BoundValue.evaluate(BoundPropEvalPropertySet.java:234)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.BoundPropEvalPropertySet$BoundValue.evalAndGet(BoundPropEvalPropertySet.java:261)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.BoundPropEvalPropertySet.getOrDefault(BoundPropEvalPropertySet.java:126)

at com.inductiveautomation.ignition.common.config.AbstractExtendedPropertySet.getImpl(AbstractExtendedPropertySet.java:49)

at com.inductiveautomation.ignition.common.config.AbstractExtendedPropertySet.getOrDefault(AbstractExtendedPropertySet.java:71)

at com.inductiveautomation.ignition.common.config.PropertyValueSource.getValues(PropertyValueSource.java:30)

at com.inductiveautomation.ignition.common.config.MutablePropertyValueSource.merge(MutablePropertyValueSource.java:16)

at com.inductiveautomation.ignition.common.config.BasicPropertySet.(BasicPropertySet.java:47)

at com.inductiveautomation.ignition.common.config.BasicPropertySet.(BasicPropertySet.java:42)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm$AlarmPropertyModel.snapshotData(Alarm.java:1203)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.captureEventData(Alarm.java:744)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.finishTransitionEvent(Alarm.java:797)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.initTransitionEvent(Alarm.java:769)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.evaluate(Alarm.java:585)

at com.inductiveautomation.ignition.gateway.alarming.AlarmManagerImpl$AlarmEvaluatorImpl.evaluate(AlarmManagerImpl.java:672)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.alarming.AlarmingActor.processValue(AlarmingActor.java:203)

at com.inductiveautomation.ignition.gateway.tags.runtime.nodes.ExecutableTag.valueChanged(ExecutableTag.java:355)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.AbstractValueGeneratingActor.fireValueChange(AbstractValueGeneratingActor.java:76)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.AbstractValueGeneratingActor.fireValueChange(AbstractValueGeneratingActor.java:50)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.opc.OpcActorFactory$OpcActor.setValue(OpcActorFactory.java:760)

at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaSubscriptionSynchronizer$DataValueConsumer.accept(OpcUaSubscriptionSynchronizer.kt:577)

at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaSubscriptionSynchronizer$DataValueConsumer.accept(OpcUaSubscriptionSynchronizer.kt:548)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaMonitoredItem.lambda$setValueConsumer$0(OpcUaMonitoredItem.java:130)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaMonitoredItem.onValueArrived(OpcUaMonitoredItem.java:188)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaSubscriptionManager.lambda$null$39(OpcUaSubscriptionManager.java:698)

at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:119)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)


I am attempting to duplicate this locally and am not having any success. Can you please provide me with the following?:

  1. A pre-8.0.13 export of the tag you are seeing issues with (and any related UDT items if needed)
  2. The specific script that is being called where the NPE is occurring

What I have done to attempt to duplicate:

  1. In 8.0.12, setup a DB User Source with the Roles you have mentioned
  2. Created a new project that uses the user source created in step 1
  3. Created a Memory tag with the security settings provided
  4. Created a Window with a Button that calls system.tag.writeBlocking to write a value to the tag

In 8.0.13:

  1. Imported the Gateway Backup
  2. Logged into the Designer with a user that does not have any of the roles configured by Tag Security
  3. Confirmed that the Tag Browser in the designer isn’t showing me the value (because I am not logged in as a user with appropriate permissions)
  4. Confirmed the Window isn’t allowing me to write to the tag (as I don’t have permissions)
  5. Confirmed no NPE
  6. Logged into the Designer with a user that has set roles
  7. Confirmed that I could see/edit the value in the Tag Browser and that the button on the Window allows for writing
  8. Confirmed no NPE

Any additional information you can provide would be very much appreciated.


Ok, I will send you by PM a link to download a gateway backup and tag exports from my 8.0.12 before the upgrade.

For a vision project upgrade, do we need to manually add the roles provided by the database user source in the Config > Security > Security Levels ?

If we don’t add them, I don’t understand why after upgrading to 8.0.13, only checked role is visible in the tag edit permission windows.

If we need to add them, how to keep a consistent roles management beetween the legacy “User,roles” and the security levels settings ???

The NPE occur when I try to write the tag in the designer tag browser

I have the backup and haven’t been successful in duplicating the issue as of yet. I have sent you some additional questions via PM as I am referring to specific tags within your data.

For a Vision project upgrade, if you intend to use Tag Security then you will need to manually add the roles on the Config > Security > Security Levels page. While everything should work on upgrade, any changes to security on tags will require this be configured.

As for keeping Roles in Sync with security levels, unfortunately it is a manual process at this time and whenever a new role is added to the DB you will have to manually add it in the Security Levels UI. This is true for both Perspective and Tag Security permissions. We have an open feature ticket to make this better as we know this is far from ideal.

The current permissions you have after upgrade came along with the definitions of the tags. When you configured the tag pre-8.0.13, you explicitly put Roles and Zones into the tag definition that was stored and it looked/looks like the following:

    "permissionModel": [
            "role": "SYS_param",
            "writeAccess": true,
            "zone": "Default"
            "role": "GTC_visu",
            "writeAccess": false,
            "zone": "Default"

On upgrade that explicit definition came with the tag, and our code handles showing it as the 8.0.13 equivalent. As soon as the permissions are changed in 8.0.13 to something like read access for roles only, the old definition is removed and the definition of roles for that tag that the system inherited from pre-8.0.13 is erased and the 8.0.13 definition is added. This looks something like the following:

    "readPermissions": {
        "securityLevels": [
                "children": [
                        "children": [],
                        "name": "Roles"
                "name": "Authenticated"
        "type": "AnyOf"

Since the previous definition of the roles have been erased, the only source of truth for known roles Gateway has is the Security Levels screen. I know it is a bit convoluted, so let me know if you still have questions.

Ok, that make sense, but if we wan’t to keep the legacy users/roles, why the tag permission editor only show the role used in “permissionModel” ?

Other roles have to be listed (checkbox not checked), if we need to change the legacy tag permission and we don’t want to switch to Security Levels…(delete tags, import tags with pre-8.0.13 tags permission changed is the only way ?)

Before switching to Security Levels for tags permissions,
in ou case we have too some scripts reading the AccessRights and PermissionModel properties of the tags, is it still possible with 8.0.13 ?

The Tag editor will show a union of the following:

  1. Existing pre-8.0.13 security permissions
  2. Security Levels defined on the Config > Security > Security Levels page

While #2 you have to manually add, you will be able to see the Roles on all Tags once you add the roles to that screen. It will be up to the Ignition Admin to manually add additional roles on the Security Levels screen when you add them to the DB though.

Could you elaborate on your use case where you would be reading the AccessRights and PermissionModel within scripts? I am trying to understand why that would be needed.


We build custom contextual menu for some tags command. Item of the menu depend of tags permission. Item are disabled if tag is not writable by the current user.

can you confirm we have to set the Genral Idenity Provider to use the IdP created for the UserSource ?

While it is optimal that a Identity Provider is set if you are working on a Perspective project, if you are only using Vision then it shouldn’t be necessary. By defining roles on the Security Levels screen, you are saying you trust that role in any of your User Sources or IdPs and the project should inherit that.