Module Category (MCA)

Module Category defines a new menu item which opens a page with a list of objects of certain type. It is usually used by Accelerators to build new ad hoc features (coupled with Models and Custom Forms).

The standard way to use Module Category is to associate them with User Groups and most often Business Roles. See below for some details.

Configuration is at Administration › Configuration › System Configuration › Module Categories.

Use Case Example

You have a Model Class, whose Models would normally be listed under Optimization › Models, but because they are strongly related to your functionality configured in another application module (e.g., Actionable Insights), you would like to provide easy access to users by providing a special menu item under your module, which would display a list of objects you need.

You would then create a Module Category for this new menu item, associate the Model Class to this new Module Category, associate a User Group to this Module Category, create a Business Role providing this User Group as well as the required Role and finally add users that can access this new menu to the Business Role.

Fields

• uniqueName* (String) – Name of this category. Must be unique within the partition.

• module (Application Module) – Under which module menu this menu item will appear.

• label (String) – Label of the menu item, as displayed to the end user.

• translations (Strings) – Label translations for multiple languages. They can be defined in singular and plural forms. The singular is used for button labels like Create New or Save. The plural is used in menu items, label/title of the list page and in breadcrumb navigation. You must enter at least the singular for the default locale (null value in the Locale column).

• objectsTypeCode – TypeCode of the objects which will be listed on the list page. Supported types are Model Object (MO) and Custom Form (CFO).

• path (String) – Path to be used in the URL. Can also be used to refer to this menu item from links. Limit the characters used to lower case letters, no spaces, possibly "" and "-". For example, if you define the value as "cfo_mca", and module to _Pricefx Processes, then the URL will contain "/processes/cfo_mca".

• elementsUserGroupViewDetails – Comma separated list of user groups' unique names. Users can view elements in this category but not edit them.

• elementsUserGroupEdit – Comma separated list of user groups' unique names. Users can edit elements in this category but not create/delete them.

• elementsUserGroupManage – Comma separated list of user groups' unique names. Users can create/edit/delete elements in this category.

Associating Elements to a Module Category

Once a Module Category is defined for a given element type (defined by the objectsTypeCode field), any element type (e.g., MC, CFOT) can be associated to that Module Category by setting their moduleCategoryUN field to the unique name of the Module Category.

Any elements of that type will then appear in the MCA instead of their usual place.

Users will be able to create elements of that type only in that MCA.

Access Rights – Roles and User Groups

The prerequisite for a user to have access to any Module Category is to have the corresponding Role(s) to Manage, Edit or View. See the Roles prefixed by MODULECATEGORY_ in User Roles for a complete list.

Effective user access rights for elements inside the Module Category are evaluated from top to bottom:

1. Role

2. Module Category user groups

3. Element Type user groups (where applicable)

   • For Custom Form Type, see Custom Form > Access Entitlement

4. Element user groups (where applicable)

   • For Custom Form, see Custom Form > Access Entitlement

The lower you go, the more restrictive the access rights are, because the effective rights of certain level are an intersection of the level rights with the rights of the upper levels too.

For example, if you have a Module Category page with a list of Custom Forms of certain Custom Form Type, then the access to the particular Custom Form will be driven by intersection of all the rights, i.e. Role, Module Category groups, Custom Form Type groups and also by the groups of Custom Form itself.

In most use cases, the Role and the Module Category user groups will be enough to build a complete functional solution. There is usually no good reason not to specify groups for a Module Category. Without groups specified, the Module Category will be visible to everybody that have the Role(s).