Twproject integrates a really fine grained security model without bothering too much neither the user nor the administrator for setting it up.<\/p>\n
In order to understand Twproject\u2019s security, there are some key points that we will explain in this chapter.<\/p>\n
First of all, Twproject\u2019s security is role based<\/i>; having a role means gaining permission for performing certain operations, for example creating project, inserting worklog, reading resources. We call this ability \u201cpermission\u201d; a role is a collection of permissions.<\/p>\n
![\"\"](\"https:\/\/twproject.com\/support\/wp-content\/uploads\/2014\/01\/clip_image0032.png\" "\\"\\"")
There are two kinds of roles, \u201clocal\u201d and \u201cglobal\u201d. 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<\/i> role), you are giving the resource the set of permissions associated to the PM role.<\/p>\n
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.<\/p>\n
In order to solve this kind of problems Twproject supports also \u201cglobal\u201d 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 \u201cproject read\u201d permission, she will read every project, bypassing assignments.<\/p>\n
This model is really refined and works well in most cases, but Twproject goes beyond that, and introduces a more sophisticated object called \u201carea\u201d. An area is a sort of \u201csandbox\u201d, and almost all Twproject\u2019 objects belong to one and exactly one area. Objects from different areas cannot \u201csee\u201d each other (with few exceptions), so for instance if you have two areas, \u201cproduction\u201d and \u201caccounting\u201d, you may have distinct, separate projects, roles, project types, etc. .<\/p>\n
Obviously having two completely<\/i> 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.<\/p>\n
Another interesting feature is security management delegation: in each area you may have a sort of sub-administrator, the \u201carea manager\u201d, that is responsible of new user creation and area administration.<\/p>\n
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\u2019 security model.<\/p>\n
Last point is how security works for tree-structured object (like project or resources); well by default security is propagated<\/i> 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).<\/p>\n
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:<\/p>\n
![\"\"](\"https:\/\/twproject.com\/support\/wp-content\/uploads\/2014\/01\/image.png\" "\\"\\"")
<\/p>\n
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.<\/p>\n
This is the flow followed by Twproject in checking security, when a check is true the testing stops, otherwise the following clause is checked:<\/p>\n
1) Is the user owner of the project T1.1?<\/p>\n
2) Is the user an administrator?<\/p>\n
3) Has the user a global role in the same area of the project T1.1 containing the \u201cadd ToDo\u201d permission?<\/p>\n
4) Is U assigned to T1.1 with a role containing \u201cadd ToDo\u201d permission?<\/p>\n
5) Finally check if parent (T1) propagates permissions and child (T1.1) inherits. The answer is \u201cyes\u201d by default so it will check steps 1-4 with T1.1 parent T1.<\/p>\n
Making this kind of test faster has been a really challenging project.<\/pre>\nSecurity editors are really simple with respect to the security model \ud83d\ude42<\/p>\n
More about security:
\n\n\n
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\u2019s security, there are some key points that we will explain in this chapter. First of all, Twproject\u2019s security is role based; having a role means gaining permission for […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":2210,"menu_order":51,"comment_status":"closed","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-2378","page","type-page","status-publish","hentry"],"yoast_head":"\n