Two problems (not bugs) when more than one item is selected

[Spliff]

Already in my previous remarks re "Search results, even sorted by Lineage (!), NOT preserving tree order", I in particular mentioned the fact that UR's lineage sort orders "short before longer", but did not follow-up that observation, albeit being more or less sure that "working on that one" would RESOLVE the "tree-order scramble" phenomenon, at least in cases where the user, KNOWING about UR's limitations in this respect, would observe alphanumeric tree order (!) within the "upper" tree levels, in order to finally GET, more or less, tree-order preservation where they need it!

To make this perfectly clear: Even with (!) my suggestion here, the user will (!) have to observe alphanumeric tree order, in order to get tree-order preserving results, but they may combine ABC order with numbering, in order to obtain that, in any such order, e.g. ("going down" the indentation levels, and yes, the brilliant "Tree - Show - n levels" from last year will help the user enormously with obtaining such a strict order within their "upper" levels indeed!) first ABC, then ABC, then 1-9 (or 01-99 if needed), or first 1-9, then ABC, or first 1-9, then 1-9 again, then ABC only, etc., etc.

BUT in these conditions, the user will then be able to use a real tree, spanning several indentation levels, AND get tree-order-preserving search results, proof:

1) items in "Notes" (and yes, they are alphanumerically ordered, in order to achieve the desired results upon search): see screenshot

2) search ("limit search to selected item "Notes"): * = every item is to be included into the results
columns: lineage (sort by), and title
result: screenshot not needed (see 3/4)

3) copy the results to a text editor (^a, rightclick, "copy grid values")
> does not work as expected, since the result is
Title tab Lineage (not Lineage tab Title)
(= as if in the UR search results, I had not switched the columns... which I had done here for demonstration purposes only anyway since we know that this switch causes big problems in UR, albeit "Lineage then Title", for the user, is much more "natural" than the other way round)

4) thus, in the editor, (by regex) restitute the intended order
Lineage tab Title
then replace the tab by another "|":
in the editor, we have now "full-lineages" = including the titles (similar to file system's "path" vs. "fullpath"):
Lineage (with separator char "|" where it applies); here's the list:
(please note that this list exactly replicates (in its row order) what you see as UR's search results (2 above), just with an additional "|" within the lineage, and the title, columns;

we see that (since sorting was by lineage, shorter before longer, and thus, as expected) the tree order (albeit original tree observing alphanumeric sort) is not respected:

Notes
Notes|a
Notes|b
Notes|c
Notes|d
Notes|a|alpha
Notes|a|beta
Notes|a|delta
Notes|a|eta
Notes|a|beta|1
Notes|a|beta|2
Notes|b|alpha
Notes|b|beta
Notes|b|delta
Notes|b|eta
Notes|b|delta|1
Notes|b|delta|2
Notes|c|alpha
Notes|c|beta
Notes|c|delta
Notes|c|eta
Notes|d|alpha
Notes|d|beta
Notes|d|delta
Notes|d|eta

5) Now, in the editor, "Sort (lines) a-Z" (which means alphanumerically; I didn't try numbers above 10 but as said above, leading zeroes for 01...09 would cause numbers like 10, 11, 12 also being sorted correctly if needed), result list:

Notes
Notes|a
Notes|a|alpha
Notes|a|beta
Notes|a|beta|1
Notes|a|beta|2
Notes|a|delta
Notes|a|eta
Notes|b
Notes|b|alpha
Notes|b|beta
Notes|b|delta
Notes|b|delta|1
Notes|b|delta|2
Notes|b|eta
Notes|c
Notes|c|alpha
Notes|c|beta
Notes|c|delta
Notes|c|eta
Notes|d
Notes|d|alpha
Notes|d|beta
Notes|d|delta
Notes|d|eta

As we see, the alphanumeric tree order is preserved, by the search results being sorted - outside of UR here - by "FULLPATH", instead of just "naked-path".

I am sure it will be technically possible to add a "fulllineage" column (or whatever it's called), so that UR users can sort by that, and as implied, with proper categorizations / naming, and with the help of Tree-Show-n-levels, users will be perfectly able to amply profit from this column sort, even if their first-level titling is not alphanumerically ordered, example:

Root (0)
Project A (1)
Other Project (1)
__1 - Some Title (2)
____A - some subtree (3)
____B - some other subtree (3)
__2 - Some Other Title (2)
And Another Project (1)

Search in "Other Project" will give correctly ordered results 2 levels down in this example, even though it's also correct that on level 4 then (in this example), the items will not be listed in manual tree order but alphanumerically, too, since there is no (and will not be a) "weighted precedence" for ordering, so "by full path" will not only apply to n top levels, but to any level, so a secondary sort "by tree order" will never apply then; in other words:

The user will be well advised to alphanumerically order their titlings where needed (i.e. within their projects or other data bulks within their UR DB(s)), and "all the worse for the rest", i.e. for the deeper-down data of which the tree order will continue to be scrambled...

My suggestion thus will not entirely preserve tree order, BUT will preserve the tree construction, down to the user's "chapters": it'll be just within those "chapters" then that the user will have to be aware of their intended tree order not (also) to be preserved anymore.

It's core functionality we're discussing here, and if the competition doesn't get it, all the worse for them.

It's overdue, as well as v7 is then. ;-)

Spliff, you do not have permission to access this page. This could be due to one of several reasons:

Your user account may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?

If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.