Folders in graph operations

[mtbc]

https://github.com/openmicroscopy/openmicroscopy/pull/4445 adds some initial behaviors for folders with respect to moving, deletion, etc. Some of the integration tests like HierarchyMoveAndPermissionsTest.testMoveTopLevelFolder give some hints as to how they behave in different circumstances. The present graph policy rules have folders and images now work a bit like datasets containing ROIs which should allow the clients maximum latitude for adjusting the behavior via options offered by the API with the help of https://trello.com/c/3EQc3guS/14-folder-related-api-methods.

The choice of some defaults would rule out some optional possibilities. An example of this kind of thing is from https://trello.com/c/S0mR1aqp/4-have-delete2-never-delete-tags-implicitly:

It'd probably be good to decide if clients being able to use child options to achieve this behavior suffices, as if we were to change the policy rules there'd not a corresponding option for if one ever actually desired deletion of orphaned tags.

However, this kind of approach means that, for instance, with the present rules if the client tries to move an image to another group then the ROIs that are in folders would be left behind. The client can specify to insist bringing the ROIs, thus tearing them out of the folders instead, or to bring the folders along too and then everything will come: those are the kind of currently supported optional possibility I have in mind.

Complicating factors include:

1. ROIs in multiple folders and images when only some subset are selected for the operation
2. ownership and permissions, e.g., what if the ROIs or folders are owned by somebody else and now we move to tighter permissions?
3. multiple use cases for folders: for instance, perhaps they are specific to this image, or perhaps they are from an ontology shared by many other images in the group.

I am conceiving this issue as a place to discuss the folder-related behaviors of the graph operations -- http://downloads.openmicroscopy.org/omero/5.2.0/api/slice2html/omero/cmd/GraphModify2.html -- and to collect ideas about how they should work in specific situations (at the very least that it should be possible to have them to work in some manner even if not by default) to support desired client workflows and perhaps inspire API or gateway helper methods and additional integration tests.

[joshmoore]

From the above, I'd think: "if image move ROIs, too, and only folders if they are otherwise unused". The "otherwise unused" is likely the biggest decision point here, since we could change the modeling such that that would be a given.

[pwalczysko]

@joshmoore

...we could change the modeling such that that would be a given.

This means we could copy the folders or have them as separate entities on each image, thus facilitating the full move ? This seems quite attractive. On the UX side the discussion about the "moves and what to leave behind" boils down to: We think that the best is to move eveything, meaning that "it should appear and behave as if it was everything (Tags, Annotations etc.)" - this is what the user wants (what happens in the back end, deep copy or otherwise, is not so important.

[mtbc]

It would also prevent diagrams like in https://github.com/openmicroscopy/design/issues/2 where a folder may have ROIs from multiple images.

With some work in the server and gateway, both of which I could help out with, we could do copying and moving of associated folder structures when the folders have ROIs only from the targeted image(s). Once we're clear about the desired behavior then we can be sure that the API can support it.

[mtbc]

@ximenesuk is minded to adjust the CLI to not delete child folders by default in accordance with Insight. @pwalczysko: this is probably one of the things to keep among your test scenarios.

(@ximenesuk: note that overriding an exclude with an include is different from not excluding in the first place in the case of multi-parent children.)

[pwalczysko]

After discussion with @mtbc : In the first step, do not tear a ROI away from the image which it was drawn onto (this seems to be now the implemented case unfortunately.). If we have later some ROI templates or not, this is, I think, for later redesign (and it does need a lot of serious permissions design). What the folders do or not is another matter, to deal with in later stage. @gusferguson

[pwalczysko]

cc @dominikl

[mtbc]

This issue interacts somewhat with #16.