2013/5/7 Manish Gill <mgill25@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
MailingListobjects, 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.
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. Postorius reflects the same role system (admin/owner, moderator, member) that is currently implemented in the core (which is also kind of well known from Mailman2).
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.
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.
Florian