[Gsoc] proposal suggestions

[Martijn Faassen]

Hi there,

On Tue, Apr 1, 2008 at 9:51 PM, Jesper Petersen <instantfoo at gmail.com> wrote:
[snip]
> "Grok user and group management. Grok currently supports Zope 3's
> authentication infrastructure, but there's quite a bit to glue up before you
> can have users and groups. Look into simplifying the out of the box
> experience, while retaining flexibility."
>
> Are we talking about a sort of 'sanctioned' product for user management here
> (credentialsplugin, authplugin, fancy admin gui).. or simply tools to make
> rolling your own solution a piece of cake (which i believe is what is
> meant). I looked a bit at a very simple login solution here..
> http://svn.zope.org/grokapps/LoginDemo/ and I must say it does look a bit
> too Zope3:ey ;)
> Sorry for not having browsed through the grok code that much, but what
> glueing is needed for users and groups? I noticed e.g grok.admin.view.Users
> being unusable at the moment (import errors), is it only some glue missing
> or maybe we don't even have anything to glue together ;)

I think what's missing is some standard behavior. If you want to do
authentication and authorization in a Grok application now, you'll
have to roll your own UI and, in part, your own objects to store users
and groups in (though PrincipalFolder helps). As you can see in
LoginDemo, there's a lot to hook up, and there are multiple ways to
hook things up, and when you get started you obviously have no idea
what goes where yet.

In Zope 2, the nice thing is that you have a user folder which may be
limited, but you can let people log into your application right away.
It has an UI. For Grok, I think we'd need a UI for a login screen,
managing users and groups and, possibly, assigning roles to users in
particular locations. These would ideally be UI components you can
reuse in your project but don't have to, and can somehow be modified
or plugged into. We should be careful not to lay too much pluggability
in the UI though - people will likely want to be able to replace the
entire UI anyway.

You could then also think about UIs for other backends, such as a UI
for managing users maintained in a relational database.

Along with that we'd also need some documentation of best practices
(not strictly part of the SoC).

Regards,

Martijn