Populate Group Privileges

Overview

The Group Privilege Populate process is launched from the Admin overview page by clicking the Populate Group Privileges link.

The process fills in the 'blanks' in the Group Table Privilege and Group Column Privilege tables for all existing security Groups. It will not overwrite anything and it is safe to run repeatedly.

The lower half of the window is used to determine how the permission tables will be populated. Each drop down contains three options:

  • Grant— this means that the group does have the privilege in question.
  • Undefined — this means that the group hasn't been given the privilege, but neither has it been denied to the group. If a user is in one group with an 'undefined' privilege and another with a 'grant' privilege, then the user will have the privilege.
  • Deny — this means that the group does not have the privilege. If a user is in one group with a 'deny' privilege and another with a 'grant' privilege, then the user will NOT have the privilege.

Here is a more specific explanation of what a choice of undefined or deny will mean for each privilege:

  • Table Select — user will be unable to select records from that table and the form will not be able to load.
  • Table Insert — the Save button will be disabled on a form when adding a new record.
  • Table Update — the Save button will be disabled on a form when editing an existing record.
  • Table Delete — the Delete button will be disabled on a form when editing an existing record.
  • Column Select — the field will not be displayed on forms.
  • Column Update — if Select permission is granted, then the field will be displayed but it will be read-only and therefore the user will not be able to update the field.

Examples

Suppose a particular user is in five different security groups. Here are some scenarios looking at a particular table for a particular operation based on Group Table Privileges:

  • If all five groups allow Grant, then the user may do the operation.
  • If four groups allow Grant, and one is Undefined, then the user may do the operation.
  • If four groups allow Grant, and one is Deny, then the user may not do the operation because even a single Deny overrides any Grant.
  • If all five groups are Undefined, then the user may not do the operation because there must be at least one Grant (and no Denies).

Here is another way to look at it: imagine that you need at least one point in order to perform an operation. You get one point for every Group you belong to that has Grant and zero points for Undefined. So as long as you have just one Grant, you can perform the operation. But, you get negative 1,000 points for any Deny. So a single Deny will wipe out all your Grants.

Moving onto Group Column Privileges, here are some scenarios:

  • Supposing that a user does have Grant on a particular table based on the examples above, if a user is in any Group that has a Deny on a particular column, then that user cannot perform that operation on that Column, even if the user belongs to other Groups that do Grant the operation on that Column.
  • Supposing that a user does have Grant on a particular table based on the examples above, but all the Group Column Privileges are set to Undefined. In this case they user will NOT be able to perform the operation on any columns because they need at least one Grant on Columns (and no Denies).