Differences between revisions 18 and 19
⇤ ← Revision 18 as of 2010-06-08 13:54:08 →
Size: 5188
Editor: anna
Comment: Migrated to Confluence 4.0
← Revision 19 as of 2012-08-21 13:33:19 → ⇥
Size: 4344
Editor: f@state-of-mind
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DEV/versions/15171625 #pragma page-filename DEV/versions/15171627
Line 4: Line 4:
This page should serve as a place to update everyone on the current state of development, but also to discuss the progress and/or decisions being made while developing. Suggestions about the UI can be made on [[../Suggestions for new Mailman 3.0 UI|this page]]. == Postorius ==
Line 6: Line 6:
== Components == Postorius is the main component of the administrative interface of Mailman 3. It is an application based on the Django framework and is currently in alpha state. The project is hosted on Launchpad:
Line 8: Line 8:
The Mailman Web UI consists of three components: [[https://launchpad.net/postorius|https://launchpad.net/postorius]]
Line 10: Line 10:
 1. a '''REST client module''' that handles all communication with Mailman
 1. "'''mailman-django'''": a reusable Django app that makes use of the client module and delivers the web front-end
 1. a '''django project/site''' that includes mailman-django		 Currently Postorius has all basic management features, like creating lists and domains, editing list settings, moderating messages and, of course, (un)subscribing to/from lists. Authentication is handled by Django's own authentication app, or optionally by Mozilla's BrowserID service. So far it cannot handle roles 
Line 14: Line 12:
Why not just ship one thing? Because this way we cover a number of different scenarios, i.e.: Postorius uses mailman.client, the Python bindings to Mailman's REST interface:
Line 16: Line 14:
 * Use 1., 2. & 3. if you have Mailman installed but are not running an existing Django site.
 * Use 1. & 2. if you already have an existing Django web site and would like to extend it with a Mailman interface.
 * Use 1. if you are developing a completely different Python application that needs to communicate with Mailman.		 [[https://launchpad.net/mailman.client|https://launchpad.net/mailman.client]]
Line 20: Line 16:
=== The REST client module === === [[https://launchpad.net/postorius|https://launchpad.net/postorius]]Road map ===
Line 22: Line 18:
A current draft contains two classes: This is the road map for the next alpha relase:
Line 24: Line 20:
'''MailmanRESTClient:''' Methods names CRUD-like: create_list(), read_list(), update_list(), delete_list(), get_lists(), subscribe_list(), leave_list() etc. [[https://launchpad.net/postorius/+milestone/1.0.0a2|https://launchpad.net/postorius/+milestone/1.0.0a2]]
Line 26: Line 22:
'''MailmanRESTClientError:''' Exception Class Ideas, features and topics for the next releases (just a draft - feel free to add more. If you don't like what you see, add a comment or send an angry post to the dev mailing list):
Line 28: Line 24:
It currently uses urllib and urllib2 to talk to Mailman but this has to be changed to use httlib to make use of the DELETE and PUT request methods (since Mailman's REST server now uses Restish).  * Permissions: Add missing authentication/authorization functionality (roles etc...).
 * Integration with other Mailman UI projects (HyperKitty, Mailman Metrics).
 * Anonymous subscriptions
 * User profile pages
 * Code refactoring and testing: Switch to Django class-based views to reduce redundancy and make testing easier.
 * Todo-functionality
 * UI enhancement: Ajaxify static pages where appropriate, evaluate local/offline storage for speed. 
 * Add responsive CSS styles for mobile phones.
 * mailman.client: Change package name to stop it from breaking the Mailman test suite.
 * mailman.client: Evaluate switching to `requests` as http library instead of httlib2.
 * mailman.client: Tests: Move mocking from mocker to mock
Line 30: Line 36:
Note: The client module should be part of the Mailman core source to integrate it into Mailman's testing routine. But it should also be distributed as a stand-alone Python module.
Line 32: Line 37:
=== mailman-django ===
Line 34: Line 38:
A reusable Django app. Lives outside the Django project folder, somewhere on the Python path. Directory structure so far: === Development ===
Line 36: Line 40:
{{{
 mailman-django/
    media/
        mailman-django/
            css/
            img/
            js/
    templates/
        mailman-django/
            lists/
            members/		 A quick 5 minute guide (if you're lucky) to get Postorius installed for development can be found here:

[[../A 5 minute guide to get the Mailman web UI running|A 5 minute guide to get the Mailman web UI running]]

A guide to hook Postorius up to Apache is part of the Postorius documentation:

[[http://packages.python.org/postorius/setup.html|http://packages.python.org/postorius/setup.html]]

Some preliminary notes on testing new code in Postorius (this is still a draft...):

[[http://packages.python.org/postorius/development.html|http://packages.python.org/postorius/development.html]]



== Systers ==

{{{#!wiki important

Note

This section has been unchanged for a while and is possible outdated. 
Line 49: Line 63:
The "mailman-django" folders inside "media" and "templates" may seem redundant but help maintain clarity and prevent conflicts when integrating the app into an existing environment.

=== Systers ===

Alongside the general web ui an extra django app for the Systers mailing list is being developed as part of Anna Granudd's GSOC project:		 Alongside the general web ui an extra django app for the Systers mailing list was developed as part of Anna Granudd's GSOC project:
Line 81: Line 91:

=== The Django website/project ===

Contains the standard set of files when doing:

{{{
django-admin.py startproject mailmanweb
}}}

Could further be reduced to keep only settings.py and urls.py.

mailman-django is included by adding it to INSTALLED_APPS in the project's settings.py:

{{{
INSTALLED_APPS = (
    'mailman-django'
)
}}}

.... and by adding it to urls.py:

{{{
urlpatterns = patterns('',
    (r'^mailman/', include('mailman-django.urls'))
)
}}}

=== Applications in Django ===

The current plan is to have one standard django apps for the UI but discussions have been made to make it two: one for the admin site and one for the user sites. This will make the project more lucid. It is also possible to add more apps for organizations that wish to customize their views or add additional fields.

== Test Server ==

A test server with a basic setup of the web UI is currently being set up.

== Features to be implemented first ==

 1. Ability for users to subscribe, manage subscriptions, unsubscribe, change emails
 1. Admin ability to create/delete lists via pre-defined styles
 1. Users ability to customize their subscirptions
 1. Moderation
 1. Site admin ability to create domains, add and modify styles
 1. List admin ability to customize lists

Web UI - Status

Postorius

Postorius is the main component of the administrative interface of Mailman 3. It is an application based on the Django framework and is currently in alpha state. The project is hosted on Launchpad:

https://launchpad.net/postorius

Currently Postorius has all basic management features, like creating lists and domains, editing list settings, moderating messages and, of course, (un)subscribing to/from lists. Authentication is handled by Django's own authentication app, or optionally by Mozilla's BrowserID service. So far it cannot handle roles 

Postorius uses mailman.client, the Python bindings to Mailman's REST interface:

https://launchpad.net/mailman.client

[[https://launchpad.net/postorius|https://launchpad.net/postorius]]Road map

This is the road map for the next alpha relase:

https://launchpad.net/postorius/+milestone/1.0.0a2

Ideas, features and topics for the next releases (just a draft - feel free to add more. If you don't like what you see, add a comment or send an angry post to the dev mailing list):

  • Permissions: Add missing authentication/authorization functionality (roles etc...).

  • Integration with other Mailman UI projects (HyperKitty, Mailman Metrics).

  • Anonymous subscriptions
  • User profile pages
  • Code refactoring and testing: Switch to Django class-based views to reduce redundancy and make testing easier.
  • Todo-functionality
  • UI enhancement: Ajaxify static pages where appropriate, evaluate local/offline storage for speed. 
  • Add responsive CSS styles for mobile phones.
  • mailman.client: Change package name to stop it from breaking the Mailman test suite.

  • mailman.client: Evaluate switching to requests as http library instead of httlib2.

  • mailman.client: Tests: Move mocking from mocker to mock

Development

A quick 5 minute guide (if you're lucky) to get Postorius installed for development can be found here:

A 5 minute guide to get the Mailman web UI running

A guide to hook Postorius up to Apache is part of the Postorius documentation:

http://packages.python.org/postorius/setup.html

Some preliminary notes on testing new code in Postorius (this is still a draft...):

http://packages.python.org/postorius/development.html

Systers

Note

This section has been unchanged for a while and is possible outdated. 

Alongside the general web ui an extra django app for the Systers mailing list was developed as part of Anna Granudd's GSOC project:

The plan is that there will be the "normal"/standard UI/app which only uses the core DB and accesses this via the rest client. However, with the help of Django one can add databases which can be used for alternative UI's, such as the one from Systers. The extra DB could, for instance, include the following tables and content (although with this content the user table is probably redundant and can be removed):

Table "user"

  • id integer not null (to connect to core db), PK
  • URL text (specific "link_id" for each user)
  • required_id integer (connects to the "required" table)
  • web_url text (if someone, for instance, wish to add a link to a blog or similar)

Table mailing list

  • id integer not null (to connect to core db), PK
  • URL text (specific "link_id")
  • picture base64-encoded (if, for instance, the organization using the mailing list wants to add a logo)
  • dlist_enabled boolean (Systers specific)
  • questions_essay text (Systers specific)
  • required_id integer (connects to the "required" table)

Table required

  • id integer not null, PK
  • fullname_req boolean (Systers specific, possibly for core as well)
  • essay_req boolean (Systers specific)
  • picture_req boolean (although we'll probably want to make this optionally)

Of these, the mailing list and the user tables are already present in core and would be extended with this information.

MailmanWiki: DEV/Web Interface Status (last edited 2015-01-12 00:15:05 by SumanaHarihareswara)