***UPDATED 15th 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.
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). Also, there are a whole bunch of ‘People’ or ‘Group’ objects in Copper that further complicate matters, including User, Contact, Group, Client, Account manager, Project Owner, Project Participant, Task Owner, and Task Allocatee. Woah! There should just be: People and Organizations.
With that in mind, here is how we simplify this. In essence this is how Copper v5.0 will work:
We’re going to remove the Clients module, the Contacts module, remove Users and Groups from Admin, remove Project and Task owner fields and replace them with a ‘People’ module. Then, we’re going to simplify how permissions work.
New People Module
The ‘People’ module will contain People and Organizations. A Person is anyone you come into contact with when you undertake a project. A copper user will just be a person who is given log in Access). An Organization is any grouping of People, for instance a client, an internal department, a vendor or subcontractor, or a special project team.
In the new permissions model, you simply add People to Organizations, Projects, and Tasks
When a person is on an Organization, you can set them to have access to All Projects. Or you can add them to specific projects if you want to limit their access.
When a person is on a Project, they see all tasks in that project, and can se the Organization details, but not edit them.
When a person is on a Task, they see it in their To Do and can add commentary to it.
We’ll also allow you to set a flagbearer person in Organizations, Projects, and Tasks. This just means they are the current go to person on this thing, and they can pass the flag as needed.
Anyone can create an Organization or a Project, and you can add anyone that is in an Organization you’re already in.
Anyone can create a Person, but only Admin can give that Person log in access.
More to come, but this is simplifying…. Getting there…