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; } } }

Move permission for Assignee and Reporter possible?

Hi,

is it possible to set Move permission to the current assignee and the Reporter?

There are options to select, but users assigned with only this permission are unable to see the "Next" button in the Move screens.

Once they are added to explicit roles with this permission, the button is available.

Is there some kind of limitation to the use of "Current Assignee" and "Reporter" for Move permission?

Thanks!

Stefan

Accepted answers

It is a bit obscure use case as moving issues is typically done by project members.

The documentation does not state this explicitly as far as I can tell, but I reckon you would also need some of the following permissions to "Move" issues:

* Edit issue in the source project (because, well, the issue is still there and is edited before it belongs to another project; or you are just switching issue types, thus still editing the same project)

* Create issue permission in the destination project (but this does not apply here since you say the option to move doesn't even come up)

It's not clear to me whether the user is doing 'move' from issue view, or whether it's a bulk edit.

With a single issue that becomes easy to check step by step. If it's a bulk edit, it will stop you from moving anything if just a single one of the issues you don't have a permission for.

So just to be safe, does the reporter/assignee have edit permissions?

If so, does the workflow status have any properties on it that might further limit permissions?

If the answer to both of these are yes and no respectively, then that seems like a bug.

All comments

Hi @Stefan Stadler

Project roles provide the primary modification possibilities on a ticket.
Further restrictions can be added using status transition properties that reside in the workflow.
For the latter you can use the current assignee and reporter designations.

Hope this helps,

Dick

I have assigned the "ProjectLeader", "Administrators", "Current Assignee", "Reporter" the permission to Move issues in a project. All 4 settings are currently applied, but it seems that the users are only able if they are assigned the "ProjectLeader" role. Having them assigned to an issue does not allow them to move this issue.

Is this something that is expected?

No restrictions on the workflow are applied.

It is a bit obscure use case as moving issues is typically done by project members.

The documentation does not state this explicitly as far as I can tell, but I reckon you would also need some of the following permissions to "Move" issues:

* Edit issue in the source project (because, well, the issue is still there and is edited before it belongs to another project; or you are just switching issue types, thus still editing the same project)

* Create issue permission in the destination project (but this does not apply here since you say the option to move doesn't even come up)

It's not clear to me whether the user is doing 'move' from issue view, or whether it's a bulk edit.

With a single issue that becomes easy to check step by step. If it's a bulk edit, it will stop you from moving anything if just a single one of the issues you don't have a permission for.

So just to be safe, does the reporter/assignee have edit permissions?

If so, does the workflow status have any properties on it that might further limit permissions?

If the answer to both of these are yes and no respectively, then that seems like a bug.

Hi @Radek Dostál ,

thanks for bringing this up. This is for single move of an issue.

I can confirm that the current assignee has permissions for both Move and Edit issues:

And the workflow does not have any properties set in this status. Additionally, assigning the user to the Developers role did not help to move the issue, but assigning to "ProjectLeader" helped to make him move the issue.

This is a very strange behaviour and - according to what you mentioned - this appears to be a bug, right?

Thanks!

Stefan

Yup I think so, there shouldn't be anything else missing. Was looking for it on Atlassian bug tracker earlier but didn't find a match - it's becoming a bit time consuming to swim through hundreds of issues so I didn't check all of them (I usually browse here between work), but I would say it's worth sending over to Atlassian as a bug report, nothing else comes to mind.

My best guess is that probably something down there on code level is checking whether the user has project permission, but not issue permission - when evaluating the conditions in webUI - there are 2 different ways to check those on API level so it probably does not quite check it right on issue level (this would explain why it works as a role member). Just a guess though could be wrong, but for sure seems bugged either way.

Hi @Stefan Stadler ,

Why are there no groups of people assigned to the Current Assignee and Reporter headings in your list behind the asterisks? You should add people that can be the assignee and reporter.

The interface btw looks different with that respect to the 9.12.11 datacenter version I'm working with. (my version doesn't have these headings anymore). I think that these two headings were removed in a later version, because people were misinterpreting them often (as might be in your case).

Hope this helps,

Dick

now I think there is a misunderstanding: The setting is made correct and also in the UI there are no options for specifying any groups of users who can be assignee. See here for the setting made:

I cannot update to a later version, but version 9.4.1 is our current one and there might have been changes - that is for sure.

But from a technical perspective, if the setting has been made as per the above dialog, I would expect the assignees to be able to move the issue.

Regards,

Stefan

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server

jira-data-center

data-center