[Mailman3-dev] Mailman Design

[Ian A B Eiloart]

>>> However, the question is really what power we'll give users to change
>>> the u/i through the web.  Site admins with access to the file system
>>> will definitely be able to heavily modify the u/i to their heart's
>>> content.
>>
>> That'll do me, provided that the templates aren't touched during an
>> upgrade.
>
> A good principle but one that begs the question of what policy to apply
> where the whole point of an update is to introduce changed functionality
> which is only available through the templates; err that's everything, is
> it not.

Ah, good point. Here's how I might approach the problem:

Often what I want to do is change the descriptive text - for example I need 
to tell local staff which of their several email addresses they should 
subscribe with, so I add instructions above the appropriate slot.

Perhaps the answer is to parameterise text descriptions, such that one file 
can contain default text, and a site specific file can override those 
defaults. That way, a 'template' wouldn't be plain html, but rather a 
python script which generated html.

New functionality would imply new parameters with new defaults. The texts 
might be edited through the web, and might contain simple formatting 
(lists, emphasis, etc). You could even let admins include and exclude 
certain interface elements through the web (like password reminder choices, 
for example). Again, there could be default and override settings for 
inclusion of elements, but addition of new elements would mean changing a 
default settings file, whereas site specific settings would be unaffected:

So, a 'template' for a sign-on page might look like this pseudo-code:

> read /local/mailman/defaults/sign-on.settings
> read ${local-settings-path}/styles/${list.style}/sign-on.settings
> read ${local-settings-path)/lists/${list.name}/sign-on.settings
>
> if ($sign-on.digest_allowed)
>     echo $sign-on.digest_instructions
>     echo $sign-on.digest_interface
> endif

if fact, if you paramaterised the interface element, then admins could 
choose to change, say, a drop down list into a set of radio buttons.

The default sign-on.settings might contain:
$sign-on.digest_allowed = true
$sign-on.digest_instructions = "Get $list-digest-frequency digests"
$sign-on.digest_interface = "<input type=checkbox name=digest 
value=$list-digest-default>"

Whereas the sitewide settings file may contain:
$sign-on.digest_instructions = "Get $list-digest-frequency digests. <a 
href=blah>click here</a> for our digest policy."

And the list specific settings file may say:
$sign-on.digest_allowed = false

Now, most people wouldn't want to touch the "interface" settings, but many 
may want to change the descriptions.

The list specific "allowed" settings would largely be controlled by the 
list policy settings. However, it would be possible to permit styles by 
providing several site wide settings files.

-- 
Ian Eiloart
Servers Team
Sussex University ITS