taskrambler  0.1.8
Web server and task management solution.
role.h
Go to the documentation of this file.
1 /**
2  * \file
3  *
4  * \author Georg Hopp
5  *
6  * \copyright
7  * Copyright © 2012 Georg Hopp
8  *
9  * This program is free software: you can redistribute it and/or modify
10  * it under the terms of the GNU General Public License as published by
11  * the Free Software Foundation, either version 3 of the License, or
12  * (at your option) any later version.
13  *
14  * This program is distributed in the hope that it will be useful,
15  * but WITHOUT ANY WARRANTY; without even the implied warranty of
16  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
17  * GNU General Public License for more details.
18  *
19  * You should have received a copy of the GNU General Public License
20  * along with this program. If not, see <http://www.gnu.org/licenses/>.
21  */
22 
23 #ifndef __ROLE_H__
24 #define __ROLE_H__
25 
26 #include <sys/types.h>
27 
28 #include "class.h"
29 #include "ebac/permission.h"
30 #include "storage/storage.h"
31 
32 
33 CLASS(Role) {
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 };
99 
100 #endif // __ROLE_H__
101 
102 // vim: set ts=4 sw=4:
103 
const char * name
Definition: interface.h:43
CLASS(Role)
Definition: role.h:33