Differences between revisions 4 and 24 (spanning 20 versions)
⇤ ← Revision 4 as of 2010-05-16 11:08:04 →
Size: 2599
Editor: f@state-of-mind
Comment:
← Revision 24 as of 2012-08-21 13:38:50 → ⇥
Size: 4357
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/10715337 #pragma page-filename DEV/versions/10354696
Line 3: Line 3:
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.
Line 5: Line 4:
== Components ==
The Mailman Web UI consists of three components:		 == Postorius ==
Line 8: Line 6:
 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
Why not just ship one thing? Because this way we cover a number of different scenarios, i.e.:		 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 13: Line 8:
 * 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 entend it with a Mailman interface.
 * Use 1. if you are developing a completely different Python application that needs to communicate with Mailman.
=== The REST client module ===
A current draft contains two classes:		 [[https://launchpad.net/postorius|https://launchpad.net/postorius]]
Line 19: Line 10:
'''MailmanRESTClient:''' Example Methods: get_lists(), get_list(), new_list(), join_list(), etc. Postorius depends on mailman.client, the Python bindings to Mailman's REST interface:
Line 21: Line 12:
'''MailmanRESTClientError:''' Exception Class [[https://launchpad.net/mailman.client|https://launchpad.net/mailman.client]]
Line 23: Line 14:
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). === Current Featues ===
Line 25: Line 16:
=== mailman-django ===
A reusable Django app. Lives outside the Django project, somewhere on the Python path. Directory structure so far:		 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 all previously known user roles (list owner/moderator etc).
Line 28: Line 18:
{{{
mailman-django/
    media/
        mailman-django/
            css/
            img/
            js/
    templates/ mailman-django/ lists/
            members/		 === Road map ===

This is the road map for the next alpha relase:

[[https://launchpad.net/postorius/+milestone/1.0.0a2|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 5 minute guide to get the Mailman web UI running]]

A guide to run Postorius using 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 possibly outdated. 
Line 39: 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. 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 41: Line 65:
=== The Django website/project ===
Uses the standard set of files when doing:		 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):
Line 44: Line 67:
{{{
django-admin.py startproject mailmanweb
}}}		 '''Table "user"'''
Line 48: Line 69:
Could further be reduced to only contain settings.py and urls.py.  * 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)
Line 50: Line 74:
== Test Server ==
A test server with a basic setup of the web UI is currently being set up.		 '''Table mailing list'''
Line 53: Line 76:
== 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. Aite admin ability to create domains, add and modify styles
 1. List admin ability to customize lists		  * 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.

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

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

https://launchpad.net/mailman.client

Current Featues

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 all previously known user roles (list owner/moderator etc).

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 run Postorius using 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 possibly 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)