Design issue Reports about moved threads/posts are invisible to a destination forum moderator

Vladislav Rastrusny

Active member
The situation:

You have a post in forum X. You create a report about it. This report is now visible to the moderator of forum X. Now you move post to a forum Y.

Reports contain node data in a serialized form in the xf_report.content_info field. And this info is not updated on thread/post move/copy operations.

So, after we have moved our post, it is still visible to the moderator of forum X, and invisible to a moderator of forum Y.

What can be done about that? Of course, we can write a handler, that will update at least data in active reports on thread/post move/copy. But may be there is another solution?
 
I understand the issue, but I'm not sure what action should be taken exactly. Reports are generally designed to represent a snapshot in time. They represent the content when it was (first) reported. This can be relevant for situations where a post gets edited or, more significantly, where the content gets completely removed.

I don't think attempting to update the report when the content changes (or more generally, when the content's container changes) is really viable. In the longer term, we could look at pulling some details from the content "live", though I'm not a huge fan of this as it seems unintuitive what is "live" and what is "snapshotted". We could look at updating the cache when the content is reported which would allow a workaround (re-report it), but of course that causes issues where older reports lose their context because the version of the content shown isn't as it was. (That can happen now in the inverse direction.)

Thus far, I don't really see a solution I like.
 
They can if they are global moderators.

Of course. I assumed the original post referred to forum moderators who aren't Supermoderators. I think one can make the case that report contents are useful for all staff to see (see being the operative word the op used) regardless if they moderate the particular forum the thread starts in or ends up in. Why not separate permissions for viewing reports and acting on them?
 
Depending on the forum, forum moderators may not be part of the staff.

For example, we have several "company" forums where a representative has limited moderating abilities within just that forum. But they are in no way, associated with the site staff.
 
Depending on the forum, forum moderators may not be part of the staff.

For example, we have several "company" forums where a representative has limited moderating abilities within just that forum. But they are in no way, associated with the site staff.

Matter of semantics really - "staff" can mean different things. One definition of staff includes only paid employees, but the definition I prefer for those who work on a forum is those members of an organization serving only in an auxiliary or advisory capacity on a given project. So regardless of whether or not you consider forum moderators "staff", they do serve on the forum and they could benefit from seeing reports globally to gain information about the behavior of certain members as well as to get a feeling for how issues are to be handled.

My suggestion was to separate permissions for viewing and acting on reports, so you'd still be able to keep some or all of your staff from seeing reports anyway.
 
My suggestion was to separate permissions for viewing and acting on reports, so you'd still be able to keep some or all of your staff from seeing reports anyway.
That's sort of an aside to the issue in question though, because if this were a per node permission, the reported issue still exists.
 
That's sort of an aside to the issue in question though, because if this were a per node permission, the reported issue still exists.
Yeah, sorry about that - I know this isn't the suggestions forum, but the suggestion did stem from the bug report so I posted it here. Feel free to delete it. :)
 
I understand the issue, but I'm not sure what action should be taken exactly. Reports are generally designed to represent a snapshot in time. They represent the content when it was (first) reported. This can be relevant for situations where a post gets edited or, more significantly, where the content gets completely removed.

I can vouch for wanting to keep the reported post completely intact. Plus, if staff wants to see the post itself, they can click the appropriate link and hop right to it, and view the edit history (which shows the revisions). We have a 15 minute edit/delete window, so as far as member editing, not much could happen.

So no, I wouldn't want to see the present behavior changed.
 
Top Bottom