Postorius

Merge lp://staging/~sophron/postorius/create_users into lp://staging/postorius

create_users
Merge into trunk

Proposed by George Chatzisofroniou on 2012-10-13

Status:	Merged
Merged at revision:	93
Proposed branch:	lp://staging/~sophron/postorius/create_users
Merge into:	lp://staging/postorius
Diff against target:	273 lines (+187/-2) 9 files modified src/postorius/forms.py (+35/-0) src/postorius/templates/postorius/base.html (+1/-0) src/postorius/templates/postorius/menu/mm_user_nav.html (+8/-0) src/postorius/templates/postorius/users/index.html (+32/-0) src/postorius/templates/postorius/users/new.html (+12/-0) src/postorius/templates/postorius/users/summary.html (+17/-0) src/postorius/urls.py (+6/-1) src/postorius/views/generic.py (+22/-0) src/postorius/views/views.py (+54/-1)
To merge this branch:	bzr merge lp://staging/~sophron/postorius/create_users
Related bugs:	Link a bug report

Reviewer	Review Type	Date Requested	Status
Florian Fuchs		2012-10-13	Approve on 2012-10-25
Review via email: mp+129567@code.staging.launchpad.net

Description of the change

I worked on this bug: https://bugs.launchpad.net/postorius/+bug/1058445

I added the feature to create a mailman user account, but in order to edit the basic user data via the web interface, some additions to mailman client are required. See, https://bugs.launchpad.net/mailman.client/+bug/1066352 and https://bugs.launchpad.net/mailman.client/+bug/1066343.

We also need an icon for the new entry on the menu: https://bugs.launchpad.net/postorius/+bug/1066340

I think it's better to divide the whole 'edit user' feature into smaller ones (delete user, register addresses to a user, basic data edit, etc).

lp://staging/~sophron/postorius/create_users updated on 2012-10-13

92. By George Chatzisofroniou on 2012-10-13: Added the required templates for users

Revision history for this message

Florian Fuchs (flo-fuchs) wrote on 2012-10-25:

Hi George,

thank you for your changes (and the bug reports)! I have just merged them to the trunk. I only made some very small changes and additions (adjusted the docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I also made the user list and details only available to superusers (I don't think every user should be able to see who else is there...).

So now that we have a method to add new users to the core, we need a way to connect them to the users in the postorius database (the ones added through django.contrib.auth). I added some comment about that in the bug description:

https://bugs.launchpad.net/postorius/+bug/1058445

Cheers and thanks again
Florian

review: Approve

Revision history for this message

Richard Wackerbarth (wacky) wrote on 2012-10-25:

Isn't the visibility of the list members a per_list policy setting?

In any case, we will need to have list administrators (who are not the superuser) be able to see the membership on their list.

I think that Postorius will require a better model for roles.

Richard

On Oct 25, 2012, at 3:19 AM, Florian Fuchs <email address hidden> wrote:

> Review: Approve
>
> Hi George,
>
> thank you for your changes (and the bug reports)! I have just merged them to the trunk. I only made some very small changes and additions (adjusted the docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I also made the user list and details only available to superusers (I don't think every user should be able to see who else is there...).

Revision history for this message

Florian Fuchs (flo-fuchs) wrote on 2012-10-25:

Hi Richard,

2012/10/25 Richard Wackerbarth <email address hidden>:
> Isn't the visibility of the list members a per_list policy setting?

Please not that users/index is not a list of members, but a list of
the users stored in Mailman's core database. The members of a list are
displayed for each list separately and can be accessed only by
superusers and list owners.

> In any case, we will need to have list administrators (who are not the superuser) be able to see the membership on their list.
>
> I think that Postorius will require a better model for roles.

Yes, this is already possible. There are two custom permission
decorators for view functions (list_owner_required and
list_moderator_required) that check if the currently logged-in user is
either the owner or the moderator of a list. Currently those
restrictions are in user on the list members page, the moderation
page, the list settings etc.

Next step is providing forms to make existing users owners and/or moderators.

Cheers
Florian