Add account_id to spammer

[rschrieken]

From a spammer record I can only navigate to the user profile on the site. If the user profile is nuked there is no option left to find the account id so I could navigate to the network profile.

I prefer this option so I can check if this spammer also has an account on a site I moderate so I can take additional steps if needed.

Please add the account_id, preferable the one that comes in the shallow_user since v2.3 of the SE API

[thesecretmaster]

I think the best way to approach this would be first on the SD side. Currently we do not fetch any user information ourselves, we only use what SD passes to us with the post, and SD only passes the user_link field, which we parse to get the user's site profile id. If SD also fetched account ID and passed that up to us when it created posts, we could use that.

[tripleee]

We can probably add whatever additional information you require to Smoke Detector rather easily. I created a SmokeDetector ticket just now (link above) but it should probably be implemented in metasmoke first, so that we don't submit information you can't handle.

Is it enough if you accept an account_id field in addition to the user_link field, or do we need something more complex? I haven't yet looked at the Stack Exchange API in any detail.

[thesecretmaster]

That should work. I can try adding this feature, honestly it would be cleaner to accept both account and site id instead of needing to parse site id out of the url.

[tripleee]

Would this be a new API endpoint, and would that warrant calling this a new minor version of the API?

[makyen]

I've assumed that the network account ID would just be another value which SD would pass along with the post report. As I understand it, the thing which decided against having that data originally was that obtaining it would have required at least one additional SE API access per report, which would cost both SE API quota and additional time per report. One of the things added to the 2.3 SE API is that the SE Network user ID number can be included in the response we get for our requests for post data. This means that if we use the 2.3 SE API an additional SE API request is not necessary to get the data (i.e. the costs which resulted in choosing not to have the data can no longer exist).

I'll add this obtaining the data on SD's side and sending it to MS. I'm already working on substantial changes to processing post data, so adding this shouldn't be much additional work.

Just to double-check, if SD just starts sending extra properties (e.g. the network user ID) in the post report data structure, they will merely be ignored by MS until such time as MS is changed to handle them. Correct? In other words, SD starting to send the data won't cause problems with MS, even if MS hasn't yet been updated to do anything with that data. Right?

[tripleee]

@makyen Should I put you as the assignee?

[makyen]

@tripleee IMO, no, not really, as it would imply I'd taken responsibility for making the necessary changes on MS here in this repository. While the work I've said I'll do on SD is necessary, it's not the portion which needs to happen in this repository. It would be reasonable to have an additional issue in the SD repository, which links to this one, and have me as the assignee on that issue.

[tripleee]

Right, sorry, that's the one I was alluding to -- Charcoal-SE/SmokeDetector#6695