API Access to Moderation Queue #1028
Conversation
ix5
added
server
There was a problem hiding this comment.
In general, I think this idea is sensible. A few comments inline.
I don't think you really need a new config option for this though. Either someone has already enabled the admin interface, giving anyone with admin credentials access to all comments, or admin is disabled, which will also disable the new /pending endpoint. My concern is that going at this rate, the whole routing system will at some point in the future be (poorly) exposed through the configuration file.
isso/tests/test_comments.py
Outdated
| self.assertEqual(self.app.db.comments.get(id_), None) | ||
|
|
||
| def testPendingWithoutAdmin(self): | ||
| self.conf.set("admin", "enabled", "false") |
There was a problem hiding this comment.
Are these tests guaranteed to be run in order? I'd prefer you un-set the admin.enabled value at test end.
|
I'm afraid, I will need a couple of weeks to come back to this PR. |
|
Hi @gflohr , any news on this? |
|
I'll try to find time within the next couple of days. |
It works exactly like `/latest` but returns only posts waiting moderation. The endpoint has to be explicitly enabled and requests must be authorized with the admin password. The admin interface also has to be enabled to make sure that people have changed the password.
It should be mentioned that the endpoint /latest only returns accepted comments.
Version 0.13.0 is already released. . Change to the probably next version 0.13.1.
Instead of a separate endpoint /pending, the existing endpoint /latest now has an optional mode parameter.
| The quantity of last comments to retrieve | ||
| @apiExample {curl} Get the latest 5 comments | ||
| @apiQuery {Number{1,2}} [mode=1] |
There was a problem hiding this comment.
can we make these strings? it's hard to remember what these integers mean
There was a problem hiding this comment.
#1028 (comment) suggested the numeric constants. But make a suggestion for string constants.
There was a problem hiding this comment.
mode=pending vs mode=accepted ?
There was a problem hiding this comment.
I have changed my mind after looking a little bit deeper into isso/views/comments.py. The mode property is a number in all API responses. Do you really want to change that to a string for requests?
There was a problem hiding this comment.
Open to the idea of supporting both integers and strings, but I do strongly feel that we should move away from integers.
There was a problem hiding this comment.
But that can only be done in requests. In the responses, it would break compatibility. So what should I do?
There was a problem hiding this comment.
One way to maintain full backwards compatibility would be to have mode still be a number, but an equivalent parameter state would expect strings. In the responses, both mode and string can then be given. And mode could be deprecated everywhere. But up to you, not my project.
| The quantity of last comments to retrieve | ||
| @apiExample {curl} Get the latest 5 comments | ||
| @apiQuery {Number{1,2}} [mode=1] |
There was a problem hiding this comment.
Open to the idea of supporting both integers and strings, but I do strongly feel that we should move away from integers.
The mode parameter switches between accepted comments and comments pending moderation.
3 participants
Checklist
CHANGES.rstbecause this is a user-facing change or an important bugfixWhat changes does this Pull Request introduce?
This PR introduces a new API endpoint
/pendingwhich works like/latestwith the following differences:[general] pending-enabledset to "true".admininterface to be enabled.The last requirement is maybe a little bit paranoid. Rationale: the admin password is currently only used for the admin interface. The requirement is meant to ensure that people have changed the default password. On the other hand, the endpoint does not expose sensitive information but only potential spam.
The feature/endpoint only makes sense, when moderation is enabled. But this is not explicitly checked because it causes no harm if moderation is not enabled.
Why is this necessary?
If you want to implement an alternative notification mechanism for comments awaiting moderation, access to the moderation queue via the API is required. The existing
/latestendpoint only returns accepted comments. The new endpoint should require authorization because it exposes comments that are not publicly visible....