Open AntonKhorev opened 2 weeks ago
The big question for me is how updates are propagated to the changeset replication feed. Otherwise if you delete tags on the website, they will still be shown in all systems that consume the feed.
The big question for me is how updates are propagated to the changeset replication feed
This is one of the excuses why hiding/deleting changeset tags wasn't done before. There are others such as we don't have changeset versions to store previous set of tags.
If the feed is generated by this, tag deletions probably won't be propagated. But we can automatically add a changeset comment saying that some tag was deleted, this should get picked up by the feed.
This is one of the excuses why hiding/deleting changeset tags wasn't done before.
I'd call it a 'good reason', not an 'excuse'. Having a user interface to remove or edit tags is straightforward, but making sure the updates are properly replicated is required too.
I've decided against automatically adding a comment to trigger the replication. Surely moderators can add a comment after deleting tags. Or they can choose not to add a comment if they don't want to replicate the changes, although that's less likely.
Lets moderators delete changeset tags. A typical use case is somebody creating a changeset with a comment tag that says "my house" or "<person's name>'s house" which DWG is later asked to remove.
Fixes #5219.
Moderators will see the "Manage changeset tags" link at the bottom of the changeset page:
It leads to a page like this:
There was another attempt at tag hiding with a different approach #1167. It required database schema changes and marked the entire changeset as having its tags hidden. The tags were still kept in the database.
This PR doesn't change the schema and actually deletes the tags. Such deletions are not unusual and happen during regular changeset updates: https://github.com/openstreetmap/openstreetmap-website/blob/3a1b4cbe3396092efa2ea2c60cdbfb2a6ed6de0d/app/models/changeset.rb#L176