[MGNLUI-4232] A user should be able to reassign a task Created: 15/Jul/15  Updated: 29/Aug/17  Resolved: 14/Jul/17

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.4.6
Fix Version/s: 5.5.6, 5.6

Type: Improvement Priority: Neutral
Reporter: Richard Gange Assignee: Hieu Nguyen Duc
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: 0d
Time Spent: 5.5d
Original Estimate: 4d

Attachments: PNG File assigneeAdded.png    
Issue Links:
Cloners
is cloned by MGNLWORKFLOW-357 CLONE - A user should be able to reas... Closed
Relates
causality
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Saigon 102, Saigon 103, Saigon 104
Story Points: 5

 Description   

If a user takes control of a task they should be able to release the task without taking any action of approve/reject/abort.



 Comments   
Comment by Mikaël Geljić [ 18/May/17 ]

How about letting the Assign to me action stay available, even when task is already claimed?

—I can foresee an additional human-task in the default workflow to support that; but that would be fairly minimal, especially *without* unassigning tasks nor choosing who to assign them to (which may additionally require UI/action changes).

Comment by Richard Gange [ 19/May/17 ]

I guess that would be ok. It would nice if the person who lost assignment got notified. Otherwise how would they know.

Comment by Mikaël Geljić [ 28/Jun/17 ]

Update upon hieu.nguyen's investigation:

Task assignment is done purely on the Magnolia side, via TasksManager#claim; which means there is no notion of user-assignment on the BPM side, for our default workflow. Therefore, it's safe to allow users to reclaim the task, by loosening action-availability a bit. We know this works already.

Re: notification, it would likely come in the shape of a pulse message sent to the previous assignee (again, from the ClaimTaskAction).

For both of these points, we could optionally add a couple config flags to ClaimTaskActionDefinition:

  • allowReassigning, true by default
  • notifyPreviousAssignee, true by default

—just so we don't enforce the behavior change without any way to roll back to the previous behavior. How does that sound?

Comment by Viet Nguyen [ 29/Jun/17 ]

Imo a new 'assignee' field with value of 'username' in Task 'messageViews' would also be useful for both user and implementation.

Comment by Mikaël Geljić [ 29/Jun/17 ]

viet.nguyen I see, assignee is shown in the list view, but not in the detail view.
It's actually easy to do: field name must be actorId, but then we also need to make sure the detail view is refreshed when re-assigning.
Hieu will decide if it's a quick win, or if we do that with a follow-up

Generated at Mon Feb 12 09:14:36 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.