Auto-assigned workflow tasks include a broken "return to pool" button on /mydspace

[ybnd]

Describe the bug The "Return to pool" button still shows up even though the WFI was assigned automatically and can't be returned to the pool.

We make the assumption that all claimed tasks work with a pool, but this is not the case for most user assigning ations:

• AssignAction
• AssignOriginalSubmitterAction
• AutoAssignAction
• InheritUsersAction

It's not immediately clear to me how we would address this, the first thing that comes to mind would be to

• not add the "return to pool" to claimed tasks button by default (also: "claimed" is confusing)
• instead, include return_to_pool in REST depending on the usesTaskPool value of the preceding user assignment action

To Reproduce Go through the steps listed in #8400 In the final step, the workflow task that was automatically assigned to the original submitter will include the "Return to pool" button. Clicking on it results is a HTTP 500 error.

Expected behavior Workflow tasks that don't have an associated task pool should not give the user the option to return them to the pool.

Related work https://github.com/DSpace/DSpace/pull/8400

[tdonohue]

Because this bug doesn't impact the "defaultWorkflow" workflow tasks/actions (i.e. the default enabled workflow), I think it's directly related to #770 (and https://github.com/DSpace/DSpace/issues/2841)... The root issue here is that currently (as of 7.3), the "defaultWorkflow" behavior is somewhat hardcoded into the codebase. Other steps/actions do not fully work as they cannot be loaded dynamically from the backend.

So, I'm going to move this over to the Tier 3 board alongside those tasks. I think it needs to be solved as part of that effort.

[tdonohue]

Closing, fixed by #2039 (which closed related #770)