FAQ
As introduced by terry yesterday I'm the one who will support the
development of the WebUI which should be published together with MM3 -
or even better as a standalone Django Application using the REST-Api.

Those who already saw my Blogpost know what I'm talking about now - the
new menu grouping.
I've created a mindmap showing a possible regrouping of menu items.
Florian asked me only to use these which are already available in the
REST API.

Just in case you didn't read my Blog yet - I've attached the image.

Feel free to give any feedback you like,
but I'm especially interested in the following things:

1. Digest ? volume :
Do you really need this internal value to be displayed in the
WebUI ?
2. What do you think about regrouping all List related mail adresses
from General Options to a special "Mail " section
3. Same like 2. but formatting options
4. Sorting out all kind of notifications
5. showing stats within the archives view instead of the config

Thanks for you help improving this work.
benste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mm3_menu_idea.png
Type: image/png
Size: 283724 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110524/b5842390/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110524/b5842390/attachment-0001.pgp>

Search Discussions

  • Barry Warsaw at May 24, 2011 at 12:23 pm

    On May 24, 2011, at 01:39 PM, Benedict Stein wrote:
    1. Digest ? volume :
    Do you really need this internal value to be displayed in the
    WebUI ?
    I think this would only be useful information wherever you had a control to
    explicitly start a new volume. What might actually be interesting is to show
    the current volume number and the accumulated size of the current volume,
    along with a button to explicitly send out the current volume and increment
    the volume number.

    (It might also be interesting to show some historical data about the digests,
    e.g. when they went out and how big they were. This isn't currently being
    collected though.)
    2. What do you think about regrouping all List related mail adresses
    from General Options to a special "Mail " section
    Since those are read-only, it might be useful to have an "information" page
    for the list, detailing useful things like this that can't be changed.
    3. Same like 2. but formatting options
    Same, perhaps?
    4. Sorting out all kind of notifications
    Can you go into more detail?
    5. showing stats within the archives view instead of the config
    Yep. We need to do a much better job of collecting and exposing stats.
    Thanks for you help improving this work.
    Thank *you*!

    -Barry

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110524/702beb20/attachment.pgp>
  • C Nulk at May 24, 2011 at 10:11 pm

    On 5/24/2011 5:23 AM, Barry Warsaw wrote:
    On May 24, 2011, at 01:39 PM, Benedict Stein wrote:

    5. showing stats within the archives view instead of the config
    Yep. We need to do a much better job of collecting and exposing stats.
    I don't know if this is the place to mention it but along with increased
    accessibility to statistics and archives, the ability to look at or
    review the logging information is also very important. Anywhere in the
    code that output's to a log file should provide enough information to
    follow a message coming into Mailman, through the various Mailman
    processes, and out of Mailman. I went through Mailman v2.1.9 to add
    additional logging information so I can track a message. My users call
    on a regular basis to check if their message "went out" to a list they
    can post to but not read (it gets complicated). Once I had the logging
    information (message-id, listname, sender, etc.), I wrote a web app that
    parses the vette, smtp, and post logs and combines the information so I
    can see what happened to the message either by list or by sender. It
    works well for me but additional logging information for tracking
    messages and problems is also need.

    I know I drifted a bit but additional logging is needed and an
    administrative interface to view the information is also needed.
    Thanks for you help improving this work.
    Thank *you*!

    -Barry
    Thank you for the work also. I did view your latest diagram and the
    volume/digest issue seems to be correct. But just to make sure, the
    volume number is increased for every SCHEDULED digest sent out (with the
    digest number reset to 1). Next, any addition digests sent out BETWEEN
    scheduled digests (whether due to size of digest or number of messages
    in the digest) increase the digest number but not the volume number. If
    that is true, then I am in agreement with you :) because it mimics the
    magazine style of volume/issue.

    Thanks for yours and Barry's hard work,
    Chris
  • Mark Sapiro at May 24, 2011 at 10:50 pm

    C Nulk wrote:
    Thank you for the work also. I did view your latest diagram and the
    volume/digest issue seems to be correct. But just to make sure, the
    volume number is increased for every SCHEDULED digest sent out (with the
    digest number reset to 1). Next, any addition digests sent out BETWEEN
    scheduled digests (whether due to size of digest or number of messages
    in the digest) increase the digest number but not the volume number. If
    that is true, then I am in agreement with you :) because it mimics the
    magazine style of volume/issue.

    This is not the way it works in MM 2.1. In MM 2.1, the volume
    increments and the issue resets to one for the first digest produced
    in a new period, where period is Year, Quarter, Month, Week or Day as
    set in Digest options -> digest_volume_frequency. The issue increments
    for each digest produced in that period whether the digest is produced
    'periodically' or by size. If there are no posts/digests produced
    during a period, the volume doesn't increment for that period.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • C Nulk at May 25, 2011 at 2:25 pm
    Yeah, I took a look at what I wrote and I wasn't as clear as I thought I
    was. By SCHEDULED digest, I mean a digest sent out on a set time period
    or frequency (like Years, Months, Weeks, etc.). Those digests would
    have the volume number incremented and the digest number reset to 1.
    Any digests sent within (or BETWEEN) the scheduled digests time period /
    freq. for whatever reason - size, number of msgs - would increment the
    digest number only. If there are no digests/msgs to send, then the
    volume number does not increment.

    Thanks Mark,
    Chris
    On 5/24/2011 3:50 PM, Mark Sapiro wrote:
    C Nulk wrote:
    Thank you for the work also. I did view your latest diagram and the
    volume/digest issue seems to be correct. But just to make sure, the
    volume number is increased for every SCHEDULED digest sent out (with the
    digest number reset to 1). Next, any addition digests sent out BETWEEN
    scheduled digests (whether due to size of digest or number of messages
    in the digest) increase the digest number but not the volume number. If
    that is true, then I am in agreement with you :) because it mimics the
    magazine style of volume/issue.
    This is not the way it works in MM 2.1. In MM 2.1, the volume
    increments and the issue resets to one for the first digest produced
    in a new period, where period is Year, Quarter, Month, Week or Day as
    set in Digest options -> digest_volume_frequency. The issue increments
    for each digest produced in that period whether the digest is produced
    'periodically' or by size. If there are no posts/digests produced
    during a period, the volume doesn't increment for that period.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at May 25, 2011 at 4:32 pm

    On 5/25/11 7:25 AM, C Nulk wrote:
    Yeah, I took a look at what I wrote and I wasn't as clear as I thought I
    was. By SCHEDULED digest, I mean a digest sent out on a set time period
    or frequency (like Years, Months, Weeks, etc.). Those digests would
    have the volume number incremented and the digest number reset to 1.
    Any digests sent within (or BETWEEN) the scheduled digests time period /
    freq. for whatever reason - size, number of msgs - would increment the
    digest number only. If there are no digests/msgs to send, then the
    volume number does not increment.

    That is essentially what I thought you meant, and as I said, that's not
    how it works in Mailman 2.1 (See below)

    digest_volume_frequency and digest_send_periodic are separate,
    independent settings. digest_volume_frequency controls only when the
    volume number changes. digest_send_periodic controls whether or not a
    digest is sent when cron/senddigests runs (default, daily at noon). In
    any case, a digest is always sent when the size of the list's
    accumulated digest.mbox reaches digest_size_threshhold.

    I.e. there are no 'scheduled' digests other than the ones sent daily by
    cron/senddigests and those have no relation to the volume number.

    Even if digest_volume_frequency is Daily, and digest_send_periodic is
    Yes, and digests are sent at noon, a digest triggered on size at 09:00
    will be issue number one of that day's volume if it's the first digest
    of the day.

    On 5/24/2011 3:50 PM, Mark Sapiro wrote:

    This is not the way it works in MM 2.1. In MM 2.1, the volume
    increments and the issue resets to one for the first digest produced
    in a new period, where period is Year, Quarter, Month, Week or Day as
    set in Digest options -> digest_volume_frequency. The issue increments
    for each digest produced in that period whether the digest is produced
    'periodically' or by size. If there are no posts/digests produced
    during a period, the volume doesn't increment for that period.
    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California Better use your sense - B. Dylan
  • Barry Warsaw at May 27, 2011 at 9:09 pm

    On May 24, 2011, at 03:11 PM, C Nulk wrote:
    I don't know if this is the place to mention it but along with increased
    accessibility to statistics and archives, the ability to look at or
    review the logging information is also very important. Anywhere in the
    code that output's to a log file should provide enough information to
    follow a message coming into Mailman, through the various Mailman
    processes, and out of Mailman.
    It is, and I agree! Well, let me say that I definitely think better logging
    is on the table for MM3, and I've been careful to ensure that at least the
    Message-ID is logged for anything that pertains to the disposition of an email
    message. I'm not sure how or if the logging information should be available
    through the web ui (and thus the REST API).
    I went through Mailman v2.1.9 to add additional logging information so I can
    track a message. My users call on a regular basis to check if their message
    "went out" to a list they can post to but not read (it gets complicated).
    Once I had the logging information (message-id, listname, sender, etc.), I
    wrote a web app that parses the vette, smtp, and post logs and combines the
    information so I can see what happened to the message either by list or by
    sender. It works well for me but additional logging information for tracking
    messages and problems is also need.
    One other thing I've been thinking about is a kind of "debug" option where a
    fake message could be injected into the system, with the appropriate headers,
    and out would come some debugging information about which rules got hit, and
    exactly why a message would be held, accepted, discarded, or rejected. I
    haven't thought more about this other than "it would be cool to have" ;).

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110527/213e5a1e/attachment.pgp>
  • Daniel Kahn Gillmor at May 27, 2011 at 9:26 pm

    On 05/27/2011 05:09 PM, Barry Warsaw wrote:
    One other thing I've been thinking about is a kind of "debug" option where a
    fake message could be injected into the system, with the appropriate headers,
    and out would come some debugging information about which rules got hit, and
    exactly why a message would be held, accepted, discarded, or rejected. I
    haven't thought more about this other than "it would be cool to have" ;).
    More than just "cool to have": it would enable people to write more
    tests for the test suite, which in turn makes developers more confident
    in undertaking aggressive re-factorings without fear of breakage. That
    would be a Good Thing.

    --dkg

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 1030 bytes
    Desc: OpenPGP digital signature
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110527/dd3f27ba/attachment.pgp>
  • Barry Warsaw at May 27, 2011 at 9:32 pm

    On May 27, 2011, at 05:26 PM, Daniel Kahn Gillmor wrote:
    More than just "cool to have": it would enable people to write more
    tests for the test suite, which in turn makes developers more confident
    in undertaking aggressive re-factorings without fear of breakage. That
    would be a Good Thing.
    Most definitely. In the meantime, take comfort at least that MM3 has a pretty
    extensive test suite that *actually runs and passes* :)

    -Barry
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 836 bytes
    Desc: not available
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110527/1f80b12a/attachment.pgp>
  • Patrick Ben Koetter at May 24, 2011 at 10:28 pm
    Benedict,

    * Benedict Stein <benedict.stein at googlemail.com>:
    As introduced by terry yesterday I'm the one who will support the
    development of the WebUI which should be published together with MM3 -
    or even better as a standalone Django Application using the REST-Api.

    Those who already saw my Blogpost know what I'm talking about now - the
    new menu grouping.
    I've created a mindmap showing a possible regrouping of menu items.
    Florian asked me only to use these which are already available in the
    REST API.

    Just in case you didn't read my Blog yet - I've attached the image.

    Feel free to give any feedback you like,
    The current (MM2) structure is far too complex. I work with it often and I
    still get lost or spend too much time searching for an option that must have
    been, wait, well where did it ...

    In 2009 I ended up buying tickets for Pycon 2009, visiting Barry to work on
    the MM3 WUI.

    Here's what I came up with (and what I personally still would do):

    The navigation structure should work for the following user groups:

    - subscriber
    - moderator
    - admin

    Each group (in descending order) requires an interface that offers/exposes more
    options. Put the other way around: The interface should hide all options not
    required for a group.

    A user can see the same interface different any time she logs in, IF she acts
    out different roles (subscriber, moderator, admin).

    I think we need to develop a structure that works for all groups and remains
    consistent. No matter which role you own, menu items should always be located
    at the same place.

    I think this can be done best if menu items were rearranged following a
    role/task driven approach.

    Here's a model I've come up with at Pycon 2009:

    The model forsees plugins, something Barry and I discussed to open MM3
    to development by third parties.

    A subscriber could see these items:

    dashboard
    options
    general
    topics
    plugins
    subscriptions
    subscribe
    remove
    modify
    statistics
    List

    A moderator would see more items, building upon the already established
    "subscriber" structure:

    dashboard
    requests
    statistics
    System
    List
    User
    plugins
    plugin 1
    configuration options
    plugin 2


    Finally, an admin would be exposed to all options available through the WUI:

    dashboard
    maintenance
    requests
    options
    General
    Subscription Rules
    Language
    Non-Digest/Digest
    Filter
    Sender
    Recipient
    Spam
    Message
    Topics
    Bounces
    Archive
    Gateways
    Auto-Responder
    Plugins
    subscriptions
    subscribe
    remove
    statistics
    System
    List
    User
    plugins
    plugin 1
    configuration options
    plugin 2


    I've laid all this and descriptions of the various items down in
    <http://wiki.list.org/display/DEV/global+requirements>.

    p at rick


    --
    state of mind ()

    http://www.state-of-mind.de

    Franziskanerstra?e 15 Telefon +49 89 3090 4664
    81669 M?nchen Telefax +49 89 3090 4666

    Amtsgericht M?nchen Partnerschaftsregister PR 563

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 316 bytes
    Desc: Digital signature
    URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110525/2ce04239/attachment-0001.pgp>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-developers @
categoriespython
postedMay 24, '11 at 11:39a
activeMay 27, '11 at 9:32p
posts10
users6
websitelist.org

People

Translate

site design / logo © 2021 Grokbase