***UPDATED 9th Sept***
We’re underway with the next version update for Copper, and we’re working on something that we really want some feedback on, for the first time in about seven years we’re going to overhaul the permissions model. We think its really going to simplify things, and allow us to bring you a host of new resource management tools that will blow your socks off.
Why are we doing this? To make things simpler for everyone, easier to learn, easier to support. One of the consistent pieces of feedback we get is that the Copper permissions model is too confusing, and I agree with this entirely. So, we’re going to take the lead from operating system permissions models.
That said, one thing I’ve learnt over the past decade building this software (yes we’re coming up to 10 years!) is that its much harder to reduce complexity than it sounds.
In essence, a good project management software tool should allow you to manage two hemispheres:
1. A bunch of stuff that needs to get done
2. A bunch of people that can get it done.
It should be simple enough to create and maintain a series of projects/tasks, review the progress of same, and it should also be simple enough to create and maintain a series of people/organizations, and review the workload of same. In this way you know where a PROJECT is at, but also where a PERSON is at.
The current access model in Copper allows you to give a user or a group read/write/deny access to a Module (i.e. what a user sees), a Client (with this they see all projects), a Project (with this they see all tasks), and also allows you to allocate users to a Task (they see this task in To Do). If a user is in a group they adopt the groups permissions. For the most part this works, but then there are Client/Project/Task owners, an Admin user (who has access to everything) and things start to get confusing.
Another regular redundancy we find is that there are a whole bunch of ‘People’ or ‘Group’ objects in Copper. There is: User, Contact, Group, Client, Account manager, Project Owner, Project Participant, Task Owner, and Task Allocatee. Woah! There should just be People, and Organizations.
So, here are our thoughts on how to simplify this:
Firstly we’re going to remove a bunch of things and replace them with a single ‘People’ Module. We’re going to remove the Contacts module, remove the Clients module, remove Users and Groups from Admin, remove Project and Task owners. Along with this we’ll introduce a new permissions model.
The People Module
The ‘People’ module will contain People and Organizations. A Person is anyone you come into contact with when you undertake a project. So this includes contacts and users (A user is just a person with login access). An Organization is any grouping of People, for instance a client, a department, a vendor, or a special project team.
The Permissions Model
In the new permissions model, we still have an Admin user (access to everything), and we still allow you to set READ/WRITE access to Organizations, Projects, and Tasks. We also allow the Admin to show/hide module items for each user.
Here are the rules:
Anyone can create an Organization. You add People (that you have access to) to an Organization (They are given Read access, Admin can set Write access to an Org)
Anyone can create a Project. You add People (that you have access to) or Organizations to Project.
A user can read an Org if they have Read/Write on the Org, or if they have Write on any of the projects that Org is on
A user can edit/delete/addpeople to an Org if they have Write on the Org (you can only ever add People they can read, see People below)
A user can read/edit/delete/add people to a Project if they have Write on the Project or Write on any Org on that Project
A user can read/edit/delete/add people to a Task if they have Write on the Task, Project, or any Org on that Task
A user can create a Task if they have Write on the Project, or any Org on the Project
A user can read/edit a Person if they are that Person or they have Write on an Org that person is in
A user can create a Person (contact, i.e. no login) if they have Write to any Org
Admin can create a Person (user, i.e. login) or delete a Person.
We’re getting there no?? Feedback please.
Ben.