[Mailman-Developers] Re: edit moderated messages?

[David Champion]

On 2001.08.14, in <25236.997812283@2wire.com>,
	"J C Lawrence" <claw@2wire.com> wrote:
> 
> Not sure you meant this to be off-list.

I did originally, since I didn't think my comment was good enough to
waste everyone's time, just yours. :) Seems fair for the list now,
though; I'm cc:ing, and giving my quotation scalpel a much-needed rest.

List: this has to do with proposed features for moderated (read:
editable) approval in admindb. I initially objected (privately) to JC's
comment that editing the raw text was an advantage, on the grounds that
it's not actually *that* useful for most moderators I know (and might be
very confusing, to boot) -- but I agree with the principle that power
for those who can wield it is good. Here's a common ground we arrived
at.


> On Mon, 13 Aug 2001 18:14:12 -0500 
> David Champion <dgc@uchicago.edu> wrote:
> > On 2001.08.13, in <19981.997743783@2wire.com>, "J C Lawrence"
> > <claw@2wire.com> wrote:
> 
> >> How about:
> >> 
> >> The edit interface by default exposes an editable text area for
> >> each text/* parts in the message, and keep/delete radio buttons
> >> for each of the non-text/* bits possibly along with an immutable
> >> text representation.
> >> 
> >> A further button can be hit to render the entire message in an
> >> editable textarea.
> 
> > That basically sounds good to me, as a first step. Ultimately I'd
> > like to see it rendering certain attachment types, but there's no
> > reason to demand this now in the absence of the same feature in
> > the archiver. :) 
> 
> Quite.

Also: I'd be happy enough never to have it; I just think it would be
nifty if that ever did arrive.


> > 1. I'd put keep/delete radios on the text parts, too -- it might
> > not be obvious to Joe User that deleting all text in a textarea
> > implies removal of the mime part, and it might be easier, too.
> 
> <nod>
> 
> > 2. Maybe another button on each non-text component would allow
> > download of the decoded binary object. That might be a bit much to
> > add in now, but it would be most useful for review purposes. "Is
> > this an inappropriate image/jpeg attachment, or can I let it
> > through?" Hard to know if all you see is base-64, and you don't
> > have a MIME-spec base-64 decoder.
> 
> A link which hits a CGI which returns the binary stream of the
> base64 (if needed) processed blob would do just fine.  If we want to
> get *really* fancy we could then even do MIME types handling, but I
> don't see that's worth bothering with initially.

Yes, links are fine... I didn't really mean to limit it to a form
element, and there's no reason I can see to do it that way.

It works for me with or without content-types in the HTTP header -- I
expect an octet-stream is sufficient for most cases, but MIME types
might be nice for others. Actually it's probably not that hard to add,
if you just assume (as Mailman ought) that the MIME header knows what
it's talking about.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago