Authorization

Authorization defines what a user can or can't do after they get access to your application. (./authentication)

Aptli's authorization model combines both permissive and restrictive elements for tremendous flexibility:

Admin Rights visible through the user's settings (screenshot pending) and
A restrictive model of Roles achieved through membership (screenshot pending)

Admin Rights

Admin rights are permissive. This means permission must be granted to users but only to modify information or alter status. For example, having usersUpdate allows one user to alter some profile details of another user. This would include Name, Title, Division, etc. while excluding changes to email, passwords, SSO, and validation dates. Without this, users can only edit their own profile.

usersLogout is required to hard lock or log out a user and usersDelete is required to delete a user's account. usersCreate can undelete an account or create a unique new one with the field restrictions above.

Work order rights use the workOrders prefix: workOrdersCreate, workOrdersUpdate, workOrdersDelete. (Note: orders is a separate data model — do not confuse the two.)

Nearly all data models behave in this manner and only 3 Admin Rights supercede them all:

appSettingSchemasModify which allow modification to application-level settings like allowed domains, timeouts, and server information
adminRightsModify which allows users to share and extend admin rights to other users.
viewDeleted which allows users to view deleted records. This is nearly universal, though can be partially overridden by Role Restrictios.

Role Restrictions

Roles are Restrictive. This means assignment to a role prevents viewing and altering records with certain characteristics. Roles are a collection of Role Restrictions and consist of Members. Only the Owner of a role can change the members or anyone with RoleUpdate admin rights.

Role Restrictions come with a basic setup of model, field, comparison, filter value, and the read/edit/create/delete permissions. For example, let's say there were assets that should not be visible by competing contractors A and B. To prevent access to B's information do the following:

create a role called contractor A and add a Role Restriction with the following details:
set the model as Point to represent the Point Features
set a field with the information like owner
set a comparison like =
set filter Value to Contractor B
set read, edit, create, delete to true, meaning they cannot see it or change it.

Once complete, add your contractor A members to the role, and members of Contractor A will not be able able to see anything where the owner is Contractor B.

Using Admin Rights together with Role Restrictions

By default, all users other than the admin can see everything but not alter everything. Allowing write access broadly can be restricted to by records to define rigorous process controls offering some useful seperations:

By work stage (i.e. Preventing those who report work from seeing the quality assurance reports afterwards)
By asset (i.e. infrastructure like poles and ducts vs. active equipment and eletric cables are by others)
By physical and logical concepts (i.e. relationships like capacity and consumptions between offices vs. the location and characteristics of the offices themselves)

Customizing Authenticaiton and Authorization for new users

Modification of any of these settings will require access to "AppSettingSchemasModify" on the user profile. This is granted by default to super admins upon access to the application, but may be shared by other admins. To see the admin rights a user has view their profile under users (http://your host/admin/users) and see Admin Rights.

Checking Admin Rights

The following may be customized to overide the (defaults):

Roles for new users
Admin Rights for new users