Twproject integrates a really fine grained security model without bothering too much neither the user nor the administrator for setting it up.

In order to understand Twproject’s security, there are some key points that we will explain in this chapter.

First of all, Twproject’s security is role based; having a role means gaining permission for performing certain operations, for example creating project, inserting worklog, reading resources. We call this ability “permission”; a role is a collection of permissions.

There are two kinds of roles, “local” and “global”. Local roles have the scope of a project: this means that permissions work on the project where the role is set (through an assignment). Local roles are assigned to resources during the assignment phase; so when you assign a resource on a project as, for instance, project manager (that is a local role), you are giving the resource the set of permissions associated to the PM role.

In this way you will create a really fine grained security structure, but with some limitations: setting local permission will not allow, for instance, a supervisor to read every data of your project without assign her/him on every project, which would be a waste of time.

In order to solve this kind of problems Twproject supports also “global” roles. A global role is a set of permissions that is directly associated to a resource, not through the mediation of an assignment. So if a user has a global role with “project read” permission, she will read every project, bypassing assignments.

This model is really refined and works well in most cases, but Twproject goes beyond that, and introduces a more sophisticated object called “area”. An area is a sort of “sandbox”, and almost all Twproject’ objects belong to one and exactly one area. Objects from different areas cannot “see” each other (with few exceptions), so for instance if you have two areas, “production” and “accounting”, you may have distinct, separate projects, roles, project types, etc. .

Obviously having two completely separated areas may also be a problem, say for a single company, where probably some users should be cross-area. Twproject supports also this kind of solution, by allowing having on the same user global roles and assignments from different areas.

Another interesting feature is security management delegation: in each area you may have a sort of sub-administrator, the “area manager”, that is responsible of new user creation and area administration.

Setting up this kind of environment is simple but not trivial, we warmly suggest to avoid multi-area management until you have really understood Twproject’ security model.

Last point is how security works for tree-structured object (like project or resources); well by default security is propagated so if you have a permission on a project, you have the same permission on each descendant. This is the default behavior, but this setting is local to the node, so for instance Scrum based projects may have a different configuration (on Scrum a customer can add ToDos on the backlog, but cannot interfere with sprints, so permissions are not to be propagated in that case).

Summing up how security works, we will examine an example of how Twproject answers this question: can user U add an ToDo on phase T1.1. Here the structure of the example:

The resource U is assigned on T1 with local role W(orker) that contains some permissions like project read, ToDo add/read/modify, and others. U has no global roles.

This is the flow followed by Twproject in checking security, when a check is true the testing stops, otherwise the following clause is checked:

1) Is the user owner of the project T1.1?

2) Is the user an administrator?

3) Has the user a global role in the same area of the project T1.1 containing the “add ToDo” permission?

4) Is U assigned to T1.1 with a role containing “add ToDo” permission?

5) Finally check if parent (T1) propagates permissions and child (T1.1) inherits. The answer is “yes” by default so it will check steps 1-4 with T1.1 parent T1.

Making this kind of test faster has been a really challenging project.

Security editors are really simple with respect to the security model 🙂

More about security: