Permissions schema
[ Previous: Schema for user access ]
[ Top: To-do manager ]
[ Next: Definition of todomgr_create ]
The permissions facility is used to grant users access to projects that they don't own. A
project may be associated with any number of keywords, and a user may have permissions to any
number of keywords. The permission mechanism permits fairly fine-grained control over who can
do what, as this part of the application is really aimed at granting my own customers varying
degrees of access to my own to-do list. So I want some of them to be able to modify the
priorities of their own category of tasks, for instance, but I don't want them to be able to
rename tasks.
The tables we need for this are pretty easy: just a keyword table which associates a keyword
with a project, and a permission table which grants a user various privileges to a given keyword.
If no permission is given to a user for a given keyword, projects using that keyword will be
completely invisible to the user. (Unless the project has more than one keyword and the user
has viewing privilege to another applicable keyword.)
Keyword table
The keyword table is very simple:
| |
process text,
keyword text
|
Permission table
The permission table is a little trickier. When working in Tcl I usually use a string for
flags of this nature, then do a [string match *b* $string] or something to look
for the 'b' flag. As the only question which really impacts queries is whether or not any
permission exists, I see no need to use Booleans.
| |
userid text,
keyword text,
flags text
|
The flags I will define are:
- p
- assign keyword. To assign a process to a keyword, I must own the process
or have 'p' privilege. To assign a keyword to a user, I must own or have
'p' privileges to all the processes associated with the keyword.
- t
- request a task.
- r
- modify priority.
- m
- modify anything including priority.
There is no flag for viewing privileges, because mere existence of the keyword grants that (the
query is easier that way.)
Task requests can be made by any user who has viewing privileges on a project. The requestee
must be (at least) level 2 and likewise have viewing privileges on the project. The task
requested is not active until the new owner accepts it; a request may also be foisted
off on someone else. Logically a request could be made of a role or queue as well, but I
haven't implemented roles and queues yet, so that will have to wait.
[ Previous: Schema for user access ]
[ Top: To-do manager ]
[ Next: Definition of todomgr_create ]
|
This code and documentation are released under the terms of the GNU license. They are
additionally copyright (c) 2000, Vivtek. All rights reserved except those explicitly
granted under the terms of the GNU license.
|