taskrambler  0.1.9
Web server and task management solution.
Functions
role.h File Reference
#include <sys/types.h>
#include "class.h"
#include "ebac/permission.h"
#include "storage/storage.h"
+ Include dependency graph for role.h:

Go to the source code of this file.

Functions

 CLASS (Role)
 

Detailed Description

Author
Georg Hopp
Copyright
Copyright © 2012 Georg Hopp

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

Definition in file role.h.

Function Documentation

CLASS ( Role  )
Todo:
We need a good way to serialize a hash. If I can't find any I should choose a different data structure here...but I think there is a way. And as there is none I will change this to simple arrays and add an index to them that is a hash. The arrays could even be static. When a role is load the index on permissions and users is updated each time. The longer I think about it the less I think this role based approach is good... Each user is able to create resources (tasks, projects, etc.) but in the first place these should only be accessible for her/him. Then he should be able to allow other users or groups of users to access these but with each of these separately. So at least this can't be accomplished only with roles or else a role has to be created for every resource. OK, lets think about some roles:
  • owner (for each resorce ... this will enable us to share ownership.)
  • viewer (for each resource ... these might only see the resource.)
  • projectmember (for each project resource)
  • teamlead (might have special rights for some projects and be able to see what each projectmember can see)
  • projectowner (well ... this might be owner of a project resource)
  • projectadmin (being able to change parts of the project but can't see everything...)

I think I do not need an index here...because these are only used to setup a permission set within the user session...so these are simply added to this set..... With the users it is a different story...in fact i don't think that this relation should be stored here...this is an extra relation which is indexed by the usr name and credential and holds an array of roles he is in...on the other hand...if a role changes we need a fast way to get all users to update their permissions if they are online...

New thoughts, a resource might be either a URL or a userid. When it is a userid the configured rights are valid for all resources owned by that user. Each grouped resource has less precedence than a specific one. That means, access rights can be removed for single resources after they have been added via a grouped resource. By default each user is assigned a role that allows him to do everything with every resource she/he has created. This role is also named after the user id.

Definition at line 33 of file role.h.

References interface::name.

33  {
34  char id[37];
35  unsigned long hash;
36 
37  char * name;
38  size_t nname;
39 
40  /**
41  * \todo We need a good way to serialize a hash.
42  * If I can't find any I should choose a different
43  * data structure here...but I think there is a way.
44  * And as there is none I will change this to simple
45  * arrays and add an index to them that is a hash.
46  * The arrays could even be static.
47  * When a role is load the index on permissions and
48  * users is updated each time.
49  * The longer I think about it the less I think this
50  * role based approach is good...
51  * Each user is able to create resources (tasks,
52  * projects, etc.) but in the first place these should
53  * only be accessible for her/him. Then he should be
54  * able to allow other users or groups of users to
55  * access these but with each of these separately.
56  * So at least this can't be accomplished only with
57  * roles or else a role has to be created for every
58  * resource.
59  * OK, lets think about some roles:
60  * - owner (for each resorce ... this will enable us
61  * to share ownership.)
62  * - viewer (for each resource ... these might only
63  * see the resource.)
64  * - projectmember (for each project resource)
65  * - teamlead (might have special rights for some projects
66  * and be able to see what each projectmember
67  * can see)
68  * - projectowner (well ... this might be owner of
69  * a project resource)
70  * - projectadmin (being able to change parts of the project
71  * but can't see everything...)
72  *
73  * I think I do not need an index here...because these are only
74  * used to setup a permission set within the user session...so
75  * these are simply added to this set.....
76  * With the users it is a different story...in fact i don't think
77  * that this relation should be stored here...this is an extra
78  * relation which is indexed by the usr name and credential and
79  * holds an array of roles he is in...on the other hand...if
80  * a role changes we need a fast way to get all users to update
81  * their permissions if they are online...
82  *
83  * New thoughts, a resource might be either a URL or a userid.
84  * When it is a userid the configured rights are valid for all
85  * resources owned by that user.
86  * Each grouped resource has less precedence than a specific
87  * one. That means, access rights can be removed for single
88  * resources after they have been added via a grouped resource.
89  * By default each user is assigned a role that allows him to
90  * do everything with every resource she/he has created.
91  * This role is also named after the user id.
92  */
93  Permission * permissions;
94  size_t npermissions;
95 
96  User * users;
97  Hash users_idx;
98 };