NOTE:  The dynamic menu files discussed throughout this solution article have been included as attachments.  Before spending a significant amount of time copying and pasting information from the sample code provided, it may be easier to simply download the menu XML files and update them as needed to meet your requirements.

Scenario

"Full Press Printing has reported issues with orders disappearing from their system and items being batched to press multiple times, resulting in duplicates on the production floor.  Management has determined that the issues were caused by a small number of new employees that have not yet been fully training in using the Infinity software.  The management team at FPP would like to implement some form of access control that would allow them to restrict certain features and functionality to those employees not yet fully trained.  At the same time, they do not want to prevent these employees from using the UI while they continue to learn the system, but instead, simply control which actions they can perform."

Solution overview

To meet the requirements of this solution, two things will need to occur.

1. The customer will need to decide on and implement a set of AD groups that will map well to collections of abilities available within the UI
2. A set of roles will need to be defined by the customer that addresses their needs
3. All dynamic menu configurations will need to be updated to include the appropriate value for the action's authType attribute
4. The access control configuration file will need to be updated to reflect the newly created authentication types

Prerequisites

Before starting the access control configuration process, all AD groups should be in place, with each of the users added to their appropriate group.  A typical AD configuration to meet the needs described in the above scenario might include the follwoing.

• IPS_Admin
• IPS_User
• IPS_Train

IPS_Admin

The IPS_Admin AD group will server two purposes.  First, it will include all individuals deemed administrators of the IPS system and will be used for controlling access to key areas where system configuration files are stored.  Second, it will provide the role that has zero restrictions within the Infinity UI.

IPS_User

The IPS_User AD group will include individuals that should have full access within the UI.  The difference between this group and the IPS_Admin is that these users will not have full control to locations where core system files are stored and managed.

IPS_Train

The IPS_Train AD group will include individuals with limited ability in the user interface.  The specific actions available to these users will be determined by the configuration put in place in the access control file and authentication types defined in the menu configuration files.

High level steps

• Identify and create roles and AD groups
• Map authentication types to roles
• Set each menu action with the appropriate authentication type
• Update the access control file to include a task for each unique authentication type, and add AD groups as required

Identify roles / create AD groups

To meet the needs defined in the customer scenario, three roles will be required.  We will need to create one role for IPS administrators, one for standard IPS users, and a third for IPS trainees.  Each of these roles will map to a group created in  active directory (AD).  This means that the access control file will contain three tasks beyond the three system level tasks included in the file.  System level tasks will be discussed later in the article.

The roles that will be used (aka - authTypes discussed in the next section) will be

• admin
• user
• trainee

Map authentication types to roles

Now that the roles have been defined, we need to specify which role will be applied to each menu action.  Menu actions have an attribute called authType.  The authType attribute is where we will define the role that should be associated with the given action.  For example, we could set all menu actions that result in a delete to have an authType of admin, and set menu actions that simply view order attributes to have no value (remain empty).  When an authType has no value set, that action will be available to all users.

To work out what role should be assigned to each menu action, we will use the chart shown below.

Given the values supplied for AuthType above, we have basically established two possible roles for users.  One which can perform ALL actions within the UI and a second that is basically a view only role. 

The level of access control that has been established here is very basic.  You have the ability to create any level of granularity deemed necessary, up to the point of having each menu action specify its own unique value for the authType attribute.   Then, mapping each of those to a unique task definition within the access control file.  Implementing access control to that level would be nearly impossible to manage and maintain over time, and is strongly discouraged for anyone interested in setting up access control restrictions within their environment.

That said, the implementation above is likely too basic for some production environments, so setting up something with a bit more granularity as shown below may be more appropriate.

Roles/AuthType

Trainee

Reviewer

Batcher

Lead

Admin

For a set of roles such as these, Trainee would like have no access to perform any actions within the UI, Admin would have access to all functions within the UI, and the remaining roles would have the appropriate actions for each defined to suit the needs of your organization.

NOTE:  The menu item actions listed above may not match your environment exactly.  Just update the AuthType for the items contained in your dynamic menu files.  If you believe there is a menu item that you are missing, contact Infinity Digital for assistance.  

A sample from the Products tab menu configuration file is shown below, with each taskAuth attribute set to the user role.

<menus>
  <menu name="">
    <menuitems>

      <menuitem name="Mark Order Highest Priority" hotkey="CTRL-P" taskAuth="user"
        whenAuthFails="disable" icon="exclamation.png"
        tooltip="Marks this order as highest priority (100)."
        disableWhenAttrIsNull=""
        actionClass="com.infdig.tools.ui.idforders.menu.IDFProductHighestPriorityAction"/>

      <menuitem name="Reprocess at Order Analyze" hotkey="CTRL-R" taskAuth="user"
        whenAuthFails="disable" icon="refresh.png"
        tooltip="Reprocess selected products at the order analyze step."
        disableWhenAttrIsNull="Order Analyze queue"
        actionClass="com.infdig.tools.ui.idforders.menu.IDFProductReprocessAtOrderAnalyzeAction"/>

      <menuitem name="Reprocess at Order Prebatch" hotkey="" taskAuth="reprocessorder"
        whenAuthFails="disable" icon="refresh.png"
        tooltip="Reprocess selected products at the order prebatch step."
        disableWhenAttrIsNull="Order Prebatch queue"
        actionClass="com.infdig.tools.ui.idforders.menu.IDFProductReprocessAtOrderPrebatchAction"/>

      <menuitem name="Reprocess at Order Sort" hotkey="CTRL-S" taskAuth="user"
        whenAuthFails="disable" icon="refresh.png"
        tooltip="Reprocess selected products at the order sort step."
        disableWhenAttrIsNull="Order Sort queue"
        actionClass="com.infdig.tools.ui.idforders.menu.IDFProductReprocessAtOrderSortAction"/>

Updating the accesscontrol.xml file

Now that the main XML files for the UI have been updated, it's time to update the accesscontrol.xml file to include all system level and user defined tasks with the appropriate AD groups defined in each.  A starter / basic accesscontrol.xml file is shown below.

<accesscontrol>
    <tasks>
    <task name="allow_invalid_divert">
            <group>IPS_Admin</group>
            <group>IPS_User</group>
        </task>
    </tasks>
</accesscontrol>

NOTE:  Your implementation of the Infinity software may contain other system level tasks.

To build out the accesscontrol.xml file to meet the requirements of the solution we have defined, we need to include 1 additional task sections.  For this scenario, we only need to include a new task section for the user role, which will include the domain groups IPS_Admin and IPS_User.  The reason for this is that we only have one other role which will inherit the abilities of all actions that have not been defined with a specific value for authType.  In a situation where we had several roles, each with a specific set of authTypes mapped to it, a task section within the accesscontrol.xml file would be created for each role defined.  Creating the user task section in our accesscontrol.xml file results in the XML shown below.

<accesscontrol>
    <tasks>
    <task name="user">
            <group>IPS_Admin</group>
            <group>IPS_User</group>
        </task>
    <task name="allow_invalid_divert">
            <group>IPS_Admin</group>
            <group>IPS_User</group>
        </task>
    </tasks>
</accesscontrol>

Because our trainees do not belong to either of the groups defined above, they will have no access to any menu actions which have been associated to the user or allow_invalid_divert tasks.  However, all menu items that do not have a value specified for authTask will be available for the trainees to use as required.

Provided the domain groups / memberships have been correctly defined and align with the roles and tasks defined, the menu items for the products tab in your environment should look similar to the following when logged in as a trainee.

When logged in as a member of the IPS_Admin or IPS_User group, all menu items will be available, as shown below.

Need additional help?

If you get stuck or have further questions on something we may not have covered, don't hesitate to contact our support team.  You can reach us using any of the following options.

	(800) 625-0599
	help@infdig.com
	http://support.infdig.com