And suddenly, more than 6 years later, nothing happend. Problem still existing.

And suddenly, more than 6 years later, nothing happend. Problem still existing.

Hello,

This was marked as duplicate.

However in the related issue JRA-39112 there is no mention of there being a problem with the reporter too (except for the comment that I made myself).

Would you be so kind and update the description (and subject) of the related/duplicated issue.

Thanks.

Let me note that this is also a regression as at least checking for a suitable assignee still worked in Jira 5.2 that we had before the upgrade to Jira 6.

Ack tim.schlueter, I am raising the priority to Major as the issue has no known workaround at the moment.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Is it possible to raise the priority of this issue beacause it's Kind of a security issue.

Let me just add that users do not necessarily have an intimate knowledge of Jira and therefore click where they can. If they don't get an error message, then it's ok for them. The software should protect against impossible scenarios.

I have now written a few reporting scripts that point out these issues to me so I can counteract manually, but that is administrative overhead that need not be at all if someone had thought this through to the end.

Allowing issues to be unassigned may not be enabled.

Workaround : Before moving an issue to another project/issue type, always ensure to unassigned the assignee first.

Of course one should say that the system probably cannot set a "default reporter" as there is no such thing.
It comes to the users of the projects to set the reporter correctly.
However, you should not be able to move if the reporter has no permissions in the destination, that part is correct.

I would consider a plain move a basic operation of the system, therefore I wonder: are there no unit tests testing these things? Is this really of minor priority?