This is because all the validators use it, and it's the right thing to do.
As entites load from the OSM or are restored from history, the most
updated version of them will be in context.graph, not validatedGraph
Now entities can always be deleted if the user created them in the first
place.. We skip asking `operationDelete.disabled()` because there are reasons
why this may return true.
A thing that could happen before:
- User creates an untagged entity
- Quits browser and restarts iD
- Restores history
- The entity happens to be in a part of the map that hasn't been loaded yet,
so `operationDelete.disabled()` returns true, and the issue ends up
as a 'warning' instead of an 'error'
This matters as we start to match more rules for hybrid features like rail
platforms, which now match both path and rail. We want to show them unless the
user has hidden all the rules that they match.
Also this changes the test code slightly to actually test rule matching.
Before it was really just testing hiding.
The idea here is that the validator will now hold onto lots of issues,
but the calling code will only want some small subset of them
(edited/everything) (inview/everywhere) and can pass these as options
so that we don't need filtering code spread throughtout the app.
What could happen was:
- user could right click on a line
- this would trigger `disabled()` checks for each operation buttons
- the line was not fully downloaded, so would return `disabled()` 'not_downloaded'
(and also start download of the missing tiles)
- then the tooltip would pop into existence, calling `tooltip()`
- which calls `disabled()` again
- but this time it's fine and the `disabled()` is false
- so you'd see a greyed out button but the tooltip said everyting is ok and
you can click the button anyway
I fixed this by just caching the disabled test. This is probably ok anyway
because these tests can be expensive, and then the user will see a consistent
message like "The line is not yet fully downloaded".
If the user clicks off the line and back onto it, iD will reenter select mode,
rebuild the menu, redo the disabled test, and they will see the button enabled.
(closes#4890)
This lets iD request needed tiles outside of the viewport, for example to
properly straighten lines or validate features that may have unloaded
connections.
Since d5e427289, the tree head graph will not update if only tags have
changed - it requires an addition, deletion, or geometry change.
This makes the tree a little more efficient, but we do need to make
sure to return the current entities to the caller.