Other Functionality

Designer Express Setup

Default Metadata

When updating the ERP Profile, at the end of the Profile Wizard you will see a task called “Import Hubble Default Metadata” being performed. This step can take a while to complete the first time it is being done.

Once you go through the Profile Wizard, you will see an additional folder called “Common” that displays along with the folders for each ERP Version Specific profile defined if they were defined in a version prior to 2012.1. This “Common” folder is referred to as the Customer Common Library:

The Customer Common Folder will be populated for any customer-specific table definitions, for example, custom ERP System Tables.

The final step in the Profile Wizard created, behind the scenes, a folder for the Hubble Default Library that is not exposed in the repository. This folder is the one that stores all the Hubble Default Metadata to be used in DX when creating reports.

Designer Dictionary in Designer Express

This is where all the Default Amounts and Quantities (Hubble Default Metadata) are defined and stored. This file is used at the end of the Profile Wizard to bring in behind the scenes all the Hubble Default

Metadata. It is important to note that the HubbleDefaults.rdf file is not imported if the metadata in the repository matches the metadata in the rdf. Hubble checks the date the file was created, the date the file was modified, the file size and the checksum of the file to determine if the file has changed.

Note that the Hubble Defaults folder does not display in Administrator, however it is there behind the scenes once you have gone through the Profile Wizard.

Minimizing Tables in Template Designer

You can minimize the tables used in Template Designer so that only the table names appear. This is necessary when using many tables in a report so you can display all the tables on one screen within Template Designer.

After you have added a table from within Template Designer, double-click on the table header to minimize the table.

The below example shows all tables being minimized when each table header has been clicked on:

Module Security

Overview

Module Security was created to allow greater control of what a user can see when using the Payroll, Timesheet and Human Resources modules. This feature works in conjunction with the standard security settings provided with JD Edwards products, e.g. Business Unit Security.

The feature is available within Administrator and is attached directly to a profile. By defining security conditions based on fields and values, you can choose what a user can view and ultimately report on. These security conditions can be made against a specific User ID, against a specified group or even a combination of the two.

Brief examples of how the feature can be used include allowing administrative staff to see the contact details of staff while hiding their salary, or allowing the head of a department to only see the employees for whom he is responsible.

It is important to remember that users and groups will inherit permissions from their respective parent groups. In the situation of large numbers of users or groups, we recommend grouping users together with security levels in mind in order to reduce the overall maintenance. When similar level users are in the same group, you can apply the same security settings for the entire group instead of assigning them to individual users.

The application of Module Security only comes into effect when creating/opening a new inquiry. If the user whose security settings you are changing is already in an inquiry which you would like to restrict, the security will not be enforced. The user would need to close out of the inquiry and then reopen it in order for the security to take effect.

Setting Up Module Security

In order to be able to set up Module Security, you must have the following set in Administrator:

1. You must have Read and Update Permissions for the profile on which you will be setting Module Security.
2. You must have the Module Security Capability (accessible in the Basic Capabilities > Administration tab > Module Security feature).

Setting up Module Security for a Profile

To set up module security for a profile, follow the steps below:

1. Log into your repository if you are not logged in already.
2. Expand Data Sources in the navigation tree on the left panel and select Profiles.
3. In the right panel, right-click on the required Profile and select Module Security.
4. Within the Module Security dialog, set Grant or Deny Permissions to specific users on specific modules:
   1. Select the specific Module using the drop-down menu.
   2. At the level you wish to set security, highlight that user or group in the left panel
   3. Click New.
   4. From the drop-down list, select the field to be restricted.
   5. Specify the specific field values to either grant or deny to the selected user(s). (Multiple selections are separated with a comma and ranges are supported using the colon character. Only a single definition can be made per user for any one field.)
   6. Using the radio button, select either Granted or Denied.
   7. Click OK.
   8. Click OK again in the main Module Security dialog.

Module Security Examples

While the below examples are very specific in how Module Security can be configured to restrict or allow access to certain values, the logic can be applied to any allowable field.

Example 1: Denying Specific Values

In the first example, we are going to restrict a user from seeing specific employees’ payroll details using the Denied mode. The result of using Module Security will be shown by comparing the results before and after changing the security.

Below is a basic Payroll History inquiry prior to setting security. The filter selections, hidden to maximize the display result set, are left blank to return all results. Additionally all non-essential columns were removed.

In Administrator, we will apply security to the Administrator Group as shown below. This will affect all users within this group. We selected the Payroll Module at the top of the dialog, then selected the

Administrator group. In the new security entry, we denied access to the AN8 field for values 6002, 6078 and 6001.

After clicking OK, you see the security entry for the Administrator group:

After closing and re-opening the inquiry, you see that the inquiry results no longer contain the Employee Numbers 6002, 6078 and 6001. This is because we denied the user visibility to these employees by using the Deny option to those specific field values:

Example 2: Granting specific values

In the next example we can see the result of using the Granted mode against specific criteria. In Administrator, change your previously entered security condition and click Edit. Change the security entry to Granted, as shown below:

Click OK to see the changes referenced in the dialog:

After closing and re-opening the inquiry, you see that the results have now been amended so we can see only the field values that were specified using the Granted option:

Example 3: Suppress label columns

Some fields can be set to suppress the display of sensitive information from a user. In this example we will suppress the display of Hourly Rate, a label column found with the Payroll History Template. Before any security is applied, the inquiry looks like this:

In Administrator, add a new security entry on the Payroll – PHRT field. The PHRT field cannot be specified as in the previous examples, so the Values field is grayed out to prevent data entry. Instead, the Values section of the dialog is populated with a ‘*’ (a select all) to indicate that all data returned will be affected.

For this example we will apply a Denied mode, as shown below:

Once the Module Security is set, the associated user will see that the Hourly Rate (PHRT) is now suppressed as shown below:

Example 4: Suppressing value columns

Module Security also provides a way of suppressing the display of value columns. As with previous examples, you need to select the correct field from the drop-down list within the Module Security dialog. (The below example illustrates one value column being affected. However by entering an asterisk (*) in the value section of the Add Module Security Entry dialog, you can select all value columns, allowing you to grant or deny all values in all columns.) It is important to know that if you suppress all the value columns in your inquiry, no data will be returned in the result set. To see records, you must enable the Zero Balances feature in Hubble.

In this example, we are going to restrict the Administrator group from viewing the Gross Pay value column (GPA). In the Add Module Security Entry dialog:

• Field: Payroll – F0618, F06116 Measures. [The inquiry is based off the Payroll History Template, which contains data from the Employment Transaction History (F0618) and Employee Transaction Detail File (F06116) tables. This is why we have chosen the field that is in both the F0618 and F06116 tables.]
• Values: GPA (Again, we only are suppressing values in this column, so this is the only one that needs to be specified here. To select all columns, you would enter an asterisk (*).
• Mode: Denied (setting used for suppressing data in the specified value column).

  

As a result of the Module Security setting, the Gross Pay column, although specified in the filter, will no longer be displayed to users in the Administrator Group as shown below:

Example 5: Combinations of security

In the previous examples we have used single selections to Grant or Deny access to certain values; however it is also possible to use multiple selections.

The following example demonstrates how you may wish to grant access to a user for specific employees, but deny the user the ability to view payroll information such as Hourly Rate.

For the first condition, we will repeat the condition established in the 2nd example, granting specific values:

For the second condition, we will repeat the condition established in the 3rd example, suppressing label columns:

The Module Security dialog will then display both conditions:

As shown below, the user has been limited to the three employee’s records via Granted mode and the hourly rate has been affected by the Denied mode.

The combination of security conditions allows for detailed and complicated authorities to be handled in a reasonably straightforward manner.

Inheritance and Priority

Module Security is designed to work with large hierarchical organizational structures by allowing users and groups to inherit security conditions from their respective parent groups. The underlying security engine will combine all the levels for one particular Field. However a condition established with a Deny mode will take precedence over a Granted mode.

Security Inheritance on a two-level system

The table below shows how security condition priorities would be applied when security is set at the Group and User levels.

Security Inheritance on a three-level system

The table below shows examples of how priorities would be applied when security is set on a three level system:

Everyone Level

Group Level

User Level