Delete rnd

[pwalczysko]

This adds a script which deletes all the rnd settings on images from specified dataset(s).
The main goal is to be able to clean the rendering settings of other users as they are viewing each others and trainer-1's images on outreach. There is quite a few settings thumbs in the Preview panel on siRNA-HeLa dataset.

Although the script deletes ALL the rnd settings on each relevant image, the rnd settings are regenerated immediately when the owner (or other person) is viewing the images the first time after this script has been run. Hope this is an acceptable tactics.
cc @jburel @will-moore

cc @jrswedlow (regards the prep for LA outreach -> follow-up of https://openmicroscopy.slack.com/archives/C1PJHN2D7/p1550422112083100)

[mtbc]

bin/omero delete Dataset/RenderingDef:123,124,125

[pwalczysko]

bin/omero delete Dataset/RenderingDef:123,124,125

@mtbc @sbesson But this does not what the script is doing. It does not iterate through rnd from many datasets specified by a name or ID.
Which means, I need some querying and passing the IDs of the datasets -> bash script. Not sure that would be optimal.

[mtbc]

True, if you want to do it by name you'd have to first find the IDs like,

/bin/omero hql --all "SELECT id FROM Dataset WHERE name = 'my dataset'"

[pwalczysko]

As discussed with @mtbc in the office, we have to pass the IDs find via the CLI into another CLI command. This still leads to a bash script, which is much less user friendly and assumes typing a one-liner on the fly, also remembering the syntax of the command, or re-writing the looping here using bash.
I had the feeling from, lets say, the other scripts from this repo, or from the ldap scripts written by @joshmoore that the python way is the way to go here ?
I like the -h option of these python scripts a lot and use it heavily.
Or, indeed as @joshmoore suggested on another PR here, to expand the CLI so that it can do the things asked for by the scripts here ?

[joshmoore]

I'm not exactly following, but in general, yes, I'm all for adding more CLI commands if they make our life simpler.

[jburel]

@pwalczysko the CLI examples are very useful during training. I don't remember any discussion about having only python scripts

[pwalczysko]

As requested, the last commit re-writes the whole logic in a bash script.

[pwalczysko]

The biggest problem with using CLI in our setup is that an output of a previous command (typically a row of IDs, typically from hql) does not bind smoothly into intput of another command (delete in this case). Do we have a card for this ? (@mtbc @joshmoore )

[joshmoore]

@pwalczysko : not that I know of. Around the time that obj was being developed, we discussed parts of this, but ended up going for a simpler version. One option would be to have YAML inputs/outputs for the various apps (hql, obj, chown/chgrp, etc)

That being said, looking at some of your scripts, they are quite complicated. Unless you have some clear low-hanging fruit, rewriting them in Python might be the cleanest solution.

[dominikl]

Like Petr said, a big improvement would be if just the hql output would be more OMEROish for a start. You can neither use the 'plain' nor the 'csv' style output as input for another command, hence all the complicated parsing steps. I can have a look into this actually.

Btw, another great improvement would be to generally accept the "Type:Id,Id,Id,..." syntax ( https://github.com/openmicroscopy/openmicroscopy/blob/bff72cb83888ef3b54540bd29973e18885a09ffa/components/tools/OmeroPy/src/omero/cli.py#L1694 ) for all commands. But at the moment only the 'GraphControl' commands do that.
But I think that'll be huge task to rewrite all commands using this 'GraphArg' (tried that for the metadata plugin, and gave up again).

[mtbc]

Mmm, similarly I ran into a lack of GraphControl for https://trello.com/c/4UKcyaed/77-chmod-needs-dry-run.

[joshmoore]

I can have a look into this actually.

👍

But I think that'll be huge task to rewrite all commands using this 'GraphArg' (tried that for the metadata plugin, and gave up again).

I would think we would write separate Input and Output interfaces to match the --style items which the Controls would use.

[joshmoore]

Reading this again, I wonder:

if just the hql output would be more OMEROish for a start.

Do you mean by just having a list of $class:$id elements? Is that "OMEROish"?

to generally accept the "Type:Id,Id,Id,..." syntax

i.e. ignore everything after the first comma when an entry starts with $class:$id?

[dominikl]

Yes, additionally to the csv, plain, etc. output, hql command should have an option to directly output something like $class:$id, which can be used as input for another cli call. Ideally it should output $class:$id1,$id2,... for multiple objects, but for that to be useful all cli commands/plugins should accept this syntax as input. Unfortuntaly only the GraphControl plugins do that at the moment (using the GraphArg ), the 'default' syntax seems to be handled by the ProxyStringType which does not support multiple objects. But I might be wrong, not easy to get the head around this cli/plugins architecture...

[manics]

See also https://trello.com/c/XaHPIQy4/444-rfe-cli-should-digest-long-lists.
How about move this to a design issue, so we don't end up with more incompatible inputs/outputs for the CLI?