id summary reporter owner description type status priority milestone component version resolution keywords cc 24998 "[RFC PATCH] Search for ""modified"" objects includes ""new deleted"" objects, which is distracting" mattmccutchen team "I frequently review my work by searching for `modified` with the ""all objects"" box checked. I do want to review objects that exist on the server that I've deleted in my layer, but I've noticed that the search also includes objects that I created and then deleted locally without ever uploading them to the server. This is distracting because such ""new deleted"" objects don't represent a change that would be uploaded and thus don't need to be reviewed. (The upload dialog correctly filters them out.) In fact, I was surprised that ""new deleted"" objects are retained in the layer at all, since they have no significance to any workflow I can imagine. I propose that the `modified` keyword shouldn't match ""new deleted"" objects. A workaround is to search for `modified -(new deleted)`, and it's easy enough to save that as a toolbar button. Note that the `modified` keyword correctly does not match objects that are deleted both on the server and in the layer (call them ""already deleted"" objects). For reference, I know of two ways to generate ""already deleted"" objects: download them from a changeset in the Changeset Manager, or use the undelete plugin to undelete an object and then delete it again. So I'm proposing that the `modified` keyword should handle ""new deleted"" objects consistently with ""already deleted"" objects. ==== What steps will reproduce the problem? 1. Ensure expert mode is on. 2. Create a new local layer. 3. Create a node and then delete it. 4. Search for `modified` with the ""all objects"" box checked. ==== What is the expected result? The search has no results. ==== What happens instead? The search matches the node from step 3. ==== Please provide any additional information below. Attach a screenshot if possible. According to my analysis, the problem happens because the condition in `SearchCompiler.Modified.match` is `osm.isModified() || osm.isNewOrUndeleted()`, and ''both'' disjuncts are true for ""new deleted"" objects. FLAG_MODIFIED is true because `AbstractPrimitive.setDeleted` does `setModified(deleted ^ !isVisible())`, and new objects have FLAG_VISIBLE true (a questionable design in my view). And of course, `osm.isNewOrUndeleted()` is true for all new objects. I can imagine a few levels at which the problem could be fixed: 1. Don't retain ""new deleted"" objects in the layer at all; purge them as soon as they are deleted. 2. Handle new objects more uniformly with objects deleted on the server by turning off FLAG_VISIBLE for new objects. Then ""new deleted"" objects will have FLAG_MODIFIED set to false according to the `AbstractPrimitive.setDeleted` logic above. Further, instead of having `SearchCompiler.Modified.match` call `osm.isNewOrUndeleted`, which expands to `isNew() || ((flags & (FLAG_VISIBLE + FLAG_DELETED)) == 0)`, just test the second part of the condition, `(flags & (FLAG_VISIBLE + FLAG_DELETED)) == 0` (which could be encapsulated in a new helper method of `AbstractPrimitive`). With these changes, `SearchCompiler.Modified.match` would no longer match new deleted objects. 3. Just change the condition in `SearchCompiler.Modified.match` somehow so that it doesn't match new deleted objects. Of course, fixing the problem at a deeper level has the potential benefit of fixing other problems related to new deleted objects and enabling code simplifications, but it presents a much higher risk of breaking other code in JOSM. So my proposal would be to start with approach 3. That doesn't preclude implementing a deeper fix later if the benefit is found to outweigh the cost. {{{ Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2026-10-27 08:20:52 +0100 (Tue, 27 Oct 2026) Revision:19668 Build-Date:2026-10-28 02:30:40 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (19668 en) Linux Fedora Linux 44 (Forty Four) Memory Usage: 234 MB / 4072 MB (132 MB allocated, but free) Java version: 25.0.4.1+1, Red Hat, Inc., OpenJDK 64-Bit Server VM Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel Screen: :0.0 1920x1080x[Multi depth]@46Hz (scaling 1.00×1.00) Maximum Screen Size: 1920×1080 Best cursor sizes: 16×16→16×16, 32×32→32×32 Environment variable LANG: en_US.utf8 System property file.encoding: UTF-8 System property sun.jnu.encoding: UTF-8 Locale info: en_US Numbers with default locale: 1234567890 -> 1234567890 Desktop environment: X-QUBES VM arguments: [--add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, -Djosm.home=] Dataset consistency test: No problems found }}} " defect new normal Core template_report