Visibility Rules

The visibility rules which are part of Manager features aim to restrict or give access to specific Manager objects, in terms of viewing or editing them.

These objects are APIs, environments, and custom interceptors.

Visibility options

Although the objects (APIs, environments, custom interceptors) contain specificities regarding visibility (we go through them below), the options and the way they work in general apply to all cases.

There are three visibility options, found on object settings pages: Organization, Groups and Only me. Each of them defines a different access scope for the object at hand:

  • Organization: the object will be visible to all users. This option is set by default when creating any new object.

  • Groups: the object will be visible only to the group selected. When this option is chosen, a field to select a group will be enabled and the selection is required (check the documentation for Sensedia Acces Control to learn more about creating groups).

  • Only me: the object will be visible only to the user who created it.

If you select the options Groups or Only me when you configure the access scope of any object, the Add Users button will be enabled. Clicking it will bring up a window to select individual users who will also have access to the object.

visibility add users button
visibility add users
The Super Admin policy has permission to view and edit all features (and objects) of the Platform, regardless of the visibility option defined for a given object. Read more about access policies here.

You can see below the specificities of visibility rules for each type of object and some details of the inner workings of the Platform that have to do with visibility options.

APIs

Visibility options for APIs are applied in the Context field, on API creation and editing screens.

visibility api

For APIs, visibility rules regard the permission of viewing and editing registered objects.

When the Add Users button is used to give access to individual users (which is enabled when the options Groups or Only me are selected), you can grant permission to either view (Can view) or view and edit (Can edit) the API.

visibility add users api
visibility add users api1

Environments

On the Environments page, visibility rules apply to two different fields of environment creation and editing screens: Environment Deployment Permission and Environment Trace Visibility.

visibility environment

The Environment Deployment Permission field is related to the permission to deploy APIs into an environment. Its visibility options can only restrict a user’s capacity to deploy an API into the environment at hand, not affecting viewing the environment or editing its settings.

The Environment Trace Visibility field allows restricting access to tracing logs regarding calls to APIs deployed into a given environment (see more about tracing here).

Custom interceptors

Visibility rules for custom interceptors are applied into the Visibility field, found in the creation/editing modal window in the case of Java interceptors and on the creation/editing screens of JavaScript interceptors.

visibility js interceptor
visibility java interceptor

The visibility section of Custom Interceptor settings can only be accessed via the main menu (Interceptors page). When the interceptor is edited from inside the Flows section of API settings, visibility rules are not displayed for modification.

When users are added individually to the access scope (which can be done when the Groups or Only me options are selected), they will have permission to edit the interceptor.

Special cases

There are specific cases in which the behaviour regarding visibility rules is worth noting.

  • Only Me permissions: when an object is registered with the Only me option, other users that have access to it (granted optionally via the Add Users button) may edit the visibility option — changing it to Organization, Groups, or adding other individual users to the access scope — but cannot choose the option Only me. This is to prevent other users from taking hold of the object, becoming its owner.

  • Exclusion of a group linked to a visibility rule: if an object has a visibility option of type groups selected, you will not be able to delete the associated group. You need to change visibility option first.

  • Exclusion of users who own an object: to delete a user who owns an object, you must first remove such ownership. To do this, associate the object with a different user.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]