The simplest way to imagine a “security area” is a kindergarten “sandbox”. Every Twproject entity such projects, resource, roles, ToDos, type etc. “lives” inside the sandbox boundaries.
The installer creates a default area, and normally you should not need any more.
Anyway, areas are useful objects that can help fine-tuning Twproject in complex working environment.
Every sandbox is a world-apart, and people coming from another sandbox cannot interact with your world (by default).
In this sense security areas can model a multi-company environment (actually our online demo is a single instance with thousands of areas) but this strictly isolated configuration usually didn’t fit well complex scenarios, because even in large companies there are users that must have access cross-areas (CEO?).
In this cases Twproject administrators can create users with cross-area roles, so that you can have both isolation and visibility.
For instance you could have a project with some branches in “administrative” area and some branches on “production” area, but the introduction of this level of “barriers” can quickly rise the complexity of the security configuration.
The standard security, based on assignment, already set the required accesses.
Think twice before creating a second area: things may quickly become horribly complex But for advanced usage, in order to create a new area go to the “admin” page, focus the security box.
Here you can use the “area creation wizard” that creates a new area and standard roles on it.
By going on “area management” you will have the standard find-and-edit pages.
How to create a multiple-area environment
If you want to setup a multiple area environment described in the introduction follow these instructions:
1) Supposing to have two users U1 and U2
2) Login as administrator
3) Supposing you already have a area A1
4) Create a second area A2 with the wizard
5) Edit U1, assign it to area A1 and give it the role Area Manager A1
6) Edit U2, assign it to area A2 and give it the role Area Manager A2
If you stop now area A1 and A2 are completely separated, U1 and U2 can create new resources in their areas respectively, so security management is almost completely delegated.
If you want to have some users with cross-area rights, you (administrator) can give them roles in both areas, or if you want to delegate you can give U1 the role of area manager even on area A2. In latter case U1 is the manager of both areas.
Note that permissions given locally go beyond area restrictions, so if you have a project T1 on area A1, you can assign a resource (U3) from area A2 with role “Project manager A2”. In order to set-up this project you must have “project create” on A1 and “resource: manage” and “assignment: create, read, write” on A2.
In this case U3 will operate on T1 without restrictions, but in general U3 doesn’t see any project in A2 except T1.
Considering that you can change roles or create new ones, Twproject lets you have a really flexible security environment.
In order to check permission of someone on a project there is a tool available from admin page called “check permission on project”, pick a user, a project, press search and look at permissions.
Remember that every object in Twproject belongs to an area, for every lockups like project type, event type o ToDo status.