Timeline for New Post Notices are live network-wide
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 22, 2019 at 12:31 | comment | added | Yaakov Ellis StaffMod | I believe you. Feel free to update the answer. | |
| Dec 22, 2019 at 12:29 | comment | added | Dharman |
@YaakovEllis I am 100% sure I am getting elipsis via API. This is the exact value: Duplicate of…
|
|
| Dec 22, 2019 at 12:27 | comment | added | Yaakov Ellis StaffMod | @Dharman you can see the current reasons here as well. I couldn't use the ellipsis character in the db, so it has three periods (and the API pulls from the Db). The Ids are accurate, sorry if I messed up one of the old values. | |
| Dec 19, 2019 at 18:55 | comment | added | Dharman |
@YaakovEllis I disagree. The duplicate reason is actually called Duplicate of… You used ... instead of … Which is the correct one? Also the 105 reason was not unclear before.
|
|
| Dec 19, 2019 at 18:53 | comment | added | Yaakov Ellis StaffMod | @dharman yes, I copied them directly out of my db change script. They will be live on sede on Sunday when it refreshes, if you want to double check there | |
| Dec 19, 2019 at 17:44 | comment | added | Dharman | @YaakovEllis Could you confirm that the list you edited into the question is the exact list as it appears in the DB and in the API? We need to update our apps and scripts so that these values match. I would like to make double sure that there are no typos here. | |
| Dec 19, 2019 at 12:23 | comment | added | Yaakov Ellis StaffMod | I have updated the close reasons accessed by the API. I appreciate that this might break things that rely on these values. Really sorry about that. However, the choice is either to never update them (and then have confusing close reasons that are out of sync with what is shown on the site) or to update them (as infrequently as possible) and have short-time pain for long-term clarity. I chose the second. To help, I put the exact close reason value changes into the answer above. | |
| Dec 19, 2019 at 12:21 | history | edited | Yaakov EllisStaffMod | CC BY-SA 4.0 |
update close reasons
|
| Dec 19, 2019 at 12:08 | history | edited | Yaakov EllisStaffMod | CC BY-SA 4.0 |
added 3 characters in body
|
| Dec 10, 2019 at 23:05 | comment | added | Makyen |
The closed_reason and closed_details.reason have the appearance of being intended for machine consumption, but this answer implies they are directly used as human readable information. Note that both of these fields were recently changed (i.e. in the last day, or so), such that the new values have broken a few/several scripts which relied on the values to determine the reason for closure.
|
|
| Dec 10, 2019 at 23:04 | comment | added | Makyen |
For an API, in general, fields which are intended to be machine readable shouldn't change. If the field is intended to be used as something human readable, then it's usually OK to change it. Unfortunately, for close reasons, the SE API doesn't do a good job of keeping this separation. For example, closed_details.description is formatted as clearly intended to be human readable (it's HTML text), but it's also the only place where some information exists in the entire response provided by the API for a question (actual off-topic reason). Thus, it must be parsed to find that information.
|
|
| Dec 9, 2019 at 21:05 | comment | added | Dharman | Please, don't. This will break software relying on these values. | |
| Dec 5, 2019 at 21:17 | history | edited | Yaakov EllisStaffMod | CC BY-SA 4.0 |
review
|
| Dec 5, 2019 at 21:00 | history | answered | GlorfindelMod | CC BY-SA 4.0 |