Re: [mlmmj] undesired help emails

[Ben Schmidt <mail_ben_schmidt@yahoo.com.au>]

On 7/10/10 12:47 AM, Ben Schmidt wrote:
>> Perhaps a variation where a postheaders tunable contained headers to be
>> added to list posts would be sensible. Then customheaders would be added
>> to all mails, but listtexts and postheaders would define headers at a
>> finer grain. The override order and behaviour would still have to be
>> carefully considered.
>>
>> Any of these changes would be a behaviour disruption, and potentially
>> break compatibility, so would wait until a fairly major release to come
>> through.
>
> I have filed this as a feature request to remind myself of it, for
> consideration later as part of a more major update.
>
>> I guess adding a listid tunable isn't out of the question, though if we
>> went down that road I'd want to carefully consider how to best structure
>> it for possible future use by mlmmj itself.
>
> Ditto.
>
>> Another thought...What about a generic $tunableX$ substitution that
>> pulls the text out of the given tunable X? That would enable you to do
>> as much list-specific stuff as you wanted, and although it seems pretty
>> powerful and a candidate for exploitation, I don't think it would open
>> any security holes.
>
> Since this is a compatible change that shouldn't cause disruption, I
> have implemented it, as a $controlN$ substitution. I have given it a
> quick test and it seems to work.
>
> Robin, might you be able to pull the current sources from hg and give it
> a test? I believe the code there is fairly stable, though there are a
> number of changes awaiting review, so I'm not yet wholly confident and
> wouldn't recommend it for production use just yet.
>
> Perhaps this is wishful thinking, but is there any chance you'd be able
> to code-review the change, too? Are you a C-programmer? It is here:
>
> http://mlmmj.org/hg/mlmmj/rev/ecb991e41a4c

Missed a #include before. Added as a new change now.

http://mlmmj.org/hg/mlmmj/rev/bb803487199c

>>>> I'll look at your specific examples in more detail later. Thanks for
>>>> forwarding them.
>>> The bulk header should cut a lot of them.
>
> I think let's focus on getting the relevant changes into production so
> that you can test this, and report back if the problem still exists and
> needs work.
>
> Cheers,
>
> Ben.