Users Authorisation

Permission are handled by the laravel-doctrine/acl package as part of of our use of laravel-doctrine for the database ORM

Permission and some built-in Roles are defined in the config/roles.php

Roles have assigned Permission
Users have assigned Roles
We check that a User has a Permission, we never^[1] check that they have a role.
Roles are split into groups as described below.

[1] OK members.* roles are check for during the automatic audit.

Permission

Permission are basically just strings and are what we refer and check in code.
Most are hard coded in the roles.php but some are automatically generated by HMS (tools)
Some example persmission

• profile.view.self
• profile.view.limited
• profile.view.all
• accessCodes.view
• membership.approval
• membership.banMember

Checking for permission

There are many ways and time to check for permissions

With a user model
$user->can('box.view.self');

With the current logged in user Gate::can('box.view.all');

As a route Middleware
This we tend to do in the constructor of Controllers either against all methods or some.

public function __construct()
{
    $this->middleware('can:box.view.self')->only(['index', 'show']);
    $this->middleware('can:box.buy.self')->only(['create', 'store']);
    $this->middleware('can:box.issue.all')->only(['issue']);
    $this->middleware('can:box.edit.self')->only(['markInUse', 'markAbandoned', 'markRemoved']);
    $this->middleware(['can:box.printLabel.self', 'feature:label_printer'])->only(['printLabel']);
    $this->middleware('can:box.view.all')->only(['audit']);
}

In a blade view @can('box.edit.self')

Roles

Within HMS Roles are split into four groups

• member.*
• team.*
• tools.*
• user.*

Member roles

These roles are used to represent the state of Member. These roles are exclusive and a Member will only have one of them at a time.

• member.approval Assigned when a user first registers and their details are awaiting review by someone from the Membership Team
• member.payment Members are transitioned to this once their details are approved and stay at this role until their first payment is reconciled
• member.current This is the main roles all paying members will have.
• member.ex Members who stop their monthly payment are transitioned to this role. If they start paying again they are transations back to the member.current role.

Transitions between the above four roles are handled automatically by HMS's membership audit process that runs each weekday at 23:55

• member.temporarybanned
• member.banned temporarybanned & banned are roles which the Trustees can manually transition a member too. They can also be transitioned away from an the correct current or ex role will be applied.

Team roles

These roles represent the Teams that we have at Nottingham Hackspace that members can join if they wish to help out in the relevant area.
There are four built in team roles that HMS automatically creates (see roles.php) and these are needed for HMS to function as they are hardcoded destinations for notifications.
Other teams can be freely created by the Trustees as needed and they can or remove Members from the Teams as needed.

All team. roles are stripped when a Member transitions to the Ex Member state.

Tool roles

These roles are automatically generated when Tools are added into HMS, there are three for each tool. They represent the level of access a member may have for a restricted tool.

• tools.{toolname}.maintainer
• tools.{toolname}.inductor
• tools.{toolname}.user

.maintainer and .indutor roles are granted and revooked in HMS by the Trustee at the request of the Team responsible for the tool.
The .user role is given to a member when they are inducted on the Tool and there inductor registers there card at the nh-tool reader.

A .user role is retained when a Member transitions to the Ex Member state but all others are striped.

User roles

Currently there are three special user. roles.

• user.super This the power user role with all the permissions. Only few have such power.
• user.temporaryAccess This role is automatically applied and removed to give a Member Building access when the Access State is not Fully Open
• user.buildingAccess This is a role for non member users that need 24/7 building access, like landlords and cleaners.

All user. roles are stripped when a Member transitions to the Ex Member state.