nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

RapidBoard, default workflow, and setting issue in progress on behalf of others

Stevo Slavic2

On RapidBoard by default:

One can set assignee to TODO issue other than himself.
One can set assignee to TODO issue to himself.
One can set issue in progress only if issue is assigned to himself.
One can change assignee of in progress issue to somebody else.

So default workflow allows difficult way with extra step to set issue in progress on behalf for others, but not more directly (by setting assignee for TODO issue to somebody else, and setting it in progress).

Is there any special reason for this behaviour, not allowing more direct way of setting issue in progress on behalf of others?

We'd like this to be possible, for virtual scrumboard (RapidBoard work tab) for distributed scrum, when doing "standups" remotely, sharing view on scrumboard and all being in control of the screen (changing state of issue) while only one user is actually logged in JIRA/GreenHopper.

Accepted answers

Jobin Kuruvilla [Adaptavist]

It is the default behavior based on the assumption that the person working on an issue will be the assignee himself. But if your process demands someone else to do that for the assignee, you can just modify the workflow to remove that workflow condition.

You can also add different conditions like people in certain groups or roles can do it and not just assignee.

All comments

Jobin Kuruvilla [Adaptavist]

You can also add different conditions like people in certain groups or roles can do it and not just assignee.

Stevo Slavic2

"..assumption that the person working on an issue will be the assignee himself."

Yes, assignee is doing the work on issue, nobody's questioning that.

Problem is that issue assigned to one person cannot be set to in progress by other person, on RapidBorad. Still, it is possible to assign issue to oneself, set it in progress, and then assign it to somebody else resulting in same outcome (issue assigned to other person and in progress), but with extra step.

So default workflow scheme is not consistent, allows one workflow, but not the other both resulting in same outcome. To make it consistent either:

changing assignee to somebody else should be disallowed while issue is in progress, or
changing assignee to somebody else while issue is in progress can remain to be allowed, but than it should also change issue status, from in progress to todo, or
setting issue in progress on behalf of others should be allowed on RapidBoard (when assignee is not set and issue is dragged from todo to in progress then set current user automatically, or ask for assignee to be chosen offering automatic as first choice).

I'm in favour of last option.

Jobin Kuruvilla [Adaptavist]

You can do any one of these. You just need to modify the workflows accordingly. It is just that the default workflow is designed without this but it doesn't prevent you from modifying it as you need.

And regarding the extra step, it shows that the person who assigned the issue to himself takes the ownership and that is why the extra step is important. But again, different perspectives

Stevo Slavic2

For an issue which is in progress I'm allowed to change assignee to someone else, and issue stays in progress, for that other asignee without that person's consent.

For an open issue I'm allowed to change assignee to someone else, but not change status to be in progress.

For me this is not consistent and wrong. I understand I can change it by making custom workflow, but IMO better solution would be to change default workflow itself. Currently default one prevents me to do one thing in one way, but not to do same thing in another way with extra steps. Unless idea is to bug users with extra steps, please consider changing default workflow.