metadata view: introduce a minimal task metadata view

[oliver-sanders]

Addresses #582
Closes #1896

• Bare bones task metadata view.
• Display task metadata, prerequisites and outputs.
• Display / functionality improvements and support for other information to follow in future PRs.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc - bumped changes entry to a PR (view is likely to change further before release)
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[hjoliver]

Ping @ScottWales @ColemanTom (you were wanting this for viewing prerequisites etc.)

[ScottWales]

Great! thanks for this

[oliver-sanders]

Added offline-data and tests.

Many, many enhancements and features left to add to this view, but will leave it at basic metadata, prereqs and outputs for this PR. The main work here is getting the template for the view in place (it's quite different to other views).

Further enhancements will slot into this template fairly easily provided the required data is present (and accurate) in the schema.

[oliver-sanders]

Documented desired future enhancements in issues:

• info view: better display of prerequisites #1893
• info view: display all jobs and their associated task messages #1894
• info view: display task configuration & broadcasts #1895
• info view: add completion expression info #1896
• info view: markup support #1897
• info view: add task selection controls and enable workflow metadata #1898

[wxtim]

IMO most users will be coming here for the pre-reqs and outputs and not the metadata - these should go first and probably not be collapsed.

Could they go in neighbouring Columns?

Happy to spin this out into an issue and not block this PR.

e.g.:

| Prerequisites |                | Outputs     |
| list of       |   task icon    |             |
------------------------------------------------
| Metadata                                     |   

[oliver-sanders]

Columns aren't an option (or at least aren't always an option) because they won't work in narrow widths.

We can't expand all of the sections by default as there will be a lot of them, from prerequisites, to completion expression satisfaction, to runtime configuration and broadcasts. Prereqs are important, but so are all the other sections.

We could start with nothing expanded, but I thought the title, description and URL (often used to link to documentation) are notably important and deserve to be displayed at all times. Important messages like "do not re-run this task" or "if it fails, try re-running in shortstep mode" will be prominent as a result.

[wxtim]

• Manually tested
• Read PR content

I've made some comments, none of which should block the PR going in if they cost any effort to implement.

[MetRonnie]

This one is inconsistent with the others

Suggested change

	<v-expansion-panel-title color="blue-grey-lighten-2">
	<v-expansion-panel-title color="blue-grey-lighten-1">

[oliver-sanders]

On purpose.

There will be other sections in the near future. I tried adding a few extras and it ended up as a giant block of "blue-grey" which didn't make it especially obvious that these are individual sections that can be expanded.

I thought it was clearer if the sections were striped ("lighten-1", "lighten-2", "lighten-1", ...).

[MetRonnie]

To me it doesn't really indicate clickability, it looks like it's selected or has keyboard focus or something. Not too important

[oliver-sanders]

Unfortunately, this work may be blocked by cylc/cylc-flow#6307 which also imposes some back-compatibility constraints :(

I can hack it for outputs, but I'm not sure I can hack it for prerequisites.

[oliver-sanders]

We could overcome the block by moving from a delta subscription to a regular subscription.

However, this would request the complete data for the task on every change which would get expensive.

[oliver-sanders]

The cylc-flow blocker to this has not been resolved, however, I have come up with a workaround: cylc/cylc-flow#6403

I have also added an output completion expression (closes #1896) so this should now be more or less a direct analogue of cylc show with a similar display interface.

[MetRonnie]

Have you/are you considering a client-side workaround (i.e. in the onUpdated method of the InfoCallback) rather than cylc/cylc-flow#6403 (still in draft)?

Other feedback: to me, these look like bullet points rather than yes/no indicators. (Tested on Windows, FF & Chrome)

[oliver-sanders]

Have you/are you considering a client-side workaround

It's possible, but it would require iterating over the received delta and the fix would only apply to the info view and not to other views which might want this information (e.g. the tree view currently uses it).

I think the long-term fix should be cylc-flow end so would rather stick any bodges / workarounds there if possible. Happy to undraft the hack PR, was hoping we could come up with a more global fix.

[hjoliver]

Unblocked by merge of cylc/cylc-flow#6403 ... I think