>>I think I would second the idea of having a single component/database that is >>responsible for the management of user information.
The problem is that the larger Mailman ecosystem is designed to be a loose collection of components so there is no way to define what information each component needs stored at the Mailman Core. It wouldn’t make sense for the data store requirements of Postorius to be baked in to the Mailman Core data structures because Postorius is an optional component of the Mailman suite. In the case of your original question: >>>However, I am having some trouble understanding the procedure of granting >>>users access to the Postorius webinterface. Whether or not a user has access via the web interface is application specific to Postorius so it should be stored in a local datastore managed by Postorius. It’s both a strength and a weakness that Mailman Core is quite rigid about “taking care only of its own business”. The big benefit of this strategy is that in future it will continue to be practical to upgrade Mailman Core exactly because it has tightly defined data structures and no knowledge of how other applications in the ecosystem behave. Customised data structures in the Mailman Core would lead to major issues in forward compatibility - imagine the nightmare of trying to upgrade Mailman Core if it included application-specific customisations that had been wound in over time - it would be like chewing gum in your hair - you’d never get it out. The important thing is that Mailman Core provides a resource permissions model that can be leveraged by other servers such as Postorius so that the central store of Mailman user authorisation information can be applied to application specific data stores. Which is to say, Postorius (or any other application) can store data using the Mailman userid, and can check with the Mailman Core to see if it is a valid user. Mailman Core’s commitment to minding its own business is a good compromise - its not ideal but it’s not that bad either - the key thing for third party application developers to understand is that Mailman provides a unique ID for every resource (users, domains, lists etc), and provides a permissions model that defines which of these resources users have access to. Third party applications can connect logically to this conceptual framework in a fairly loosely coupled manner. as _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
