0032930: issue assigned to person who can't see it after cloning

ID	Project	Category	View Status	Date Submitted	Last Update

0032930	mantisbt	bugtracker	public	2023-09-13 05:59	2023-09-15 01:42

Reporter	diedie2	Assigned To
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	acknowledged	Resolution	open
Product Version	2.25.6

Summary	0032930: issue assigned to person who can't see it after cloning
Description	Image to following setup: Project A \|_Project B User A User B 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.

diedie2 2023-09-13 06:10 reporter ~0068092	typo: it's possible changing the part of changing to issue is enough to simulate it. should be: it's possible the part of changing the issue to another project is enough to simulate it. (to bad users can't edit their own issues here...)

dregad 2023-09-13 06:29 developer ~0068093	Fixed the typo as requested. (to bad users can't edit their own issues here...) Known problem. See 0008141.

dregad 2023-09-14 03:14 developer ~0068099	Reading your report again, it is not really clear, what you think the system's behavior should be. issue under Project A, but assigned to User B, who will never be able to see it (I hope). In particular, the I hope comment kind of implies that this is working as expected...

diedie2 2023-09-14 07:56 reporter ~0068102	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] Well, it implies I hope the security is OK. Otherwise it would mean User B has access to an issue inside a project he/she isn't allowed to and that would be a security issue.

dregad 2023-09-14 13:08 developer ~0068103	Thanks for the clarification. Well, it implies I hope the security is OK. 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.

View Issue Details

Activities