User Module

The user module will contain the information about the users. Including log on information, and which user groups, and which roles they belong to. There will be a flat two-level hierarchy for the security. It will be:

  • User Roles
  • User

This way the permissions can be controlled in roles. This can be overriden at the user level. This is similar to how the Linux file system permissions work. The roles contain a reference to the partitions, and thus you can have different roles in different partitions (you can be an administrator of one partition, and a lowly user in another). This way you can have the permissions controlled for the partitioned data. Users can belong to as many different roles as they like or they can belong to none.

The User Group will also contain references to the partition/brand. This allows for different branding rules based on the partitions that they have access to. Users can belong to as many groups as they like, or they can belong to none.

The granting of permissions is done in a similar fashion to Drupal, where there are certain actions that can be performed for each partition.

Initially we will only develop a local login version of the authentication, with other to follow. Essentially the external validation will be another lookup table with a link to the login table to say which service and what the valid token is.

The user module will contain the user's details including email addresses (per brand/partition), contact details, permission mapping, etc.

The users can be internal users, or external users (such as principals, agents).

Users have roles which belong to partitions. Users can have as many roles as they like.

Users can be allocated into teams (depending on the organisation, sales staff can be divided into teams with a team leader) . A user can be part of a team and also be a team leader for that team. A user can belong to as many teams as they like. A Team leader should be able to call up her/his team and see sales, reassign bookings etc. Users can also have a assignee which is another user who is authorised to access the original users bookings/quotes, etc. Essentially they inherit the roles and permissions of the original user.

More specifically the users module will have the following capabilities:

  • Be a member of a group (or groups) for logical functions (such as driving branding).
  • Be a member of a role (or roles) which control access including partition access.
  • Store contact information, email, phone, etc.
  • Store contact information per partition to be able to brand in each partition.
  • Be able to add or remove user from groups.
  • Be able to add or remove user from roles.
  • Be able to add additional logins from third party authorities (such as Facebook, Twitter, Google+, etc)
  • Set defaults with respect to system behaviour (default brand, default agency, default principal etc)
  • Be able to set internal commission for the user (or user group).
  • Be able to identify duplicates.
  • Be able to merge records.