role.h
3.61 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
/**
* \file
*
* \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/>.
*/
#ifndef __ROLE_H__
#define __ROLE_H__
#include <sys/types.h>
#include "class.h"
#include "ebac/permission.h"
#include "storage/storage.h"
CLASS(Role) {
char id[37];
unsigned long hash;
char * name;
size_t nname;
/**
* \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.
*/
Permission * permissions;
size_t npermissions;
User * users;
Hash users_idx;
};
#endif // __ROLE_H__
// vim: set ts=4 sw=4: