Re: [Mailman-Developers] [Project Discussion] Approach for Implementing Admin Tasks
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mon, 25 May 2015 17:19:17 +0530 Bhavesh Goyal <bhavesh.goyal093@gmail.com> wrote:
Widget Specifications:
The Tasks widget gives the admin, a list of pending tasks which require his immediate attention on the dashboard. The tasks particularly include those of 'Held Messages' (pending for moderation) and 'Subscription Requests'. A Task is added to the To - Do List for admin automatically, whenever a message sent by an user to a list is held for moderation or whenever a user makes a request for a subscription (through list-join).
That Being said, I ve made a prototype for The widget 'model' which adds a 'task' entry for the admin, whenever a new message is queued for moderation or a subscription request is made (through list-join). The model can then further be iterated to create views for postorius to generate list of all tasks to be displayed on the dashboard.
Approach :
The 'Tasks' model and the REST API used to query the model are implemented in the core
I think a better idea would be to keep everything in Postorius. Held
messages and subscription requests are already available through the
REST API, and hence can easily be used to create the Tasks model in
Postorius.
Barry, Florian thoughts?
thanks, Abhilash Raj -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVYw4jAAoJEJ2bK6Bh0KZ8AisP/05yxnMO0xG/Ye82QRHIm6mv 1wncgXvNL2UG7qW8pQevFQaAnhf5zrb4DZA12qFtYUGMbArWfpE5dDNyAaRrKQBT joKb9p/tvAwIS1aqH7fudcU7p60jgluoHDs4KfR39jNPgSZSkrv2z5jlZiLJew5X bZt6S/28fYH9nqYAFueoR4SnLIVCLA3SQ6tkuywPKPbPqT7DsHk1lQHcJdZVa/zu zKtgj5lsrALAMlL1vMuGll5CCPLRlzHjCud646KDQse1Vm/lzjcqtacq7LO2D4CN qEcnWfPbWtKVjiYF8le0kSlumGJ754t/drxty9ZZGEWAOinZVQ0gkiHRcNQpdo5V 4nePnLYZlx0SFY1E+3mIouqO0lpwMXY6IY1zw2gd9Uu8/XI9D3+vLcdwZF7yGYHl 7p7G03B//zg9Qd3I/PaCjDKUDAFu5otphSCylN392nPenUrznfQef/t7MQQFepqc kVP43O4rBo1OwEumuFRjs9FcC8sAi2RVoH+CvYXv36xBMALJtERm0q0gg8Xt0AIy LvkqQ+tHtcljoMwLXpe0Z3TqNO4V1VbjHMOCUIvmdGUx4r0gBD6hrEM3mgr+Xcg5 JHswGOswDiG/CDS66Ksn0PWD6EC9BvQAi+HUyD03rHYwlsbanwM+CtE9crb1GxF1 oSp4R3qdwtDO/+13Dx2z =AZeK -----END PGP SIGNATURE-----
On May 25, 2015, at 05:27 PM, Abhilash Raj wrote:
I think a better idea would be to keep everything in Postorius. Held messages and subscription requests are already available through the REST API, and hence can easily be used to create the
Tasksmodel in Postorius. Barry, Florian thoughts?
It was a long USA holiday weekend so I haven't had time to read the detailed proposal, but I think what Abhilash suggests has a lot of merit. The internal representation of subscription requests underwent a big change during Pycon, where the subscription policy work landed. There will be changes soon for unsubscription policy support. It's also possible that held messages will be handled differently in the future. The intent is to keep the REST API as stable as possible during all this, so if the information is available there (which it is), then it would be safest to just build on top of the existing API.
Bhavesh, can you describe why a task model in the core is a better way to go?
Cheers, -Barry
Barry Warsaw writes:
On May 25, 2015, at 05:27 PM, Abhilash Raj wrote:
I think a better idea would be to keep everything in Postorius.
+1 I really think we should reserve 3.1 for fixing major problems (and I expect to have a lot of user-noticable problems, starting with lots of Mailman 2 functionality that went unimplemented for one reason or another).
I tend to sympathize with Bhavesh. There are a bunch of things that really need help from core. (Authn/z is the gaping wound: a *lot* of people have separate machines for mail and web, but as things stand that's not possible because Postorius has to live on the same host as core).
Bhavesh, can you describe why a task model in the core is a better way to go?
Yes, please do: I'm not 100% sure I agree that it would be useful later in the series, but especially in cases where the conclusion is "let's not" it's best to get a pretty solid argument "for" on record.
It's also good practice. :-)
On May 26, 2015, at 01:26 PM, Stephen J. Turnbull wrote:
I really think we should reserve 3.1 for fixing major problems (and I expect to have a lot of user-noticable problems, starting with lots of Mailman 2 functionality that went unimplemented for one reason or another).
+1.
I do intend to do a 3.0.1 of core at some point soonish to fix a few bugs.
Here's where we can start gathering high level tasks for 3.1:
http://wiki.list.org/DEV/Mailman%203.1
I tend to sympathize with Bhavesh. There are a bunch of things that really need help from core. (Authn/z is the gaping wound: a *lot* of people have separate machines for mail and web, but as things stand that's not possible because Postorius has to live on the same host as core).
I'm not opposed to pulling things into the core where it makes sense. I just want a good rationale, a consistent design, and a logical organization of the API resources.
Bhavesh, can you describe why a task model in the core is a better way to go?
Yes, please do: I'm not 100% sure I agree that it would be useful later in the series, but especially in cases where the conclusion is "let's not" it's best to get a pretty solid argument "for" on record.
There could be some good reasons to implement and expose the task model in the core. One of them might be to provide a better abstraction on top of the currently disjoint implementation of held messages and subscription requests. These currently have different types of ids/tokens and are held in different tables. There might be other benefits worth exploring.
I have some thoughts about how it might be best to implement something like that in the core, but let's not go there yet. If there's a really strong reason to do it, I can outline my implementation thoughts.
Cheers, -Barry
participants (3)
-
Abhilash Raj -
Barry Warsaw -
Stephen J. Turnbull