Page History

...

• Scope
  • JOC Cockpit Permissions are assigned for operations in JOC Cockpit, for example to manage calendars and the daily plan etc.
  • Controller Permissions are assigned for operations on scheduling objects per Controller, for example to deploy workflows, to add orders etc.
    • If more than one Controller is connected to JOC Cockpit then a user account can be assigned a role that for example allows deployment to one Controller but not to other Controllers.
    • Controller permissions can be specified as a default for any Controllers and they can be specified on a per Controller basis.
• Permission Tree
  • Permissions can be considered a tree that offers a hierarchy of branches.
  • Granting or denying permissions at a higher level inherits the permission assignment recursively to deeper levels of the tree.
• Permission StatesStatus
  • Permissions can take one of three statesstatus values, being unassigned, granted or denied.
  • Unassigned permissions do not suggest any assumption if the permission is granted or denied.
  • Granted permissions are considered additive within limits as they can be overruled by denied permissions.
  • Denied permissions are considered subtractive without limits as they cannot be overruled by granted permissions.
• Permission Sets
  • Roles are assigned permissions. A user account can accumulate a number of roles, therefore permissions are merged to a permission set by the following rules.
    • JOC Cockpit Permissions
      • Unassigned permissions are ignored.
      • Granted permissions work across any roles unless merged with a denied permission from a role.
      • Denied permissions work across any roles and cannot be overruled by granted permissions from any role.
    • Controller Permissions
      
      • Default Controller
        • Unassigned permissions are ignored.
        • Granted permissions overrule unassigned permissions from any roles and Controllers.
        • Granted permission can be overruled from any roles, they can be
          • denied by a permission of the Default Controller specified by some other role,
          • denied by a permission for a Specific Controller.
        • Denied permissions 
      • Specific Controller
        • Unassigned permissions are ignored, instead the permissions of the Default Controller are applied.
        • Granted permissions work across any roles unless denied by a permission from a role for the given Controller.
        • Denied permissions work without limits across any roles for the given Controller.

...

Views are available for roles and and permissions . including the Graphical Permissions View and Textual Permission Views are availablethe Textual Permissions View.

Roles View

From the list of Identity Services user users can click the name of an Identity Service:

...

For each role a default link is available to navigate to the Graphical Permissions View. 

Additional links can be added by use of the Add Controller button. Such links are used to manage permissions that are specific to Assign Permissions for a Specific Controller.

Anchor
graphical_permissions_view graphical_permissions_view

Graphical Permissions View

...

• Explanation:
  
  •  Navigation
    • The Expand All and Collapse All buttons open and close any child branches.
    • The Expand Active and Collapse Active buttons open and close child branches with granted or denied permissions.
    • The + and - icons at the right edge of each permission icon open and close child branches.
  • States Status and Colors
    • Permissions show the following background colors to indicate their statethe status:
      • White: Permission is not assigned, i.e. is not granted and is not denied.
      • Dark Blue: Permission is granted and the grant is inherited to child permissions recursively.
      • Light Blue: Permission is inherited from a granted parent permission.
      • Dark Grey: Permission is denied and the denial is inherited to child permissions recursively..
      • Light Grey: Permission is inherited from a denied parent permission.
    • Granting Permissions
      • Clicking the middle of an unassigned (white) permission grants the permission (dark blue).
      • Clicking the middle of a granted permission revokes the grant and puts the permission to the unassigned state status (white).
    • Denying Permissions
      • The + icon inside a permission icon denies the permission (dark grey) recursively for child permissions that are located deeper in the permissions tree (light grey).
      • A denied permission shows the - icon, clicking this icon revokes the denial and puts the permission to the unassigned statestatus.
  • Undo/Redo
    • Changes to the permissions tree are stored to the JS7 database- Database.
    • The Undo button allows the last 10 changes to be undone stepwise.
      • Any changes held in the Undo button will be deleted when the user leaves the Permissions sub-view.
    • The Redo button changes the permissions tree back to its initial state when the Permissions sub-view is displayed.
      • The state status held with the Redo button is deleted when a user leaves the Permissions sub-view.

...

The view acts as an alternative to the Graphical Permissions View and displays permissions from a list of textual entries.

...

• Explanation:
  • Individual permissions can be modified and can be removed from a role using the pencil  icon and X icons icon that are faded in when the user's mouse is moved over a permission.
  • The Edit function allows the permission to be made subtractive, i.e. for permission permissions granted at a higher level to be removedthe selected permission and any child permissions are denied.
  • The folder part of the view is used to restrict the role to access particular folders only - this includes that any scheduling objects such as workflows are visible from the assigned folder only.

...

Consider a user account being assigned a demo-role holding an application_manager role holding the following permission:

...

This permission does not allow the demo-role to application_manager role to perform any modifying operations on Controllers. Instead, such permissions are granted individually by using:

...

The following permissions allow the  demo-roleapplication_manager role to view and to restart a Controller, but not to terminate a Controller and not to switch-over between Controller instances:

...

Alternatively, users might prefer to grant the role a higher level of permissions and then to remove deny one or more specific permissions. This approach is used for example with the following permission set:

...

The sos:products:controller permission is an overall Controller permission including permissions to view, to restart and to terminate a Controller. The -sos:products:controller:switch_over permission is removed from the demo-roledenied.

Minimum Permission Assignment

User accounts have to be assigned a role with the following minimum permission set in order to be able to login to JOC Cockpit:

...

Permissions are added by clicking the respective permission icon in the Graphical Permissions View:

Unassigned

...

Permissions

The white background color indicates that the a permission is not assigned, i.e. is not granted and it is not denied.

Clicking the middle of an unassigned (white) permission grants the permission (dark blue).

Granted

...

Permissions

A dark blue background color indicates that the a permission is granted and that the grant is inherited to child permissions recursively.

Clicking the middle of a granted permission revokes the grant and puts the permission to the unassigned state status (white).

Denied

...

Permissions

The dark grey background color indicates that the a permission is denied and that the denial is inherited to child permissions recursively..

...

By default user accounts are granted permissions for any Controllers connected to registered with JOC Cockpit. Permissions that should be applicable to a Specific Controller only can be added to a role. This can be achieved from the Roles view:

...

With the testsuite Controller being selected the role displays two links for default Controller and for the testsuite Controllers like this:

...

In this configuration, the application_manager role is not yet granted any permissions specific to the Controller ID testsuite. A minimum of one permission has to be added:

• default permissionsDefault Permissions:
  • sos:products:controller:view
• Permissions for a Specific Controller such as testsuite:
  • sos:products:controller:agents:view

...

Inventory folders are added by use of the Add Folder button visible in the upper right corner of the Graphical Permissions View and of the Textual Permissions View of the respective role like this :

...

• Folders are selected from a tree view widget that is opened by clicking the folder input field.
• The Recursive option grants access to any sub-folders of the selected inventory folder.

...