Reports should clearly annotate Staging Ground questions and use the canonical link to them

[codygray]

Staging Ground is back now on Stack Overflow, and it is public (no longer a beta). Questions from Staging Ground are currently being scanned and reported by SD, but the reports are indistinguishable from reports on "normal" questions. I believe that they should be clearly marked as being from the Staging Ground.

NOTE: This is effectively what was implemented by PR #7827 by @Papershine. I would have just commented and re-opened that PR, but I cannot do so, since the repository linked to that PR has been deleted.

Currently, when a Staging Ground question is reported, the report message looks indistinguishable from the report message for a normal question on Stack Overflow. An example can be found here (note that is from a manual report, but, aside from the reason, which will vary for every report anyway, it is no different for automatic reports):

[ SmokeDetector | MS ] Manually reported question (93): What is geo bags?‭ by singhal‭ on stackoverflow.com

and, in "raw" Markdown format:

[ [SmokeDetector](//github.com/Charcoal-SE/SmokeDetector) | [MS](//m.erwaysoftware.com/posts/uid/stackoverflow/78955454) ] Manually reported question (93): [What is geo bags?‭](//stackoverflow.com/questions/78955454) by [singhal‭](//stackoverflow.com/users/27215498) on `stackoverflow.com`

Note two salient features—or, the lack thereof:

1. There is no indication anywhere in the message that the question is from the Staging Ground. While this is not a functionality issue, it would be nice to make this improvement for clarity and searchability.

2. The URL used to link the question is //stackoverflow.com/questions/N. This works in the sense that it can correctly load the Staging Ground question. Since the system-assigned IDs for Staging Ground questions are within the name namespace as the IDs for "normal" questions, requests for these URLs are automatically redirected to the format //stackoverflow.com/staging-ground/N. So, again, not a functionality issue, but should be fixed while we're at it.

As should be clear from the above description, Staging Ground questions do always have /staging-ground/ in the URL, so this should be sufficient for detecting them.

If @Papershine is still interested and has the time, I hope that they will resurrect the code from their original PR, potentially improve it, and verify that it works properly on the live Staging Ground, and then submit a new PR. If they are not able or interested in doing this, perhaps I (or someone else) will take a stab at doing this.

Two potential improvements from @Papershine's originally proposed implementation:

1. Tighten up the URL check by matching /staging-ground/, rather than just staging-ground, here. (Already suggested by @makyen.)

2. Alter the message_format used for the report. Instead of reporting the Staging Ground status before the username, append it to the end (after the site name). That is, here, instead of:

   message_format = "{prefix_ms} {{reasons}} ({reason_weight}): [{title}\u202D]({post_url}) {staging}\
                     by {user} on `{site}`"
   

   do this:

   message_format = "{prefix_ms} {{reasons}} ({reason_weight}): [{title}\u202D]({post_url}) \
                     by {user} on `{site} {staging}`"
   

[Papershine]

Oops, I must have made a mistake with the original head repo!

After doing a bit of digging again, it seems that the method that I proposed in #7827 actually doesn't work... The API does not indicate whether the post is posted on the staging ground or not.

Here is the result for GET /posts/id for this staging ground post https://stackoverflow.com/staging-ground/78955432:

"items": [
  {
    "score": 0,
    "creation_date": 1725590314,
    "post_type": "question",
    "post_id": 78955432,
    "share_link": "https://stackoverflow.com/q/78955432",
    "link": "https://stackoverflow.com/q/78955432"
  }
],

If anybody else has a better idea on how to implement this, feel free to take a stab at it!

[codygray]

Thanks for testing it! It's really quite surprising that both link and share_link do not return a URL that indicates the post is in the Staging Ground. But, confirmed.

The only thing that catches my eye is the title field, which appears to return the following when testing as an anonymous user (from the SE API documentation):

"Not authorized. Please check the user token in the property 'sonar.token' or the credentials in the properties 'sonar.login' and 'sonar.password'"

I guess this is because anonymous users don't have the privileges to view Staging Ground questions? But the API will return other information about them. And what does sonar. mean? I have no idea.

It seems odd that there would be no way to programmatically determine via the API whether a question is in the Staging Ground or not, but I cannot find one, either.

[Andrew5057]

Switching to v2.4 would make this way easier, as Makyen pointed out within half an hour of me asking(!!!)

The v2.4 response includes a "post_state" field, which starts with "StagingGround" for any SG posts. It also uses the SG URL for the "link" field.

"items": [
  {
    "owner": {
      "account_id": 27906011,
      "reputation": 1,
      "user_id": 21309208,
      "user_type": "registered",
      "profile_image": "https://www.gravatar.com/avatar/a6ebbe47d0d66170e065f7c9e96d4426?s=256&d=identicon&r=PG&f=y&so-version=2",
      "display_name": "vince pablo",
      "link": "https://stackoverflow.com/users/21309208/vince-pablo"
    },
    "post_state": "StagingGround_Reeval",
    "score": 0,
    "last_edit_date": 1725849551,
    "last_activity_date": 1725849551,
    "creation_date": 1725590314,
    "post_type": "question",
    "post_id": 78955432,
    "content_license": "CC BY-SA 4.0",
    "link": "https://stackoverflow.com/staging-ground/78955432"
  }
],

Not sure how actionable this is though, since switching the API version is...let's go with "nontrivial."

[Papershine]

Ah I must have made a mistake and selected api v2.3 while testing the api, seems like we do use 2.4 already as below https://github.com/Charcoal-SE/SmokeDetector/blob/bf2397f444558adb0d1fd10e53d9d0407e73d1f3/globalvars.py#L177

I guess my old code in #7827 would work then if this is the case (Which makes sense because I remember I definitely verified that it works when I submitted the original PR). Just depends if we want to use the link or actually read the post_state field.

[codygray]

You and I both made this mistake because the SE API website does not even talk about version 2.4 of the API. On the home page and the docs, it suggests that v2.3 is the latest version. In fact, I cannot even find any entrypoint or other way of toggling documentation about v2.4 on the website. Makyen's answer includes links with a query string to request v2.4, but I don't know how he found those links—whether via URL manipulation or from an announcement by SE staff elsewhere (but I can't find a Q&A on MSE announcing the release of v2.4 of the API, either).

[Andrew5057]

Makyen’s just omniscient. He gets a ping in his prefrontal cortex every time a new version of a tool comes out.