Hi,
As mentioned a couple of days ago, I sending now my ideas about the
permissions. Feedback is more than welcome.
I had a look on Turbine. I try to be as close as possible
to Turbine with my implementation of the access rights.
Roles:
------
I thought the following roles make sense. The BASIC idea of these roles
are in braces ():
- root (all permissions)
- admin (most of the permissions)
- trusted_user (permissions to add and modify)
- authenticated_user (only permissions to add)
- guest (cannot neither modify nor add)
Anyway, is not that important to fix these roles now, since Turbine
provides a flexible handling of the roules. I plan to make this five
roles as defaults in the installation.
Comments?
Permissions:
------------
This topic is a bit tricky. We have to find a tradeoff between
flexibility and easyness in the configuration.
I mean: Should the access rights (add, modify, ...) for every layer
(project, faq, topic, question, answer) be seperately configurable?
Or is it sufficiant to have these access rights for either
all layers or none?
I suggest to keep this as simple as possible, to only to have
permissions for all or none of the layers. Objections?
Thus I plan to implement the following permissions into the existing
Jyve code (elem stands for elements). The changes will go to the actions
and the screens classes.
- add_jyve_elem (project, faq, topic, question and answer)
- modify_jyve_elem (dito)
For the realease feature (admin has to release elements first)
- see_unreleased_jyve_elem (e.g. only for admin)
- release_jyve_elem (for admin)
- add_unreleased_jyve_elem (e.g. for auth. user)
- modify_my_own_unreleased_jyve_elem (e.g. for auth user)
(Besides this also the turbine User Administration permissions will be
implemented to jyve (add_user, modify_user, ...).)
Makes sense? Did I forget about anything? Please comment!
t. Bernie
On Sat, 15 Jan 2000, jon * wrote:
> on 1/15/00 12:19 PM, Bernie <[EMAIL PROTECTED]> wrote:
>
> > Since Jonas & Co. take effort into the search and template issues, I
> > will concentrate my coding as next on the different access Permissions
> > (guest, authenticated user, moderator - rights for: read, add, change,
> > delete, a.s.o.). Is anybody else working on that issue?
> > I will have a deeper look into turbine and to see how this is working
> > there. After this I will send my intentions to this list.
>
> Nope, you are the first to step up. +1 from me! ;-)
>
> > Furthermore I plan to add a feature with a possible configuration, so
> > that the new input is reviewed first by a moderator, before it is
> > visible for other users. This allows some kind of control over the
> > provided information (to ensure that only correct information is
> > provided to the world).
> > This requires some extention to the existing tables. I was thinking
> > about adding two columns:
> > - RELEASED [ timestamp(14), Default NULL]
> > - RELEASED_BY [ int(11), Default NULL ]
> > into the following tables:
> > - question
> > - answer
> > - project
> > - faq
> > - topic
>
> Excellent idea. Maybe you could have it so that when a moderator is browsing
> the system, if he/she see's an entry that has a "[Moderator Approve]" link
> next to it, then that moderator can simply click that link to approve it.
> You should also build in the option to have the moderator emailed every time
> a change occurs. In the email could be the new item text and the same link
> mentioned above so that all they have to do is click on the link in their
> email to approve the item.
>
> Make sense?
>
> +1. Please add the above changes to the schema as "alter table", after the
> table is created, so that it is possible to upgrade easily from previous
> versions.
>
> -jon
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
