Archiving from DEV/Web Interface Status as it is now obsolete.

Current Features

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

Systers

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.