[Mailman-Developers] GSoC discussion

[Richard Wackerbarth]

On May 8, 2013, at 5:33 PM, Florian Fuchs <flo.fuchs at gmail.com> wrote:

> 2013/5/7 Manish Gill <mgill25 at outlook.com>:
>> Hey guys. This is in response to Richard's email for project discussions.
>> 
>> Richard and I have been having discussion regarding how to proceed with the
>> project and he has been very helpful in getting me started with the project.
>> 
>> Right now, I'm focusing on the internal data representation of various
>> Resources in the system and how they might translate on an API level. So,
>> for example, in trying to expose `MailingList` objects, as of now, there is no
>> way to post messages to a list externally.
> 
> I don't know if posting messages through the API is a priority. I'd
> suggest to start with the more fundamental functionality, like
> creating domains/lists, list configuration, subscribing and
> unsubscribing, adding owners and moderators, moderating subscriptions
> and messages.

I agree. I have ask that he organize the set of objects that he wishes to present and the interactions between them.
For example, "persons", "mailinglists", "configuration parameters", and actions such as "subscribe".

"posting a message" might be an action that gets included on the list. However, it first assumes that there is some "message" object and, additionally, some way to have received it. Only when we have established the context will we be able to determine what capability is already present and what might be needed if we were to add or change it.

But, the same can be said for "subscribe".  Therefore, at this time, I place both of them in the category of "possible interactions" until we have a more complete statement of the system model.

> Regarding owners and moderators: It's true that the core's REST API
> does not expose them as single models, but as membership records with
> a 'role' attribute.

How the -core, or postorius, presents something is not the only factor.
It is perfectly permissible to have alternate presentations of the same data.

The only requirement is that there be a translation to and from the presentation representation and the storage representation.

> In Postorius, the permissions that are granted to each of these roles
> are static, for example a moderator can moderate messages as well as
> subscription requests, but it's currently not possible to create
> groups of moderators that can only moderate messages *or*
> subscriptions. In theory it would be possible to ignore the roles
> given by the core and grant more fine-grained permissions to separate
> groups or users. But (at least for now) Postorius does not do that for
> various reasons.

The "role" model for authorization is quite adequate, even desirable, in a historical sense.
However, it should not be the responsibility of the REST interface to DETERMINE the policy.
Rather, it should IMPLEMENT a policy, whatever it is, that the system installation provides.

Further, there are a number of ways that the policy can be presented.
We should not presuppose how it will be accomplished.

> There has been some discussion on IRC and elsewhere if the public API
> should be implemented as part of Postorius (as the project title on
> the ideas page says) or as separate app. My personal opinion is that I
> don't have a problem with any of the two options. But I *do* think
> that if we provide an "official" admin web ui and and "official"
> public facing REST API, both of them should reflect the role system
> reflected in the core and both should have the same authorization
> logic -- meaning: A list owner/moderator/member in Postorius should be
> allowed the same things as a list owner accessing the public REST API.

I agree that, unless the system is explicitly installed otherwise, it would be confusing if they are not the same.
However, a case can be made for the presence of both a "simplified" version of something (because it is adequate, and less confusing and a more powerful representation (for the "power user") coexisting on the same system.
The presence of the "simple" version should not dictate restrictions on every version

Richard