Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Administer Workflow (Abort WorkflowItem, Delete WorkflowItem) #2727

Merged
merged 12 commits into from
May 1, 2020

Conversation

benbosman
Copy link
Member

@benbosman benbosman commented Mar 31, 2020

References

Description

This includes support for building an administer workflow page and the corresponding actions. This is part of beta 3

Instructions for Reviewers

List of changes in this PR:

  • This includes support for the expunge parameter in the DELETE call
  • This adds a workflowAdmin discovery configuration where admins can view all workflow items (not just their own).
  • This moves the code for handling the workspace and workflow items filtering to SolrServiceWorkspaceWorkflowRestrictionPlugin and the indexing to SolrServiceResourceRestrictionPlugin. This removes overrides of the behavior in the SolrServiceImpl

Checklist

  • My PR is small in size
  • My PR passes Checkstyle validation based on the Code Style Guide
  • My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods. (WIP)
  • My PR passes all tests and includes new/updated Unit or Integration Tests for any bug fixes, improvements or new features. A few reminders about what constitutes good tests:
  • If my PR modifies the REST API, I've linked to the REST Contract page (or open PR) related to this change.
  • My PR is compatible with master. (WIP)

@abollini
Copy link
Member

@tdonohue we need your help on that to decide how to proceed

Copy link
Member

@tdonohue tdonohue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@benbosman : Honestly, this approach seems good to me. I only have minor comments after an initial code review. I have not tested this yet.

@abollini : I responded to your question in your thread above. This approach seems to be the same as the current "workflow" configuration in Discovery, so I don't see an issue here (though as I mentioned it might be nice to better document why these index tasks instead of WorkflowItems). That said, we could create a ticket to revisit both configurations at a later time...but I think it's better that the two remain consistent for now.

Comment on lines +72 to +81
} else if (idxObj instanceof IndexableInProgressSubmission) {
final InProgressSubmission inProgressSubmission
= ((IndexableInProgressSubmission) idxObj).getIndexedObject();
dso = inProgressSubmission.getItem();
} else if (idxObj instanceof IndexablePoolTask) {
final PoolTask poolTask = ((IndexablePoolTask) idxObj).getIndexedObject();
dso = poolTask.getWorkflowItem().getItem();
} else if (idxObj instanceof IndexableClaimedTask) {
final ClaimedTask claimedTask = ((IndexableClaimedTask) idxObj).getIndexedObject();
dso = claimedTask.getWorkflowItem().getItem();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily required of this PR, but this big if/else if seems like something we should refactor at some point. It implies to me that IndexableInProgressSubmission, IndexablePoolTask and IndexableClaimedTask should all implement an interface that has a getDSO() (or getRelatedDSO()) method. That would make this easier to extend in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree
We didn't want to change the discovery indexable objects in this PR, but it would definitely improve the functionality here, and can perhaps be used in the future in other locations where the item of any workflow object should be retrieved

dspace/config/spring/api/discovery.xml Outdated Show resolved Hide resolved
@abollini
Copy link
Member

@tdonohue it is not exactly the same scenario. The workflow configuration (maybe we should rename it workflowTasks) is about exposing the task that can be claimed or are already claimed by an user so it is natural that it returns tasks. The workflowAdmin configuration really should expose workflowItem because this is what the admin can abort.

Let me to use an example, we have a custom workflow that assign all submission to two reviewers in parallel. This mean that after one submission we have two claimed tasks, if we use the proposed configuration in this PR we will end to show two "rows" to the admin that can be both aborted.
What we expect if the admin abort only the first one? of course both tasks will disappears because they have the same underlying workflowitem this is surprising for the user. If we want to show only one row it will imply some additional logic on the client side.
If we allow the admins to check multiple rows what will happen when the second row is processed? the rest api will say not found as the workflowitem will not exists anymore (as the first row already abort it), this is why I'm saying that this approach could work but can introduce extra complexity later

@tdonohue
Copy link
Member

@abollini : Please re-review. It looks (to me) like @benbosman and @antoine-atmire decided to update this PR to change the workflowAdmin index to use XMLWorkflowItem instead of the tasks.

@benbosman
Copy link
Member Author

@tdonohue @abollini The REST and Angular PRs have now been updated to return a workflow item instead of a pooled task or claimed task

I was waiting with the other feedback because the impact of this change first had to be evaluated. I'll work with Antoine on the other feedback next

Copy link
Member

@abollini abollini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks fine to me. Thanks @benbosman to have revisited it

Copy link
Member

@tdonohue tdonohue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Looks good to me now as well. Thanks @benbosman and @antoine-atmire !

@tdonohue tdonohue merged commit e4ab84e into DSpace:master May 1, 2020
@tdonohue tdonohue added this to Needs Reviewers Assigned in DSpace 7 Beta 3 via automation Jun 30, 2020
@tdonohue tdonohue moved this from Needs Reviewers Assigned to Done in DSpace 7 Beta 3 Jun 30, 2020
@tdonohue tdonohue added this to the 7.0beta3 milestone Jun 30, 2020
@benbosman benbosman deleted the workflow-item-read-rights branch September 11, 2020 07:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants