[Mailman-Developers] edit moderated messages?

J C Lawrence claw@kanga.nu
Sun, 12 Aug 2001 23:15:15 -0700


On Mon, 13 Aug 2001 00:37:09 -0400 
Barry A Warsaw <barry@zope.com> wrote:

> [Trimming to mailman-developers... -BAW]

Thanks.

>>>>>> "TMP" == Thomas M Parris <parris@isciences.com> writes:

TMP> 1. Can you tell me if anyone is currently working in
TMP> implementing moderated edits?

> JC's right, this has never been supported.  He also points out two
> other good things to keep in mind when thinking about working on
> this: 1) the edited message must (IMO) automatically include some
> kind of prominent disclaimer that it has been edited; 2) the
> current moderation interface doesn't include the entire message,
> and doing so could really bog down the admindb page.

I have ADMINDB_PAGE_TEXT_LIMIT set to 10Meg IIRC, and yes, it does
make admin pages slow when there is a significant moderation queue,
and yes, I'm on a fast connection.  I consider this necessary
however as I require being able to read the entire message in the
moderation queue and not just an excerpt.  

> For #1, I definitely wouldn't want to bury the disclaimer in an X-
> header, which not all MUAs will display.  Perhaps it's best to
> stick something in the footer or header, or modify the Subject:
> line.  I'm not sure.  A little bit of user testing would be in
> order.

An X-header seems the absolute minimum.  A in-message text blob
(possibly in addition to the X-header) seems about the maximum.
There seems little reason not to support either option on a per-list
config basis ala:

  <check_box> [textarea]

    Add the above text above the message contents on any message
    edited by the moderation interface?

And then add a check box to the moderation interface to suppress
this added text blob on a per-message basis (in the group with
preserve_message and forward_message_to).  This would leave the
X-header in place, but not flag the message more explicitly.  This
would be useful when correcting minor typoes and the like which
don't actually change semantic content.

> For #2, I can see two approaches.  Either support only via-email
> editing...

Email-based moderation would be a Good Thing, both at the
approve/reject/discard command level, and at the approve_with_edits
level.

Aside.  I haven't checked if the current beta does this, but
rejection messages should have the entire rejected message as a
message/rfc822 part.  The current business of sending nothing but
the rejection comment back to the poster is causing me considerable
pain.

> ... or reorganize the admindb page so that you can limit the total
> number of messages it displays (and thus the size of the page,
> even given some big messages).

Given spam and mail loops, this seems a generally Good Thing, no
matter the cause.

> I've thought about including the original message in the first
> admin notification that gets sent when the message is held,
> probably as a MIME attachment.  

I'd vote for that.

> I've also thought about including /all/ the held messages as MIME
> attachements for the daily admin notifications.  

I'd vote for that as a configurable option.

> Ideal would be a way to respond to a MIME digested message such
> that you could inform Mailman of the action you want to take on
> it.  Since I think discard is probably the most common action...

No, "defer" should be, just as it is now.  You want the default to
be safe, and the likely actions to be trivially easy.

> ... that one should be the least painful, but all other options
> should be possible.  Unfortunately, I haven't come up with a
> decent email-based UI that wouldn't be error prone.

You realise that the next step will be magic-URL based individual
moderation queue message manipulation don't you? 

> Alternatively, we could simplify the "forward to admin" feature of
> the admindb page.  Then the admin could edit the message and
> resend it (i.e. using Resent-to:).

<nod>

-- 
J C Lawrence                                    )\._.,--....,'``.	    
---------(*)                                   /,   _.. \   _\  ;`._ ,.
claw@kanga.nu                                 `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/                     Oh Freddled Gruntbuggly