Changes to roles and permissions
Today we've deployed some fairly minor changes to Loco's permissions model.
Account administrators can join any project
It has always been the case that Account Administrators are able to create their own projects without providing other administrators with access. This made it possible for owners to be locked out of projects in their own account.
From now on Account Owners (and Administrators) can add themselves to any project without invitation. Your project listing still only shows "your" projects, but it's now possible to view and join any others from your "Project roles" pop-up, as shown below.
Project owners can be replaced
It's now possible for Project Owners to leave their projects by designating a new owner to replace them. Similarly, Account Administrators now have the power to replace project owners with either themselves or another team member.
This solves a long-standing issue where employees might leave an organisation without their colleagues being able to access their projects.
Increased privacy for team members
It has always been the case that the "People" tab on your team dashboard shows all members of all projects, regardless of whether you can see those projects. From now on, only team members that require access to team members outside of their projects will see those members.
Anyone with permission to add new members to a project will be able to see all members of all project teams. We can't think of a good reason why a person without this permission would need access to members outside of their projects, but we're open to feedback on this.
Permission to grant permissions
Loco's permission model has a loophole whereby anyone with permission to add or modify team members is able to grant permissions higher than their own. This is by necessity, but not entirely consistent with good security.
To maintain the expected functionality while mitigating the risk of exploitation, a couple of changes have been made:
Only Project Owners and Account Administrators can change their own role in a project. This prevents Managers upgrading themselves to Administrators, although they are still able to assign the Administrator role to others.
Project members with permission to "Add new members" no longer need the "Change member roles" permission to modify the roles of members they've added. Permission to "Change member roles" and "Remove project members" can reasonably be removed from Manager roles, although the built-in Manager role remains unchanged for the time-being.