The mailing list for listmasters using Sympa

[address@concealed]

To be more concrete, the company is a non-governmental organisation,
each department has some volunteers involved.  We want to permit all
employees creating lists freely, while lists proposed by volunteers
will be pended and later installed by these employees.  That each
employee can install only those lists proposed by the volunteers of
his/her department is too complicated and not necessary.

As you can see, the number of potential list requesters is large,
and their needs divergent.

# pm5

On Tue, May 06, 2003 at 10:07:31AM +0200, Olivier Salaun - CRU wrote:
> You're right, server admin functions are not controlled by scenarios,
> because it seemed to
> make things too complicate without much gain.
> 
> I'm afraid I can't propose you any solution...
> 
> How will you express the relationship between :
> * the one who request a new list
> AND
> * the person who will be responsible for valiodating this list
> 
> address@concealed wrote:
> 
> >We are going to deploy sympa in a company with several departments.
> >
> >Each department demand several lists, and they are for various
> >purpose.  A central small group of listmasters couldn't possibly
> >understand all their needs and decide if the reasons are qualified
> >on their own.
> >
> >Opening the creat_list permission to the intranet would solve part
> >of the problem, but we're looking for a better solution.  Some of
> >the departments still want to moderate their list creation, possibly
> >by someone(the chief maybe) inside the department.
> >
> >Making the chief one of the listmasters is not feasible, because
> >there are many departments with many lists and their own read/write
> >permission, but a listmaster can always read/write anything.  We
> >want to limit the chief's admin right to installing pending lists,
> >possibly removing closed lists, but no more.  You might call it
> >``moderators/editors on list creation.''
> >
> >Since the listmaster and server admin right part of sympa seems
> >not ``scenarilized'' yet, I guess we'll have to patch the code
> >a bit to achieve this.  The question is, how should we do this
> >appropriatly, i.e. without writing too much code.
> >  
> >
> 
> -- 
> Olivier Salaun
> Comite Reseau des Universites
>