Teams

Teams are an integral part of our permissions based system. They form the core of everything permissions are tied to. Users themselves do not have permissions, neither do Roles - although functionality can be configured around those entities, permissions should always be tied to teams to ensure they are enforced throughout the system (such as in reports).

Team Features

Users can be members of multiple teams, and they run the system logged in under a single team at any one time. This way users are always operating under the permissions of an individual team at any one time. Teams have the following security permissions that can be set:

  • Can Edit System Items
    Indicates that items that can be marked as system (such as sql wrappers) can be edited by this team.
  • Users
    Indicates all users that are allowed to use this teams permissions
  • Canvas Promotions
    Indicates which canvases this team has permissions to promote items from into the real system
  • Default Permissions
    Holds the default set of permissions this team has by entity type.
    • Default Permissions For Other Teams When Creating New Items Indicates when creating new items, you want to override the default permissions another team has for that object with a different set of permissions.

An important permission is the ability to change permissions, which again can be assigned to teams on a per entity basis.

Permissions

Legacy systems often have poorly implemented permission systems that result in poor performance, insufficient permission granularity, an upper limit on permission sets, limited permission visibility, or it simply not even being enforced universally such as through reporting, API's, Web Services, etc.

Our permission system is designed to address all of these common problems with a robust powerful permission system that is easy to use. This is administered in the following way:

  • Permissions belong at the Team level.
    • Users can be assigned to one or more Teams as required and will automatically have access to those permissions.
    • There are no limits to the number of teams you can create.
  • All entities in the system have permissions associated with them, or inherit permissions from parent entities.
  • Permissions are enforced universally throughout the application this includes, but is not limited to, the following:
    • All entities, either system entities, custom entities or entities created through our API.
    • Through all our multi-platforms clients applications whether connecting directly to the database or through a web service.
    • Through our API
    • Through all our importing functionality
    • Even at the database level using our insert, update, delete sps
    • Through all our reporting tools, including custom written ones.
  • For each entity type you can setup the default permissions any record of that entity has for a given team
    • For instance you could setup that by default a team has read-only access to all transactions in the system.
  • For every individual record you can override the default permission set (if you have permission to change permissions that is) and provide a bespoke new set of permissions for that one record.
    • For instance you could override the default read-only permission for all transactions for one team by individually setting certain transactions as no-access (or by bulk updating a set of transactions through our export/import tools).
  • For every default set of permissions for a team you can also provide individual permissions for other teams that will automatically apply when you create new records using that team.
    • For instance you could set up two teams - Accounting Team A, and Accounting Controller Team B, with both having default read-write access to all transactions. You can then set it up so whenever Team B creates a new transaction it overrides Team A's default access to it and makes it read-only. You could also set this up vice-versa for Team A.

By providing this complete set of functionality we provide a powerful and simple to setup permission system. You can finally make it so different accounting teams have access to different companies and transactions depending on their required roles. But most importantly the permissions are enforced everywhere and easy to maintain when setting up new teams/etc.

Default Teams

The system comes with two teams as default:

  • Admin
    This team is used to ensure an admin can always have full unrestricted access to everything within the system. Regardless of different permissions provided to the admin team, the team itself will always have full access. Only give admins permission to this team.
  • Standard User
    This team has read-only access to all items in the system, along with create and write permissions for certain common system entities.
Warning

These teams can not be removed from the system, they will always be recreated, and reset on upgrades, or Reset System Roles.

Note

You can copy these teams and use them as templates for designing actual teams you should use for your users.

Views

Teams can be managed using the following views: