The Logic and Consistency of the Functioning of View Permissions should be Improved

Current Situation

The Functions regulated by Permissions are not Consistent across all Objects:

• The effect(s) of granting limited YADE Permissions to a Role is unnecessarily different to the effects of granting Roles with limited Permissions for JobScheduler Objects with 'View-level' Menu links in the JOC Cockpit interface. Such Objects include Jobs and Orders.
• For example:
  • A User Account with the following Permissions will not be shown the "top-level" View Order Menu link and is therefore unable to access any functions that are normally available within the Order View:

    sos:products:joc_cockpit:order
    -sos:products:joc_cockpit:order:view:status
    

• In contrast:
  • A User Account with the following Permissions will be shown the "top-level" View File Transfers Menu link and will be able to open the view but the list will be empty other than the column headers:

    sos:products:yade:order
    -sos:products:yade:order:view:status
    

  • In addition, the Account will be shown the File Transfer Overview and File Transfer Summary Dashboard widgets but they will both be empty apart from the "No Information Available" message.

The functions of the *:view Permissions for the majority of JobScheduler Objects is not logical:

• In the Permissions Tree, the status, config & execute permissions are all children of the :view Permissions and therefore users could expect a similar function from all three Permissions. However, these three Permissions currently function at completely different levels: the :view:status Permission regulates overall access to a view and the :view:config and :view:execute Permissions regulate access to functions within a view.

Desired Behaviour

The following changes are suggested in order to prevent further inconsistencies in the implementation of Permissions and to simplify their application by users: The function of the :view and the :view:status Permissions for all Objects & for YADE File Transfer is put on a more logical basis than is currently the case:

• *:view Permissions should allow display of:
  • the "View-level" Menu links and therefore overall access to the view and the object functions themselves.
  • Dashboard Widgets / Widget information: when an Account does not have Permission to see the Information contained in a Widget then either:
    • the complete Widget will not be shown or
    • the Widget will be shown with the "No Information Available" message
• *:view:status Permissions regulates display of:
  • current status information within a view
• :view:config and :view:execute Permissions retain their current functions

Maintainer Notes

• This issue is dismissed as the permissions are oriented towards both users of the GUI and users of the API.
  • For API users it is fairly possible to be granted permissions to remove an object, e.g. an order, but not to own permissions to view an object.
  • For GUI users it certainly makes no sense to deny e.g. the order view permission but to grant the delete permission as in the GUI an object has to be visible in order to enable a delete operation.
• JOC Cockpit administrators should carefully look at permissions to be granted and should consider use of permissions for GUI users and for API users.