Is your feature request related to a problem? Please describe.
Currently the only timestamp we save or display for a report is the time of the report itself. This makes some reports confusing, because post creation or edit dates are often more relevant than the report time, and while most reports happen immediately after the post is created or edited, many are not.
Additionally, it's usually difficult to see at a glance if two reports are duplicates. For duplicate reports, it is likely they will have an identical last-modified timestamp, which could make that clearer. Duplicate report avoidance is best-effort in SmokeDetector, so many duplicates get created: often by a manual report not getting noticed as a duplicate, so a second report is created, and sometimes when SmokeDetector refuses manual reports of some edited posts without -force, and certain Charcoal members like myself mistype the forced command.
Describe the solution you'd like
This feature request is for one step towards saving and showing a modified time in Metasmoke: have SmokeDetector send last_edit_date from the SE API to be saved in Metasmoke as post_creation_date. post_creation_date already exists in Metasmoke; it just never has been populated: all posts have it as NULL. In 2017, @ArtOfCode- mentioned in chat "We really just need to populate post_creation_date in the metasmoke DB." (Though that conversation was for a different end use than what I'm thinking: my concern is being able to eventually see the date, as a user, through the Metasmoke site, a userscript, or both.)
This might be easy to do, because looking at the existing code:
bodyfetcher.scan_api_results appears to already have access to the last_edit_date value
bodyfetcher.scan_api_results passes many fields through spamhandling.handle_spam to metasmoke.send_stats_on_post, which sends a POST to Metasmoke; we'd just need to add one parameter/field here
- Metasmoke's code appears to already accept
post_creation_date as a parameter for creating a new post
That kind of PR I might be able to make and test myself, or with a small amount of help.
Describe alternatives you've considered
- We could also make
post_creation_date be creation_date from the SE API, which also appears accessible in bodyfetcher.scan_api_results. This would be slightly more logically named, but be less useful, at least to me: we already have the SE post ID to see that multiple edits are of the same post, and they'll all have the same creation_date. What changes each time it's edited is last_edit_date.
- We could add a new field
post_edited_date or similar, to store last_edit_date. Once again this would be more logically named, and this would be the most useful timestamp for me. This would take more work because it needs updated Metasmoke code and a database migration.
Updating Metasmoke and migrating the database would need more work from @makyen and @teward, which is what makes storing last_edit_date in post_creation_date tempting to me.
Is your feature request related to a problem? Please describe.
Currently the only timestamp we save or display for a report is the time of the report itself. This makes some reports confusing, because post creation or edit dates are often more relevant than the report time, and while most reports happen immediately after the post is created or edited, many are not.
Additionally, it's usually difficult to see at a glance if two reports are duplicates. For duplicate reports, it is likely they will have an identical last-modified timestamp, which could make that clearer. Duplicate report avoidance is best-effort in SmokeDetector, so many duplicates get created: often by a manual report not getting noticed as a duplicate, so a second report is created, and sometimes when SmokeDetector refuses manual reports of some edited posts without
-force, and certain Charcoal members like myself mistype the forced command.Describe the solution you'd like
This feature request is for one step towards saving and showing a modified time in Metasmoke: have SmokeDetector send
last_edit_datefrom the SE API to be saved in Metasmoke aspost_creation_date.post_creation_datealready exists in Metasmoke; it just never has been populated: all posts have it asNULL. In 2017, @ArtOfCode- mentioned in chat "We really just need to populatepost_creation_datein the metasmoke DB." (Though that conversation was for a different end use than what I'm thinking: my concern is being able to eventually see the date, as a user, through the Metasmoke site, a userscript, or both.)This might be easy to do, because looking at the existing code:
bodyfetcher.scan_api_resultsappears to already have access to thelast_edit_datevaluebodyfetcher.scan_api_resultspasses many fields throughspamhandling.handle_spamtometasmoke.send_stats_on_post, which sends aPOSTto Metasmoke; we'd just need to add one parameter/field herepost_creation_dateas a parameter for creating a new postThat kind of PR I might be able to make and test myself, or with a small amount of help.
Describe alternatives you've considered
post_creation_datebecreation_datefrom the SE API, which also appears accessible inbodyfetcher.scan_api_results. This would be slightly more logically named, but be less useful, at least to me: we already have the SE post ID to see that multiple edits are of the same post, and they'll all have the samecreation_date. What changes each time it's edited islast_edit_date.post_edited_dateor similar, to storelast_edit_date. Once again this would be more logically named, and this would be the most useful timestamp for me. This would take more work because it needs updated Metasmoke code and a database migration.Updating Metasmoke and migrating the database would need more work from @makyen and @teward, which is what makes storing
last_edit_dateinpost_creation_datetempting to me.