View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0032930||mantisbt||bugtracker||public||2023-09-13 05:59||2023-09-15 01:42|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Summary||0032930: issue assigned to person who can't see it after cloning|
Image to following setup:
User A has acces to Project A and B. User B can only acces Project B.
After cloning and changing the project, I had an issue under Project A, but assigned to User B, who will never be able to see it (I hope).
|Steps To Reproduce|
In the above setup, create an issue under Project B and assign it to User B. Clone the issue and change the project to Project A afterwards. The cloned issue is still assigned to User B, who will never be able te see it.
To be honest, I'm not sure if cloning is necessary, it's possible the part of changing the issue to another project is enough to simulate it.
(Edited per 0032930:0068092)
|Tags||No tags attached.|
(to bad users can't edit their own issues here...)
Fixed the typo as requested.
Known problem. See 0008141.
Reading your report again, it is not really clear, what you think the system's behavior should be.
In particular, the I hope comment kind of implies that this is working as expected...
well, the problem is that there is possibility there is an issue assigned to or created by an user that hasn't access to it (anymore). If User A waits for a reply or feedback from User B, he/she will wait a long time as User B will never see it and thus will never reply to it.
A solution could be an error message just before changing the project of an issue (if the target project is not accessible for the creator and/or the assigned user)? Or a yes/no question, and if accepted, the "assigned to" is made blank.
If you even think further about it, what if the rights for User A are removed for project A and now have the same rights as User B. That would cause the same problem.
What about users following the issue? Are those kept?
[quote]In particular, the I hope comment kind of implies that this is working as expected...[/quote]
Thanks for the clarification.
It is. Being assigned to an issue does not otherwise grant any rights to it, so if it is moved to a project the user has no access to, they will get an error if they try to open it.
As for changing the assignment or raising an error when moving the issue, it's feasible but I need to think about it. As you pointed out, this is just one of many use cases where a meaningless / unusable assignment persists.
For consistency, all such scenarios should be identified and treated in a similar manner.