Permissions control the pages and content users may access. The framework utilizes rules by URL or function to enforce read, read/write, or no access. These rules are organized into permission levels, which can then be assigned to specific roles or users.

Core Concepts

Setup

Permission setup is currently restricted to IWS staff.

Unique URLs

Each BriteCore page has a unique URL.

Agent vs. Administrative Portals

Restrictions in the Agent Portal begin with agent/.

Restrictions in the Administrative Portal begin with britecore/.

Assume Permission Is Granted

By default, a user is granted access to all of BriteCore. Adding restrictions limits a user's access.

Type Ahead

As you begin to type a rule, a list of available URLs and functions appears.

Restrictions

By URL

Users can be restricted from webpages via URLs. For example, restrict a user from the Claims module via britecore/claims.

Of Frontend Functions

Users can be restricted from functions, which appear as camelCased verbs. For example, restrict an agent from submitting an application via agent/policies/submitQuote.

Of Backend Functions

Functions can be restricted server-side.

Of UI Elements

Users can be restricted from specific buttons.

Application of Restrictions

Restrictions apply to the far right part of the rule expression. A rule of britecore/claims/accounting means the user is only restricted from the Accounting tab of the Claims module; he/she can still access BriteCore and the Claims module.

Defaults

Roles

Each BriteCore site is loaded with the roles of agent, agency, agency group, claims adjuster, employee, and underwriter to which a default permission can be assigned.

No Permissions

Within the Contacts module, any contact with login rights but without an assigned permission level will be assigned the appropriate Role Permission.

Locking

When a permission rule is locked, it cannot be deleted by anyone other than IWS staff.

Updating A User's Permissions

If a user's permissions are updated, that user must log out of, then back into, BriteCore for the new permissions to take effect.


BriteCore Setup

Permission setup is currently restricted to IWS staff.

Settings > System Wide > Permissions

Options

Individual Users Can Only Edit / Delete Their Own Notes

Check this setting.

Permission levels

  1. Click +
  2. Click in the box to name the rule
  3. Add rules

Tips

  • For suggestions on permissions for specific contact roles, see the BriteCore Setup for contacts
  • A rule can restrict a user from many webpages via (|). For example, restrict a user from the Lines, Settings, and Claims modules via britecore/(lines|settings|claims)
  • A rule can work in reverse using (?!) where access is negated except that which is defined. For example, restrict a user from all pages except the Claims module via britecore/(?!claims)

How-Tos

Restrict a Module
Restrict a Page
Restrict a UI Element
Restrict a Backend Function

Restrict a Module

Setup

  1. Navigate to Settings > System Wide > Permissions
  2. Create a new permission via the + or edit an existing permission via the pencil
    • For new permissions, add a label then click the pencil
  3. Click + Add Rule. The Access will default to None
  4. Click in the text input box of the Rule column
  5. For an Agent Portal permission, type agent/; for an Administrative Portal permission, type britecore/
  6. Type the title of the module that is to be restricted (e.g., Lines, Settings, etc.)

Examples

  • britecore/lines provides no access to the Administrative Portal's Lines module
  • britecore/claims provides no access to the Administrative Portal's Claims module
  • agent/payments provides no access to the Agent Portal's Payments module where sweep payments are made

Restrict a Page

Setup

The setup is the same as restricting a module, except the specific page within the module is added to the rule.

Examples

  • britecore/lines/notes provides no access to the Notes tab within the Administrative Portal's Lines module
  • britecore/claims/accounting provides no access to the Accounting tab within the Administrative Portal's Claims module
  • agent/policies/documents provides no access to the Documents (Attachments) tab of the Agent Portal's Policies module

Restrict a UI Element

Code must be added whenever a new restriction is needed:

  1. Add a suggestion to lib/settings/utils.py:get_permissions_suggestions
    • Follow a URL-like pattern, for example agent/accountsReceivable/makePayment
    • optgroup is a readable category, for example Agent Accounts Receivable
  2. Check the new permission path in the get block of the page in which you are working, for example ("${check_permissions('agent/policies/accountsReceivable/makePayment')}" == 'True')
    • check_permissions defaults to requiring the read permission and may need to be imported into the page template
  3. Add Javascript/HTML to control the visibility of the new element
    • New KO pages
      • Use <element data-bind=”visible: get.permissionVar”> OR
      • Use the get.permissionVar in a computed function
    • Legacy pages
      • Track down the relevant build or draw function
      • Use get.permissionVar and $$(‘el-selector’).show() or hide()
  4. Once the code is in place, build the rule as you would when restricting a module or page

Restrict a Backend Function

Code must be added whenver a new restriction is needed:

  1. Check lib/settings/utils.py:get_permissions_suggestions to determine if the module you are adding a restriction to is already imported into the modules list
  2. Decorate your function with lib/core/decorators.py:requires_permission, for example @requires_permission('agent/claims/submitClaim', 'rw')
    • Follow a URL-like pattern, for example agent/claims/submitClaim
  3. Once the code is in place, build the rule as you would when restricting a module or page

Feedback

Report unclear or missing documentation.