[HOME] [github] [twitter] [blog] [fml4] [fml8] [北海道] Powered by NetBSD and [nuinui.net] .

case study: hierarchical ML

Consider usual ML's which allows post from registered members. For example, sales 1, 2 and 3 division.

Create sales-1, sales-2 and sales-3 ML. Each division manages each member list. Also, create sales ML other than that to inform the whole sales members. If you send a mail to sales ML, the mail is sent to all members of sales-1, sales-2 and sales-3 ML.

Define the following $recipient_maps in the config.cf of sales ML.

recipient_maps 	+=	$ml_home_dir/../sales-1/recipients
recipient_maps 	+=	$ml_home_dir/../sales-2/recipients
recipient_maps 	+=	$ml_home_dir/../sales-3/recipients

Define $member_maps in the same way to allow post from all sales members:

member_maps 	+=	$ml_home_dir/../sales-1/members
member_maps 	+=	$ml_home_dir/../sales-2/members
member_maps 	+=	$ml_home_dir/../sales-3/members
Instead of $member_maps change, it is simple that you allow post from anybody. If so set
article_post_restrictions	=	permit_anyone

This example is simplest. It is easy to use this style.

If you need to use SQL e.g. MySQL, it is modern. It needs a lot of preparions and operation know-how.

[HOME] [github] [twitter] [blog] [fml4] [fml8] [北海道] Powered by NetBSD and [nuinui.net] .
Copyright (C) 1993-2022 Ken'ichi Fukamachi mail:< fukachan at fml.org >