Not a bug Bug: Node list shows moderated (=non open) threads, which should be hidden, when using API for creating thread

Affected version
2.1.7
Hi,
when creating a thread via API (obviously only then!), which has flag "discussion_state = moderated", it means the thread should be hidden from "normal" users in forum/node view and node listing, but it IS visible on node list "most recent thread". See screenshot:

1580825063712.png

By click on that link, a normal user just see standard error. Moderators/admins can see/edit them as it should be.
However, it seems the sql query to gather info for the node list entry (on screenshot) doesn't take careabout "discussion_state" flag at all.
Affected template is "node_list_forum" around line 109, class id "node-extra". $extras.LastThread holds the "wrong" information.

In the node view the thread is - correctly - invisible, it's just the "recent/last thread" thing in the node list.

It's just in that particular place, anywhere else it's correctly displayed (== not displayed) like overview or even the xml sitemap. Everythings fine, except node list.
 

Mike

XenForo developer
Staff member
Discussion_state is not a parameter that applies when creating a thread via the API, so the only way a thread would end up in that state is if the standard rules for the user would trigger that. The logic is shared with thread creation via the standard UI. Are you 100% sure the thread is actually in that state in the DB?

Would it be possible for you to give us specific reproduction steps? (If the thread is ended up awaiting approval, what setting has triggered that? Forum settings, permissions, somethin else?)

Note that the last post data should only ever reflect visible content, so that shouldn't be updated if the thread is awaiting approval, but given the shared logic here, it would appear to me that the thread is in a visible state.
 
Hi,

Discussion_state is not a parameter that applies when creating a thread via the API, so the only way a thread would end up in that state is if the standard rules for the user would trigger that. The logic is shared with thread creation via the standard UI. Are you 100% sure the thread is actually in that state in the DB?

Would it be possible for you to give us specific reproduction steps? (If the thread is ended up awaiting approval, what setting has triggered that? Forum settings, permissions, somethin else?)
Yes, sorry, there are other changes. After creating the thread via API we're changing post_date and discussion state in DB directly ("upcoming, hidden post").

SQL is simple (PDO'ed):
PHP:
$sql = "UPDATE xf_thread SET post_date = :post_date, discussion_state = 'moderated' WHERE thread_id = :tid";
Why we're doing that is described here:

That "quickfix" works pretty well - it must be released by a mod (or automatically by a xf cronjob), it's not visible in forum / node view, neither in generated sitemap. It only pops up in that node list preview as shown on screenshot.
That's why I think it's a bug.
 

Mike

XenForo developer
Staff member
The short answer here is really that you can't do that. There many more actions that need to be taken if you want to change a thread state, you can't just change the column in the DB.

If the API isn't exposing the functionality you need, you may need to use an add-on to expand the functionality or add endpoints to handle your specific cases.
 
The short answer here is really that you can't do that. There many more actions that need to be taken if you want to change a thread state, you can't just change the column in the DB.

If the API isn't exposing the functionality you need, you may need to use an add-on to expand the functionality or add endpoints to handle your specific cases.
Well, I thought so, however, please explain which additional steps must be done to get it working (or the preview disapperaing in node list).
I'd like to code an addon for that, but I need to know what's going on to make it work. Or maybe point me to the actual code, so I might reverse engineer what's necessary to do.

To set a thread into moderated discussion_state can be done in the backend somehow, so it would be great to have a functionality in the API, or at least via code (=> via XF:Thread ?).
 
Top