It appears that Postorius' Subscription requests view lists all pending subscriptions regardless of whether they are pending user confirmation or moderator approval. Only those waiting moderator approval should be listed.
Although, there could be a different place to see the ones pending user approval, so that a moderator can look and/or delete those.
Edited
Designs
...
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
So how should this issue be fixed? @warsaw Should core be changed so it only returns requests that need moderator action?
Should Postorius also display user pending actions somewhere or not?
@thelinuxguy Good question! Can anybody think of a use case for the moderator to want to view, change, or delete subscription requests that are pending on user action? My instinct is that it would be rare if ever. It wouldn't be needed to clear out expired requests, and if the moderator wanted to say delete a request they know is spammy, the hold would still occur for the moderator later, if the mailing list was set to moderator approval. The only case not handled would be a subscription request to a confirm-only list, but really what's the point?
So I think the core should be changed to only present held subscriptions where the token-owner is moderator. It should be a pretty easy change. Modulo tests, it's a one or two line fix in SubscriptionRequests._get_collection() in src/mailman/rest/sub_moderation.py.
Barry Warsawchanged title from Postorius lists/LIST-ID/subscription_requests lists subscriptions waiting user confirmation to {+In the REST API, /lists/<list-id>/requests should only return held subscriptions waiting for moderator approval, not+} user confirmation
changed title from Postorius lists/LIST-ID/subscription_requests lists subscriptions waiting user confirmation to {+In the REST API, /lists/<list-id>/requests should only return held subscriptions waiting for moderator approval, not+} user confirmation
In general, hardcoding an application's current needs in a core API eventually leads to regrets. So does changing what an API returns after a release.
There might be a case where a spammer created a few hundred thousand subscriptions to a confirm-only list & refused to confirm - constituting a denial of service attack. This would consume disk space, and probably put a dent in the API performance.
Is there a case where a user might want a list of her pending requests? (e.g. to cancel a 3rd party unsolicited subscription. Yes, I know they eventually time out.)
Since it's just as easy, I'd suggest /lists//requests/; you could default to , but accept <user[=fred>>, , <before=date>, etc. Not suggesting that you create an infinite variety of qualifiers now, but this approach would maintain both backward compatibility and allow for future needs.
Each subscription requests from Core includes a field called token_owner, which corresponds who is this subscription request pending conformation from. It should be quite easy for Postorius to filter based on this parameter (change here)
It should also be possible for Postorius to show these two types of pending confirmations separately (pending user approval/pending moderator approval), just so that admins can keep tabs on both of them.
Abhilash Rajchanged title from {-In the REST API, /lists/<list-id>/requests should only return held subscriptions waiting for moderator approval, not user confirmation-} to Postorius' subscription view should show requests pending for moderator approval
changed title from {-In the REST API, /lists/<list-id>/requests should only return held subscriptions waiting for moderator approval, not user confirmation-} to Postorius' subscription view should show requests pending for moderator approval