>>>>> "BR" == Brock Rozen <brozen@webdreams.com> writes:
BR> I was wondering if anybody else besides me had use for a few other
BR> classes of users, namely subscription managers (only get to do
BR> subscriber list related things) and message approval managers (only get
BR> to approve or not approve messages).
For the kind of gross categorization I was talking about, these are just
list owners. But for actual administrative duties you wouldn't want to tie
that to users, anyway. You'd want to tie it to passwords. Ideas for
password stuff:
1. The current (testing) scheme; several passwords, each with a security
level. All security based on required level <= password level.
2. A class scheme. Passwords tied to classes of things; a valid password
in a class can perform that class of actions. Give several passwords
and let list owners choose what they do.
3. Some scheme based on the access restriction we talked about.
4 - oo. Things I haven't thought of that you're going to cook up for me.
BR> Personally, I don't like automatic list creation simply because I don't
BR> want other things fooling around with my aliases file. If OTOH, it
BR> simply created a file that I could insert into my aliases file, that's
BR> a different story.
To each their own; I suppose it could do several things:
1. Disallow list creation altogether.
2. Handle list creation all by itself, given an alias file it can scribble
in. (I don't want to think about the non-Sendmail issue right now.)
3. Do everything it can with its own files (make directories, set up
databases and configs) and mail the installation owner the aliases to
add.
4. Create lots of numbered lists.
- J<
Follow-Ups:
References:
|
|
