Improve Display of Workflow Status in Facets and Search Results

[mdiggory]

When Items are in Workflow, the "Tasks" list results lack detail about the Step the workflow Item is in. As well, the labels describing Item being claimed ("Validation") and in the task pool ("Waiting for Controller") are confusing terminology that does not immediately convey these state of the workflow item. The labels deviate from labels used for these states in previous version of DSpace.

A solution in this area would:

1. alter the presentation of WorkflowItems to include the Workflow step in the pill or as additional text in the record and
2. change the i18n labels to make better sense for the workflow process.
3. An optional addition that would be of benefit is to add a facet/filter specifically on Workflow Step that can be used to narrow results to only those step(s) of interest.

[tdonohue]

This seems like it's possible two (related) tickets:

• First, the recommendation to change the current status names -- I agree with this and it could be a very small, quick change
• Then, the recommendation to add the name of the workflow step into the filters & label above the item. This seems reasonable, but this may or may not require some backend changes to ensure it works properly.

For now, I'll leave this as one ticket and move to the 7.4 board. The eventual volunteer could decide whether to implement both together or break this apart into two tickets.

[alanorth]

We recently had an editor propose similar feedback. Here is a screenshot from the DSpace 6 workflow where the submissions have the status "Awaiting editor's attention":

There is definitely room for improvement there.

change the i18n labels to make better sense for the workflow process.

I recently submitted a PR suggesting to change "Waiting for controller" to "Waiting for reviewer" (and a few other minor i18n fixes).

[kshepherd]

I would like to also note that the way we use these as facets with a min count of 1 leads to some annoying UX - if I have zero tasks claimed, and I claim a new one, I cannot immediately jump to that filter as it is not displayed - it was zero when the search results were retrieved.

I have a hack for one of my DSpace instances where I use excludeTerms and a facet mincount of 0 to force these facets to both display, but it made me question whether facet-by value (named resource type in this case) was a good approach to this at all, or if we should use some more controlled filter controls, which can use i18n keys instead of a facet display value (will help with the terminology concerns above) and can be displayed based on configuration or context, not naiive interpretation of facets in search results for workflow items.

(my hack example below, note 0 count for one status)