Skip to main content
1-Visitor
June 6, 2017
Solved

System user visibility requirements

  • June 6, 2017
  • 2 replies
  • 3821 views

I'm missing something simple here but for the life of me cannot work out what I'm doing wrong.

I have a wrapper service (GetChildConnectionsWrapped) defined on a thing that wraps the GetChildConnections service of a Organization thing.

My system user has visibility of the Organization thing, my executing user does not.

The GetChildConnections service has execute permission for the system user but not the executing user.

The GetChildConnectionsWrapped service has execute permissions for the executing user but not the system user.

When I call the wrapper service from a mashup I get the following error message in my script log....

"User does not have visibility permission for <organization>."

If I give visibility permission to the organization for the executing user then everything works.  However, from my understanding of how wrapped services are executed this should not be required.

What have I missed?

Thanks

Wayne

    Best answer by posipova

    If I'm understanding your scenario correctly, here's a diagram:

    While your regular user does not need any permissions on the Service B and switching to the system user context; it still requires *visibility* of the parent entity being accessed/referred, in this case your Organization. This is how it's designed/per our architecture. Similarly in my example above, if you have a Template with three derived things and a service A that calls service B through a system user to list all derived things from that template, while no other permissions are required for the regular user, it still needs to have visibility on the Template to know such an entity exists.

    2 replies

    5-Regular Member
    June 6, 2017

    Hi Wayne Love​,

    Does GetChildConnectionsWrapped have any reference of the organization in it?

    20-Turquoise
    June 6, 2017

    Yes, your regular user would need just visibility permission to the organization - otherwise, it wouldn't  "know it exists" to put it in a simple way.

    Please refer to this The use of System User

    waynelove1-VisitorAuthor
    1-Visitor
    June 6, 2017

    Ankit Gupta - I'm not sure what you are asking, GetChildConnectionsWrapped is a simple function that takes 2 parameters Tenant & Node and then makes the following service call...

    Organizations[Tenant].GetChildConnections({ name : Node })

    By doing it this way the regular user does not need to directly access the Organizations collection or object and therefore does not need visibility.

    Polina Osipova - Why does the regular user need visibility of the Organization?  At the point that the service on the Organization thing is being called the context of the execution has switched from the regular user to the system user.  It seems that the system user is being constrained by the regular user's visibility permissions which sort of defeats the purpose of wrapping a service call.

    Or am I missing something here....?

    Thanks both for responding.

    Wayne

    20-Turquoise
    June 7, 2017

    It's same as it would be with any other service on any other type of collection. You wouldn't need runtime or design time permission, but you would need visibility on Template for the user to see such an entity exists. Similarly, with an organization.

    The use of System User

    waynelove1-VisitorAuthor
    1-Visitor
    June 7, 2017

    Thanks.  I understand where I am going wrong.  However, I am still no closer to a solution.

    I've modified my implementation to implement the following services...

    ServiceA - Has execute permissions for the user

    ServiceB (formally GetChildConnectionsWrapped) - Has execute permissions for the system user only.

    GetChildConnectionsWrapped - Has execute permissions for the system user only.

    The system user has visibility of the Organization called "OrgName".

    The process flow is that the user opens a mashup that calls ServiceA.  At this point of time we are executing with the users permissions and visibility.

    Service A calls Service B. At this point we change security context and continue to execute as the system user if I understand things directly.

    Service B (as the system user) then calls Organizations["OrgName"].GetChildConnections({ name:Node }).

    Service B will fail at this point unless the regular user has visibility of the Organization.  Given that we have switched context to the system user when we called Service B, why is this the case?  Why are the permissions & visibility settings for the system user not being used?

    Thanks

    Wayne