User Permissions

User Permissions

OrderFlow provides a sophisticated access control environment to ensure that the right users get authorised just to the areas on the system for which they require access.

This access control applies both to functional areas on the system (allowing most users only access to a some of the available screens and menus) as well as to data and operations affecting that data.

The main entities associated with user permissions in OrderFlow are shown below.

Note that there is a 'soft' relationship between roles on the one side and menus or operation definitions on the other.

Users

Access to OrderFlow screens is provided only to users properly authenticated by supplying a password.

A user is set up on the system with various items of information, include:

• user name
• password
• email address
• default URI (to which the user navigates by default after logging in)

User access can be optionally restricted to particular sites, channels and/or organisations.

Channel and organisation restrictions are particularly useful for 3PL (Third Party Logistics) environments where the 3PL clients are represented on the system using organisations. An obvious requirement here is that individual customers of the 3PL organisation do not get to see each others' data.

Site access restrictions are useful especially for restricting the access of operational staff to the sites in which they are based.

In addition, a user can be defined as a read-only user. Read-only users have access only to particular screens which have been tagged as read-only enabled.

Roles

At the heart of the access control is are roles, used to identify logical groupings of functionality. Roles are used in conjunction to menus to make screens available to certain users.

Roles can be applied to restrict access in a number of places on the system:

• to menus to ensure that menus and associated URIs are hidden from unauthorised users.
• to order, shipment and order line operations. For example, operations to escalate the priority of particular shipments or to split shipments may be restricted to users with the appropriate roles.
• to dashboard views, controlling the visibility of particular dashboard report fragments.
• to particular reports. For reports which are considered role-restricted, only users with the qualifying role are able to view or run the report.

Menus

Menus have an obvious importance on the system in providing the structure within which areas of the application can be accessed.

Every menu is associated with a URI on the system, so that when users clicks on menu entries, the application navigates to the screen determined using the menu's URI.

For example, the menu Despatch -> Shipments -> Search, itself represented internally by the identifier despatch/shipment/searchnew, is mapped to the URI /despatch/shipment/searchnew.htm.

This screen of course allows you to search shipments.

In addition, every URI is associated with a menu entry. This is important, because role permissions are associated with menus, not URIs directly. (to associate roles with URIs directly would be difficult for a user without detailed knowledge of the application internals).

In other words, it is by assigning permissions to menus that access to particular URIs on the system is given, allowing for fine-grained control of access to functionality on the system.

To understand how this works, let's consider an example. When you select an individual shipment, you are taken to a URI such as /despatch/shipment/detail.htm.

However, as there is no menu entry which points specifically to this URI, the question arises as to how access control can be applied in this case. The answer is that there are a number of mechanisms by which a URI is associated with an individual menu.

The mechanisms for determining the relationship between menu URI are:

URI Menu Resolution

Name	Usage
menu_table	The relationship between the menu and the URI are explicitly declared.
annotation	The relationship is inferred from the menu of another URI.
convention	The relationship is inferred from the corresponding structure of the menu and the URI.

More detail on each of these follows.

• menu_table: "This covers the case where there is a direct association between the menu and the URI, as in the case with Despatch -> Shipments -> Search and /despatch/shipment/searchnew.htm."
• annotation: "individual URIs in the code are tagged with an associated @MenuUri annotation which is used determine the associated menu.

For example, the URIs /despatch/shipment/search.htm and /despatch/shipment/searchreset.htm both have in the code base @MenuUri annotations pointing to /despatch/shipment/searchnew.htm. This allows these URIs to 'inherit' the permissions associated with the /despatch/shipment/searchnew.htm URI. * convention: if there is neither an entry in the menu table for the current URI, nor an @MenuUri annotation, the system attempts work out the appropriate menu by convention.

For example, the URI /despatch/shipment/detail.htm is associated with neither a specific menu table entry, nor does it have a @MenuUril annotation. In this case, the system attempts to find an appropriate menu by convention.

However, as menus are hierarchical, the matched menu is despatch/shipment; this is the menu with the longest identifier which matches the first part of the URI /despatch/shipment/detail.htm (the leading slash is ignored).