Skip to main content
A
Ascherer1716-Pearl
16-Pearl
January 6, 2026
Question

Instance Permissions Scope

  • January 6, 2026
  • 1 reply
  • 376 views

I observed something strange when working with Run Time Instance permissions on a Thing Shape and wanted to ask if this is expected behavior or a potential bug.  To demonstrate I'll propose a scenario.  I am using ThingWorx 10.0.

Created entities:

  • TestUSR - User for testing access.
  • TestTS1 - Contains property "TS1Prop" and service "TS1Service"
  • TestTS2 - Contains property "TS2Prop" and service "TS2Service"
  • TestTT - Template inheriting GenericThing template. Contains property "TTProp" and service "TTService"
  • TestThing1 - Thing inheriting TestTT template. Contains property "ThingProp" and service "ThingService"
    Ascherer17_3-1767739570948.png

Now I configure permissions on TestTS1 only.  The rest of the entities will not have any permissions configured.

  • Grant 'Property Read' and 'Service Execute' run time instance permissions to TestUSR.  See below.

Ascherer17_2-1767739217572.png

Now I run Access Report for TestThing1 for user TestUSR.  This initially looks fine, but when I dig into the Specific Permissions by clicking the various run time attributes, I'm met with the following checkmarks and X's.

Ascherer17_4-1767739662362.png

It appears that something is granting access to the "generic" Thing properties and services.  NOTE: I'm only showing a sample of specific service permissions below (left) since the list is long, and I also wanted to show the "Test" services' Denials.  

I confirmed that I don't have any Collection permissions active that provide any Grants.  

Ascherer17_6-1767739883802.png  Ascherer17_5-1767739802045.png

Ascherer17_8-1767740105441.png

Next, I removed the 'Property Read' and 'Service Execute' run time instance permissions for TestUSR.

Ascherer17_9-1767740180386.png

Running the access report again gave me the following.  No permissions are shown now.  This suggests that Granting Instance Run Time permissions (property/service) on my Thing Shape granted access to the "generic" properties/services on my Thing.  

Is this an expected behavior?  There are certain "generic" services that I may not want to grant to certain users.  

Ascherer17_10-1767740333034.png

    1 reply

    A
    Ascherer1716-PearlAuthor
    16-Pearl
    January 7, 2026

    I looked at the thing shape permissions screen again and just realized the "overrides" search box DOES provide the list of "generic" Thing Properties/Services/etc. for adding permissions here.  Has this always been the case?  

    I understand that a Thing Shape has no purpose if it's not implemented on a Thing/Template, but shouldn't the "generic" properties/services that are not defined on the immediate Thing Shape still be "out of scope" in regards to permissions?

    Ascherer17_0-1767759061300.png

     

      S
      slangley23-Emerald III
      23-Emerald III
      January 15, 2026

      Hi @Ascherer17 

       

      I think the feature allowing the "overrides" search box to provide a list of "generic" Thing Properties/Services for adding permissions was first introduced in ThingWorx 10.0. 

       

      The following documentation in the Help Center may help to answer some of your questions:

       

      Regards.

       

      --Sharon

       

      A
      Ascherer1716-PearlAuthor
      16-Pearl
      January 16, 2026

      Thanks for the response.  It sounds like it is considered expected behavior.  The effect this imposes on Thing Shape development is that I will have to explicitly grant access to each individual Property and Service that I define on my Shape so as to not mistakenly grant access to the GenericThing properties/services that I wish to restrict (like "Delete" services).

      I can understand the use case for using a Thing Shape as the vehicle for providing a certain list of "generic" attribute (property, service, etc) permissions to a specific group of Things.  However, it seems like it might be more appropriate to set those Run time instance permissions on a common Thing Template (TestTT in my example) that those Things will share since the "generic" attributes, coming from the GenericThing template, WOULD be in scope on the Template.

       

      Terms & ConditionsCookie settingsAccessibility statement