cli: implement new share-status command

[DaanRosendal]

For the workflow sharing sprint, design and implement a share-status command allowing users to view who a workflow has been shared with.

For example, Alice enquires with whom she shared her myanalysis run 42:

reana-client share-status -w myanalysis.42
myanalysis.42 has been shared with:
- bob@example.org
- cecile@example.org

The CLI could have JSON output for easy piping into user scripts (as the list, status etc commands):

reana-cilent share -w myanalysis.42 --json | jq
[ 
    "bob@example.org",
    "cecile@example.org"
]

[tiborsimko]

1) Note that the output should also include expiry date. We could perhaps go for something similar to the list output:

$ reana-client share-status -w myanalysis.42
USER                   EXPIRY_DATE
bob@example.org        9999-12-31T23:59:59
cecile@example.org     2023-11-05T18:41:57

The expiry date is optional, but it may be good to use some value for sorting purposes, and schema validation purposes, hence the illustrative use of year 9999 in the example above.

2) We could also think about not showing the expiry date by default, and show it only when people use --include-expiry-date. In this case, the output of the original bare share-status command could be a simple list of values only, one user email per line:

$ reana-client share-status -w myanalysis.42
USER
bob@example.org   
cecile@example.org 

3) Note also that we shall later introduce sharing to groups, so the heading of USER may not be the best. We should take it into account whilst designing the CLI options and command output column names. We could later use perhaps USER_OR_GROUP, but we may want to come up with something more neutral or otherwise descriptive that would be independent of the notion of a user or a group, for example:

$ reana-client share-status -w myanalysis.42
SHARED_WITH            SHARE_EXPIRES
bob@example.org        9999-12-31T23:59:59
cecile@example.org     2024-11-05T18:41:57
myteam@cern.ch         9999-12-31T23:59:59

We should consider this together with the CLI option names for the list command in #687.

[DaanRosendal]

Since it's only two columns, I think providing both the user/group and the expiry date with the default command is nicer. I will work on implementing this command like you displayed in point 3.

On a different note, what do you think of share-list instead of share-status?

[tiborsimko]

OT1H, share-list would be nicely understandable with respect to share-add and share-remove, and also nicely analogous to secrets-list.

OTOH, I would see one concern is that it might possibly create a confusion with the list command.

For example:

• With whom am I sharing "foo" analysis? -> share-list -w foo
• Who is sharing an analysis "foo" with me? -> list --shared-by=anybody --filter name=foo.
• ... and what happens when one tries to do things like: list --shared-by=myself --filter name=foo.

This concern could be possibly alleviated if we prefix existing commands, such as:

• create -> workflow-create
• list -> workflow-list
• ...
• ls -> workspace-ls
• ..

Then share-list and workflow-list wouldn't possibly be confusion-prone anymore. But such a renaming, keeping older compatibility option, is to be carefully pondered.

We can muse IRL about pros/cons about where we would like to go and see based on that?

[DaanRosendal]

I really like the idea of using clear prefixes for commands to avoid any confusion. Commands like workflow-list and share-list are straightforward and distinct. On the other hand, when it comes to non-prefixed commands like close and stop, it's not immediately apparent what they do. If I had to guess between the two, I wouldn't be sure which one closes or stops an interactive session. Switching to more explicit commands like interactive-session-close and workflow-stop may require some adjustment for users, but it seems like a sensible trade-off for improved clarity. If backward compatibility is a concern, we could always maintain the current commands as aliases.

Implementing and testing these new commands, as well as maintaining backward compatibility with aliases, could take some effort. We should weigh whether the enhanced clarity justifies the resources required for this transition.