Edit an Existing Role

  1. Go to System > Security > Roles.

  1. Select a role from a list that you wish to customize.
  2. Click the Edit button, the Edit Role page opens, where you can assign the role’s user interface (UI) rights. Use the User Interface Exclusions area to determine which portions of the UI—the tree nodes, pages, and sub-pages—you want users in this role to see and access.
  3. Select which Millennium® pages and tabs to block from a user's interface. The system puts a red x in the associated box.

How it works:

In order for any user in a role to see a child area of the system, they must have access to the parent area. To explain, here are two examples:

If you do not want a role to see or have any access to anything concerning the company’s setup: [company] > Company Maintenance > Company Setup.

To deny the role from access to this major section of the Millennium® interface, you would put a red X next to the Company Setup node in the User Interface Exclusions area.

When you select box, the system automatically puts a red X next to every child node.

If you want a role to be able to see the company’s Calendar page— [company] > Company Maintenance > Company Setup > Calendar tab—but not anything else concerning the company’s setup configuration.

In this scenario, you would not deny access to the parent Company Setup node because the role must access the child Calendar node. Instead, you would put a red X next to every sub-node except the Calendar node.

  1. Click the Save icon to preserve your changes when you're done or to save your work periodically.
Report Security
  1. Click on the Report Security tab. This is where you assign the role’s security settings concerning reports.
  2. Select the box next to the report that you want to hide from the role's user.
  • Hide Bank Information- the system blocks references to transit numbers, account numbers, and the bank’s name.
  • Hide Pay Rate Information - the system blocks rates and amounts that may be used to determine an individual’s pay.
  • Hide SSN - the system masks social security numbers anywhere on the report.

  1. Click the Save icon to preserve your changes.
  2. Click on the Rules tab. This is where you can assign various rules that affect this role to either prevent or allow them to perform certain tasks, view certain screens, and edit certain data.
Rules
  1. Click on the yellow star button, a new rule line appears in the Security Rules table. The subtabs bellow are ready to be used.

  1. Select whether this rule is going to ALLOW or DENY access to particular records, fields, or functions from the drop-down men in the Rule Setup subtab. A role/user that has no security rules is essentially allowed access to almost every object; therefore, in most cases, you would probably select DENY.

  1. Use the objects drop-down list (right-hand side) to select the object in question.

Rules apply to just one object at a time (“one rule, one object”). However, a role or user can have many rules.

There is a type of “shorthand” to the names of the objects that help you identify what to choose. It is based on the first letter of the object name. Some examples are:

  • C = company object (CAchTransfer, CCalendar, etc.)
  • E = employee object (E401k, EPaycheck, etc.)
  • S = system object (SBankAccount, STaxCode, etc.)
  • R = report object (RPhysicalReport, RProperty, etc.)

Replace this text.

  1. Enter a short title for this rule in the Description field.

Note: Always enter a description. It is the easiest way to inform other administrators about the rule’s end result or purpose.

  1. If you select the Final Rule check box, the system will apply this rule to the role or user and then stop—it will not apply any rules listed below this one.

This feature is handy when you are testing how rules interact on a role or user. For more information on testing, see Test Your Security Settings.

  1. Click the Save icon to preserve your changes before moving on to the next tab.
  2. Click on the Conditions tab. Conditions define data access rules and are field-level specific. A rule can have multiple conditions to make the rule more specific.

Note: Conditions must be met before the system applies the rule. If this rule contains multiple conditions, all conditions must be met for the rule to apply.

  1. Click on the yellow star button to add a new condition to the rule, a new line item appears in the table.
  2. Select the Target Object Type from the drop-down menu:
    • Company - the condition will apply to the parent company of the record being secured.
    • Employee - the condition will apply to the parent employee of the record being secured.
    • This - the condition will apply directly to the object being secured.

  1. Select the specific database Field you want the condition to control. Valid entries are the available fields that the Target Object Type contains.
  2. Select the comparison operator you want to use for this condition from the drop-down menu.
  3. Type in a value to which the field is being compared. It does not matter if you enclose the value in single quotes or not.
  4. Select the Type data that is being compared.
  5. Click Save to preserve your settings before moving on to the next tab.
  6. Click on the Record Rights tab, this is where you define the role’s/user’s rights to a record.

  1. Select the User can get a list of objects check box. The instances in which this should not be checked are very rare.

Cases in which you would disable the check box is an advanced topic in which your organization is creating your own interface that overrides Millennium® 3. If you are planning that kind of programming and have questions about this feature, contact Customer Support.

  1. Type in the record filter, it should be in the form of a SQL WHERE clause.

Note: You do not need to include the term WHERE in this field, as you would in a normal SQL statement. The system knows how to interpret the value you enter in the field.

When you use this sub-page for a rule, regardless of the DENY or ALLOW value of the rule, the role/user is allowed access to the results of this record filter when the condition evaluates to TRUE.

For example, you want the rule to be about all active employees; therefore, you enter the following in the text field:

empstatus=’A’

For another example, you want the rule to deal with company information for companies 100, ABC, and no others; therefore, you enter the following in the text field:

co in (‘100’,‘ABC’)

Record filters provide an excellent technique for limiting or restricting roles/users from viewing large amounts of data.

The title of the text field changes, depending on the value of the access drop-down list on the Rule Setup sub-page:

  • For a DENY rule, the title of the field is DENY record filter.
  • For an ALLOW rule, the title is ALLOW record filter.

Likewise, the descriptive text to the right of the text field depends on the value of the access and objects drop-down lists on the Rule Setup sub-page:

  • For a DENY rule, the descriptive text is “<object> objects MUST MATCH this SQL condition to be available.”
  • For an ALLOW rule, the descriptive text is “ALLOW <object> objects matching this SQL condition to be available, regardless of filters in any DENY rules.”
  1. Click Save to preserve your record filter before moving on to the next tab.
  2. Click on the Field Rights tab, this is where you can define the rule's rights to particular fields. Field rights act as field-level security and defines “who can change what.” You can restrict a role or user to read-only access, all access, partial access, or no access.

The wording/functionality depends on your rule access:

  • If this is a DENY rule, you have the option to deny the ability to change data or deny any access at all.
  • If this is an ALLOW rule, your options are to allow read only or allow all access.
  • When no field rights are specified, the software uses the settings on the Function Rights sub-page as the field rights.

  1. Click Save to preserve your settings before moving on to the next tab.
  2. Click on the Function Rights tab, this is where you can define the role’s rights to particular function. sub-page to controls the role’s/user’s overall rights to an object:
  • If this is a DENY rule, you are selecting the functions the role/user cannot perform.
  • If this is an ALLOW rule, you are selecting the functions the user/role can perform.
  • When you leave the check boxes blank, the system assumes all controls are available.

  1. Select whether to ALLOW or DENY executing functions to: Add New, Delete, and Update under this rule.
  2. Click Save to preserve your settings. You may create as many or few rules as you need for your role.

 

Double check all of the settings you have created and adjust as necessary and Save again.