Not sure if this is a bug or not, but when a post needs to be approved, and I opt to reject it (as it doesn’t really fit the type of content we want), it leaves the user as blocked and the rejected post is not associated to the user anymore (likely related to the deleted posts not being associated to the user – so this part may be fixed in a later commit).
Edit: Based on reviewing the commit for fixing deleted user action associations, it seems we have that fix in our version, but it doesn’t work when rejecting a post that needs to be approved.
Yes, that is operational. But we are seeing new users go into the Queue for “Approval” and then I’ll either Reject or Approve it, and then Akismet picks it up (potentially, if approve was used and Akismet is uncertain about the post) – but that’s a whole other issue.
In short, rejecting a topic/post in the queue leaves the user blocked, and doesn’t associate the topic/post to that user. The user action entry seems to be lost/not created/whatever and the post/topic is deleted. We choose reject because the topic wasn’t a good fit, we didn’t choose to delete the user, we want the user to remain and should be active (but we have to manually unblock that user).
Now, the other side, I’ve had it happen twice where I approved a post/topic and it then got picked up by Akismet to be approved again (sort of self defeating, as I already looked at it, but very minor in my opinion).
But when you reject a post it catches, it leaves the person blocked even though you don’t want the post to be made, but you don’t see a reason to delete/ban the user. We were anticipating that Approve/Reject would unblock the user and either show/delete the post, and delete would delete the post and ban the user.
However, Approve does that (good), Reject doesn’t (leaves user blocked, but no indication they have a deleted post), and Delete does what you’d expect too (destroys the entire user).
This seems correct as designed – when you reject a first post by a user, you are implicitly rejecting that user, too. This is really a question for @sam since he designed the feature.
I think the workflow you’re using is a bit wrong here. You should accept the post, then delete it or message the user to let them know “that post wasn’t spam, but it isn’t something we want, either”
I told @sam that copy on the page was wrong, the button should say “Delete Spam”, but it was never changed…
Okay, that’s a fair response. We’re trying to figure out how to properly use it, so if that is the intention, I’m good with that, just need to understand it better, now that we have it in a real scenario setting.
Thanks for the clarification. I think I understand how it works now.
Should rejecting a post still show that post as related to that user? IE: Deleted post for that user?
Not sure, I’d prefer deleted posts remain attributed to the person who created them. Otherwise, as staff, when I visit that user’s page, I can’t see what posts have been deleted for that user (sometimes this helps with decision making on how many more chances they get).
So I’m not sure if this should go under a new topic or along the lines with this one, but we’ve had one complaint arising around Needs Approval lately (beyond the Reject button). Context. It is hard to identify the context of the post/reply (when it is a post/reply to an existing topic).
We can visit the existing topic, but we have no clues to if it is a reply to a prior post above, or just to the topic as a whole at the end. We don’t really know where in the chain of responses this person would have fit as there isn’t any indication.
I sort of wish it worked more like Akismet, where it has the post in the stream, but deleted, so we can visit it and see these clues.
I can’t understand why that would matter in the context of completely rejecting the post? Where is reply state the difference between disallowing a post and allowing it? Example?
Well, we had one recently that I was on the fence about (can’t link you to it, as there seems to be little/no history of past queued posts…) But if it were in response to a specific post, I may have permitted it because it was semi-on-topic, but if it were to the OP, I likely wouldn’t have, as it wasn’t as on-topic.
It was very grey and since there was no way to tell who it was directed at, I let it sit and then someone else made the decision to just reject it. We’ve actually had this happen multiple times. We’ll review it, and just not act because there isn’t much context to lead us to determine “yep, allow it as who they are responding to, makes sense” versus “nope, not even close to what the OP is looking for”
Context is 100% helpful in any moderation task. OP asked X, reply from user Y covered X and added Y as a possibility, approved post could be targetting X or Y or none of them above, but without knowing the context of who the post was geared for, it is hard to approve it since the user is new and this is their one and only post (we sort of have to assume their intent and decide, which doesn’t seem like a good idea).
We’ve also taken the stance of only using Approve or Delete User, as Reject is funky at the moment (as previously stated in this topic). And Delete User blocks the user permanently (technically Reject keeps them blocked too, it just doesn’t block their IP/email and delete the user) so we like to be certain of side on Approve if there is any chance its intent could be for good (doing that without any context is difficult though).
