Feedback you send
The two tables behind tag corrections and smart search reports, what each row captures, and who can read it.
Two places in the app let you tell us something is wrong, and each writes a row
you can point at later. Tag corrections go to tag_feedback, smart search
reports to search_translation_feedback. Both rows carry only what you typed
and what the app showed you.
Tag corrections
Suggesting a change to a card's tags from its card page writes one row to
tag_feedback.
| Column | What it holds |
|---|---|
card_id | The card you were looking at. |
tag | The tag you are correcting. |
suggestion | What you wrote. |
status | pending, accepted or rejected. New rows are pending. |
user_id | You. Submitting requires being signed in. |
created_at | When you sent it. |
You can read your own rows. Accounts on the maintainer list can read every row, set the status, and delete one. That list is a table the policies check, so it is the same answer everywhere.
Accepting a suggestion sets status and changes nothing else. The tags
themselves come from the curated vocabulary and the detection rules described in
taxonomy, and those are edited by hand, so an
accepted suggestion turns into a tag change on a later pass rather than at the
moment it is accepted.
Smart search reports
Smart search turns a plain-English question into query
syntax. Reporting a bad translation writes one row to
search_translation_feedback.
| Column | What it holds |
|---|---|
input_text | What you typed. |
converted_query | The query the model produced. |
expected_query | The query you say it should have produced. Optional. |
comment | Anything else you wrote. Optional. |
status | pending, accepted or rejected. |
user_id | You, or null when you were signed out. |
created_at | When you sent it. |
Smart search works signed out, so reporting a translation does too. The insert
policy accepts a row from anyone, and a report sent while signed out carries no
user_id.
You can read your own rows. Accounts on the maintainer list can read every row
and set the status. That includes the rows sent while signed out, which have no
user_id for the ownership check to match.
status works the same way it does for tag corrections: rows start pending,
and a review sets accepted or rejected.
What these rows are used for
Both tables exist so we can fix the tags and the translator, and both are read out of band when someone works through the backlog. Neither is shown to other users, and neither is sent to a model as part of answering a question.