The mailing list for listmasters using Sympa

[Mark Valiukas <address@concealed>]

Hello,

We've been using Sympa for some time for general mailing lists,
and have just deployed it as a solution for the volume of
global mail that was being generated within our institution -
a problem I'm sure more than one University faces.

However, The Powers That Be have decided that the standard
summary message options available (even through a custom
summary template) are too "confusing" for some users and want
something HTML-ised with friendly links etc.  Okay, it's open
source, I can do this, but there are a number of ways of
achieving this - some of which are probably at odds with the
philosophy of the project. Here are my ideas, and how they
can be done.

I'm not sure my code is quite ready for release yet. I want
to clean it up a little, and sort out where it should go.
There's also the matter of hard-coded template locations
in this extremely pre-alpha proof-of-concept...
However, to show that I'm serious, the code for this hack is
included for those who want it. Sorry, no diff at this time
because I was already working from a slightly hacked 3.4.4.3

This code implements the following:
- Parses summary.tpl to construct a plain-text message part
- Parses a file I've tentatively called summary.html.tpl to
construct a HTML message part
- Produces a MIME multi-part alternative message
- Mails the multi-part message off to users

(call me a pedant, but I tend to agree with those that believe
a plain-text part should go out with *all* HTML messages)


I also have, but have not included, partially-complete templates
implementing the following:
- Nice, friendly links rather than the clunky URLs
- Nice, friendly links to the List Information, subscription
modification, login etc pages


My questions are:
=================
Would it be more in keeping with the philosophy of the project
to implement it as:
- an extension to the "send summary" code in Lists.pm, with the
HTML summary format being chosen for lists for which a summary.html.tpl
exists
OR
- a separate delivery type (with, of course, a fall-back to non-HTML
summaries if no appropriate templates exist - although it would be
easy enough to provide default HTML summary templates)

At present, as it's a proof-of-concept, it's implemented as a replacement
for the Send Summary code and has the templates it looks for hard-coded
(not a big thing to fix). It can easily be implemented either as an
extension to Send Summary or as an alternate delivery type. The former
has the advantage of fewer changes being needed elsewhere (no need to
add another delivery type, set that type as a valid option etc) but means
that lists with HTML summary templates would force the HTML summary option
on all users wanting a summary - I think this would be a bad thing, as it
decreases available user options. For this reason, my preference is for a
separate delivery type.

My present implementation is very similar to the Send Digest code in how
it actually sends the message - the composition is done using some calls
to &parser::parse_tpl, similar to how it's done within mailfile{}, and a
mime-multipart message is constructed from what's returned from
parser::parse_tpl

If it was to be incorporated into the Send Summary code,
would it be better to implement it like:

IF (HTML template exisits for this list, or globally)
        DO HTML Summary code
ELSE
        DO Standard Summary code
FI

......OR............

find some way to shoehorn it into send_file?

The former appeals to me more, and I suspect to the main
developers, because the Digest code has been done this way.
send_file is already quite "busy", and for clarity I think
the last thing it needs is to do something quite different
from what it already does. But that's just my view, and I
have only been looking at the code a few weeks.



So:

Our users have requested this as a feature - is this a feature
other sites might find useful, once its finalised?

Where should it go in the code? Is it worthy of another
delivery type, or should it be an optional summary type?
(I'd prefer another delivery type, for maximum user
flexibility - and maybe templates called summary.html.tpl
and summary.text.tpl in order to maximise site-specific
customisation options)

I think it's about 3/4 done already - it's mostly just minor
matters like where to actually put the code that need to be
resolved, hence these questions.


All feedback, even if just criticism of my coding style
and choice of variable names, is more than welcome. Once I
know where it should go, I'd be more than happy to provide
diffs of the finalised version against 3.4.4.3 and whatever
the current 4.0 beta is at that time.


Regards,

--
Mark Valiukas
Systems Programmer
ITS Networks and Computing Branch
Victoria University of Technology
        ## send summary - modified by Mark Valiukas
        if (@tabrcptsummary) {
                $param->{'subject'} = sprintf Msg(8, 31, 'Summary of list 
%s'), $self->{'admin'}{'subject'};
                #$self->send_file('summary', \@tabrcptsummary, $robot, 
$param);
        my $mv_msg = MIME::Entity->build (
                To         => $param->{'to'},
                From       => $param->{'from'},
                'Reply-to' => $param->{'reply'},
                Type       => 'multipart/alternative',
                #Subject    => MIME::Words::encode_mimewords(sprintf "HTML 
Summary of list %s",$listname)
                Subject    => MIME::Words::encode_mimewords(sprintf 
"%s",$param->{subject})
                );

                my $charset = sprintf 'us-ascii';
                local $/ = undef;


                my $related = MIME::Entity->build (
                        Type    => "multipart/related"
                        );


                my $name = $self->{'name'};
                foreach my $p 
('email','host','sympa','request','listmaster','wwsympa_url','title') {
                        $param->{'conf'}{$p} = &Conf::get_robot_conf($robot, 
$p);
                }

                $param->{'list'}{'lang'} = $self->{'admin'}{'lang'};
                $param->{'list'}{'name'} = $name;
                $param->{'robot_domain'} = $robot;
                $param->{'list'}{'host'} = $self->{'admin'}{'host'};
                $param->{'list'}{'subject'} = $self->{'admin'}{'subject'};
                $param->{'list'}{'owner'} = $self->{'admin'}{'owner'};
                $param->{'list'}{'dir'} = $self->{'dir'};


                my @blah_data;
                my $test_blah;
                $test_blah = \@blah_data ;
                
parser::parse_tpl($param,"/home/sympa/expl/mjv-test/test-text.tpl",$test_blah);

                my $blah_content = \@blah_data;

                my $blah = MIME::Entity->build (
                        Type        => "text/plain; charset=$charset",
                        Description => 'TEXT summary',
                        Data        => $blah_content
                        );

                $mv_msg->add_part($related);
                $mv_msg->add_part($blah);
                $mv_msg->add_part($barf);

                my $mv_new_msg = $self->add_parts($mv_msg);
                if (defined $mv_new_msg) {
                        $mv_msg = $mv_new_msg;
                }
                &smtp::mailto($mv_msg, $param->{'return_path'}, 'none', 
'_ALTERED_', @tabrcptsummary);

        }