Application of ACL

[Owen Winkler]

We need to start applying permissions to areas that should be restricted.

There are three immediate concerns:

1) What are the permissions required for each section of the admin? In
particular note that every permission can be both a token and an access
level, such as ("publish" and "read") or ("publish" and "write").

2) How will we upgrade users in existing installations to have
permissions so that they're not locked out entirely?

3) Anyone willing to contribute a solid graphical concept for the group
and permission management page should do so now, or I'll do it and it'll
be the ugliest thing in the admin.

Owen

[Dallas Goldswain]

Hi,

i have just joined the list and have a few ideas for this, i am just hacking habari to pieces so i can get a better under standing of it.
this being my first open-source project i am contributing too.

I also have some views for your previous post on theming, i have done a xml, xsl theme engine, will see how/if it works with habari then people can comment.

thanks
dallas

[Andrew Rickmann]

Re 2: I think it is reasonable to assume that at the time of upgrade
the person doing the upgrading will be an admin and in a position to
change rights. So if every user is given full rights on upgrade with a
notice on completion to the upgrader to check and change them that
would suffice.

Andrew

2008/10/14 Owen Winkler <epi...@gmail.com>:

[Ali B.]

On Tue, Oct 14, 2008 at 4:37 PM, Owen Winkler <epi...@gmail.com> wrote:

We need to start applying permissions to areas that should be restricted.

There are three immediate concerns:

1) What are the permissions required for each section of the admin?  In
particular note that every permission can be both a token and an access
level, such as ("publish" and "read") or ("publish" and "write").

I will try to list some of the suggestec core tokens I can think of on the top of my head.
Also, I am assuming that write includes editing, deleting and changing the status of the item. These might be re-decided later though. I suggest to have tokens for the whole admin pages as well. If this token is set, the access level should override the ones of the child elements if the latter would grant more access. Or something.

Create Entry
Create Page
Manage Entries
  Own entries
  Others' entries
Manage Pages:
    Own pages
    Others' pages
Comments
    Comments on own posts.
    Comments on others' posts.
Tags
Options
Themes
    Change theme
    Configure active theme
Plugins
    Activate plugins
    Deactivate plugins
    Configure active plugins
Import
Users
    Edit own user account.
Groups
Logs

2) How will we upgrade users in existing installations to have
permissions so that they're not locked out entirely?

Andrew's suggestion looks valid, though not awfully secure I must add. Although it's not likely, but it's a valid case that one of the other users who already have access to the Habari installation can hijack it during the upgrade process. But current users in Habari are all admins, so I don't think it would be a problem to set the user considering that fact.
 

3) Anyone willing to contribute a solid graphical concept for the group
and permission management page should do so now, or I'll do it and it'll
be the ugliest thing in the admin.

Owen

--
Ali B / dmondark
http://www.awhitebox.com

[Chris Meller]

I agree. Make everyone an admin and let someone change things later on. Currently there are no restrictions, so everyone is already an "admin", so they're not losing anything.

Note that there is no actual "upgrade" process, as there is in WordPress. The first person to visit any part of the site after the files have been updated will trigger the database upgrade, so providing some kind of notification could be difficult.

[Arthus Erea]

Do we have a timeline for 0.6?

Also, anything JS or UI-related I could be of assistance with?

On Oct 14, 2008, at 10:37 AM, Owen Winkler wrote:

>
> We need to start applying permissions to areas that should be
> restricted.
>
> There are three immediate concerns:
>
> 1) What are the permissions required for each section of the admin?
> In
> particular note that every permission can be both a token and an
> access
> level, such as ("publish" and "read") or ("publish" and "write").

I agree with dmondark.

> 2) How will we upgrade users in existing installations to have
> permissions so that they're not locked out entirely?

I think we should simply assume all users are admins. Nobody is going
to be _gaining_ new access that they didn't already have. So let's
just toss everyone into the "admin" group.

> 3) Anyone willing to contribute a solid graphical concept for the
> group
> and permission management page should do so now, or I'll do it and
> it'll
> be the ugliest thing in the admin.

I'd be willing to work on implementation, through my graphical prowess
is scarcely superior to yours.

I like some mockups Heilemann did:
http://www.flickr.com/photos/heilemann/2276021327/in/set-72157603941330603/
http://www.flickr.com/photos/heilemann/2276813124/in/set-72157603941330603/