Allow ordering of OMERO clients to be overridden in the tree view

[manics]

The ordering of top-level containers in the OMERO.web Left-hand tree can be modified using omero.client.ui.tree.type_order to not separate Projects and Screens. This is currently used in the IDR to ensure studies are ordered by number irrespective of whether they are Screens or Projects.

This does not allow more fine-grained ordering, for example

idr0001/ExperimentA
idr0002/ScreenA
idr0002/ExperimentB
idr0002/ScreenC
idr0003/ScreenA

Would be displayed in alphanumeric order as

idr0001/ExperimentA
idr0002/ExperimentB
idr0002/ScreenA
idr0002/ScreenC
idr0003/ScreenA

Possible solution

Add an optional annotation on each container that is used as the sorting key. The default value of the key would be the container name.

E.g. using MapAnnotations (name-value pairs) in namespace openmicroscopy.org/client/display (to allow for further display customisation)

Project idr0002/ExperimentB MapAnnotation:

name: container-order-key
value: idr0002-2

Screen idr0002/ScreenA MapAnnotation:

name: container-order-key
value: idr0002-1

Screen idr0002/ScreenC MapAnnotation:

name: container-order-key
value: idr0002-3

name	sort-key
idr0001/ExperimentA	idr0001/ExperimentA (default name)
idr0002/ScreenA	idr0002-1 (container-order-key)
idr0002/ExperimentB	idr0002-2 (container-order-key)
idr0002/ScreenC	idr0002-3 (container-order-key)
idr0003/ScreenA	idr0003/ScreenA (default name)

If omero.client.ui.tree.type_order=false the containers would be ordered by sort-key

[sbesson]

A few additional comments primarily coming from the IDR use case. It would be useful to also include other drivers for this functionality:

• as mentioned in the title, the need for some container order is not limited to the webclient tree. As an example of implementation, the omero-gallery app is defining a custom configuration which effectively builds a sort-key from the container name (https://github.com/IDR/deployment/blob/6a12c18d0e1881b1662c4d16013ceb31974d6954/ansible/group_vars/omero-hosts.yml#L560)
• there is an interesting trade-off in cases where the sort-keys can be directly determined from existing metadata using a regexp as in above. The advantage of the current IDR/regex based approach is that it becomes a configuration/deployment problem, reduces the maintenance extra annotations and makes it possible to change the order at fairly low-cost. The obvious downside is that the configuration needs to be copied for every client and match its own implementation.
• unlike in IDR, I suspect there are use cases where a sort key cannot be generically computing using the container metadata i.e. user input is required in order to specify an ordering. In this case an annotation sounds like the most natural way to store this information.
• also inspired by the gallery UX, given a sort-key, different UIs might want to order containers high to low or low to high depending on the use case.
• outside the IDR use case, it might be interesting to consider how this plays out with permissions i.e. should each user be able to define their own sort-keys?

[manics]

If we're happy for this to be client-side web-only then OMERO.web could take an inline javascript function that does the transformation, e.g. omero.web.display.tree.sortfunction="function(s){var a=/(\w+)-\w+\/(\w+)/.exec(s); return a[1]+'-' + a[2];}"

This function would be run on every container name to create the sort key in the browser view only. The advantage of this is there should be no performance hit since there's no need to check for annotations, it's all on the client side, and you've got full flexibility to do whatever transformations you want.

[jburel]

Looking at the configuration and reading the description, it seems that we are moving towards preference that people have requested for a while e.g. I want to the first 10 images in that dataset and hide the rest etc. If we introduce a config option this will need to be as generic as possible and tackle other problem that just the IDR issue mentioned above. The suggested map will also be visible so a way of hiding it will be required

Summary: I will refrain from introducing a config without more scoping of the preferences.

[pwalczysko]

What I understood so far:

1. KVPs with the ordering pattern will have to be added by users on the objects which have to be re-ordered
2. These KVPs thus added would have to be under a correct specific namespace
3. These KVPs will be visible in the webclient
4. There is no knowledge atm about "permissions" behaviour. There is a question in https://github.com/ome/design/issues/108#issuecomment-704109629 whether or not each user should have their own set of KVPs and thus their own ordering on the same data.

Ad 1. I would say the workflow of adding the KVPs in order to reorder the containers is very hard to discover. Also, to add these KVPs in the correct manner for a tree which is constantly in flux as new containers are appearing and disappearing (normal lab routine of importing new images, deleting, renaming and reordering the containers) is a task which the user will not conteplate for data which are in flux imho. The only usecase would be the "public group" or similar, where the data are already more "stable" aka IDR.

Ad 2. I do not see a way from the webclient UI to specify a namespace. If scripting/CLI is the only way to go here, this will push the usage of such feature to negligible levels. The cost/benefit ratio is not favorable in this case, as going into ClI for the sake of having a different UI ordering will be perceived as "not worth it" by most users.

Ad 3. This is suggested as a way to help users to understand the ordering. But imho there would be many cases where the exact opposite effect would be achieved - as the concept of ordering per item using KVPs is completely non-familiar to most of users, they will be doubly confused (both by the ordering and by the KVP) instead of connecting the two (KVPs govern ordering).

Ad 4. There is some benefit in having each user define their own ordering, but these usecases will be in an unfavorable ratio to the number of cses where the users will be confused by the feature (and the per-person ordering on top of it).

In summary, I would guess that without a UI feature with something like sort by context menu option on each item, not much usage will be achievable outside of IDR.

[joshmoore]

Another option along the lines of an annotation per dataset would be an annotation on the view. The interaction I'm imaging is eventually allowing someone to drag-and-drop the elements of the tree to have them ordered differently. Having the annotation on each individual entry might make it difficult to rationalize that drag-n-drop as opposed to one list. There are still synchronization issues which would need working out.