Private posts
Michael C. Harris
Private Posts plugin I wrote about earlier.
Currently, a logged in user is able to see Post::status('any') and a
someone not logged in can see Post::status('published'). I want to
disallow a logged in user from seeing posts with private status based
upon $user->can('view_private'). Any advice on how to do this would be
greatly appreciated.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Scott Merrill
> someone not logged in can see Post::status('published'). I want to
> disallow a logged in user from seeing posts with private status based
> upon $user->can('view_private'). Any advice on how to do this would be
> greatly appreciated.
I think we're going to need to take a long, hard look at Posts::get()
as the ACL system develops. Off the top off my head, I don't have any
specific suggestions. :(
Michael C. Harris
Is anyone doing ongoing work on the ACL at the moment? Is there a
clear picture of what needs to be done? Are there known blockers?
Scott Merrill
>
> On Sun, Feb 17, 2008 at 09:29:07AM -0500, Scott Merrill wrote:
> >
> > > Currently, a logged in user is able to see Post::status('any') and a
> > > someone not logged in can see Post::status('published'). I want to
> > > disallow a logged in user from seeing posts with private status based
> > > upon $user->can('view_private'). Any advice on how to do this would be
> > > greatly appreciated.
> >
> > I think we're going to need to take a long, hard look at Posts::get()
> > as the ACL system develops. Off the top off my head, I don't have any
> > specific suggestions. :(
>
>
> Is anyone doing ongoing work on the ACL at the moment? Is there a
> clear picture of what needs to be done? Are there known blockers?
I'm not currently working on ACLs, but I want to do so soon.
What needs to be done:
* identify discrete tasks for which permissions should be defined
* identify groups of tasks for which a single permissions can be used
* test said permissions rigorously
* create default groups and permission assignments in installhandler
using our API
* identify extant code which needs revision due to ACLs -- for
example, Posts::get() needs to only fetch those content types to which
the current user (who could be an anonymous not-logged-in visitor) has
permission to see.
Feel free to discuss here on on Trac issues as you see fit.
Michael C. Harris
> I'm not currently working on ACLs, but I want to do so soon.
>
> What needs to be done:
> * identify discrete tasks for which permissions should be defined
> * identify groups of tasks for which a single permissions can be used
> * test said permissions rigorously
> * create default groups and permission assignments in installhandler
> using our API
> * identify extant code which needs revision due to ACLs -- for
> example, Posts::get() needs to only fetch those content types to which
> the current user (who could be an anonymous not-logged-in visitor) has
> permission to see.
I haven't had much time for Habari recently, but I'm happy to continue
to help out with the ACL. If there's something you specifically would
like to throw my way, let me know. Otherwise I'll try to work out
exactly what is required when I have a chance.
Michael C. Harris
>
[snip stuff that still needs discussing]
> * identify extant code which needs revision due to ACLs -- for
> example, Posts::get() needs to only fetch those content types to which
> the current user (who could be an anonymous not-logged-in visitor) has
> permission to see.
View is the broadest permission, so it makes sense that Posts::get()
returns all the user can see. It will be more challenging to
efficiently check things like delete and moderate. We don't want to be
checking delete permissions on individual comments if there are a
million spams.