[Mailman3-dev] Flexible data storage
Ian A B Eiloart
iane at sussex.ac.uk
Tue Mar 16 11:12:08 EST 2004
--On martes, 16 marzo 2004 09:36 -0500 Barry Warsaw <barry at python.org>
> On Tue, 2004-03-16 at 08:38, Ian A B Eiloart wrote:
>> I've said before that I'd like to manage internal users (members of the
>> University) differently than external users. If we could eliminate the
>> sending of passwords to internal users (we manager their passwords in
>> LDAP), and also guarantee that external users only had one password in
>> the database, that would cut the number of reminders drastically.
> That's an interesting use case, although I think Mailman itself should
> largely be ignorant of whether they are internal or external users.
> The way I've been thinking about it ties back to the roster notion.
> Rosters may be tied via conduits to a back-end storage, and each storage
> would have its own policies for reading and writing.
Well, if a roster is a membership list which can be included in another
membership list, then that's OK.
I need to have rosters with heterogeneous membership though. Some members
from one conduit, and others from another.
And, I want mailman to be able to tie "sussex.ac.uk" email addresses to a
particular conduit. My read only LDAP conduit as it happens. I don't want
people in that domain (or susx.ac.uk) to be able to register through
Further, I want some lists to be tied to a specific conduit. I don't want
people subcribing to "staff at sussex.ac.uk" unless they have a sussex email
> Take our Students list example. You might have some grad students who
> were also employees of the university, so they'd be in the employee
> database. Perhaps you couldn't write password updates to that database
> through the Mailman conduit. But the GradStudent list would be composed
> of a non-employee roster (which Mailman managed completely) and an
> employee roster (which Mailman imported through a conduit).
Er, what's a GradStudent? Is that a current student who already has a
degree (a post-graduate), or someone who graduated here but isn't a student
(an alumnus). We don't use the term "grad student" in the UK. Anyway, all
current students are on our LDAP database, along with the staff. Alumni
aren't - they'd be an example of an external user.
Regarding rosters: I'd like to be able to fetch rosters with SQL queries
from a separate database. So, I want to populate lists from ORACLE, but
then get email addresses for each list member from LDAP, and when users log
in, I want to authenticate against the LDAP database.
Then, I'd like to be able to create a list membership with full boolean
rules. For example, I'd like to have a list lifesci-ug-1 whose membership
was lifesci-ug AND ug-1 (composed of first year undergraduates in life
sciences). Or science-ug-1 defined as "(lifesci-ug OR scitech-ug) AND
ug-1". Or local-ug defined as "ug AND NOT overseas-ug"
Caching these memberships would be useful for performance. A 24 hour cache
would be acceptable.
Finally, for each list, I'd like the list admin to be able to configure the
role-based membership, and then maintain a list of additional members
(perhaps a tutor, technician or an *external* examiner) and a list of
exceptions (no, I don't know why). I guess the additions and exceptions
would just be two more rosters, perhaps. So the real rule for, say
science-ug-1 would be "((lifesci-ug OR scitech-ug) AND ug-1 OR
my-additions) AND NOT my-exceptions" where my-additions and my-exceptions
were special rosters for each list.
I guess the default membership rule for a list would be "my-members", a
synonym for "my-additions".
So, a roster might be the result of an SQL query, or an LDAP query, or a
list from a flat file or python database. But, it might also be any boolean
combination of other rosters.
Sussex University ITS
More information about the Mailman3-Dev