0029222: Removing user/project assigments kills default project in account preferences - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0029222	mantisbt	administration	public	2021-10-25 09:43	2021-11-11 16:01

Reporter	fpaquet	Assigned To	dregad
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	won't fix
Platform	PHP 7.4.25	OS	CentOS7	OS Version	CentOS Linux rel
Product Version	2.25.2

Summary	0029222: Removing user/project assigments kills default project in account preferences
Description	Hello Victor In our local mantis installation, we have some impersonal user accounts for technical issues, like backup failures, sent by machines. The technical sender mail address doesn't allow replies nor any communication. These accounts do not have any project assignment, to prevent sending replies.. We use account preferences / default project to automatically set project on incoming e-mails. This setup is working absolutely fine so far. We think mantis is a great system. Now comes the problem: When we delete one signle project assignment of any other user, all the default project settings will be reset in all technical accounts that do not have any project assigments.
Steps To Reproduce	Project structure: Project1 +- Customer1 (subproject of Project1) +- Customer2 (subproject of Project1) create account A with no project assignment, but default project = Customer1 create account B with project assignment Customer2 and default project Customer2 remove project assignment from account B, reassign to Customer1 As a side effect, these steps will remove default project from account A .
Additional Information	Because we have ~ 100 of these technical accounts, this bug results in roughly 1 hour of clicking to reassign all the default projects.
Tags	No tags attached.

fpaquet 2021-10-25 09:45 reporter ~0065945	Fixed Additional information (no edit possible): Because we have about 100 of these technical accounts, this bug results in roughly 1 hour of clicking to reassign all the default projects.

dregad 2021-10-25 17:24 developer ~0065947	I believe this could be a consequence of 0027144. I do not have time to check in detail, but IIRC since the above-mentioned change, Mantis requires that a user has access to whatever project is set as default. To clarify, are any of the Customer1, Customer2 projects private ? If so, do accounts A and B have an access level allowing them to see private projects ? When you say This setup is working absolutely fine so far, what do you mean exactly by "so far" ? Did you upgrade Mantis then it stopped working ? If so, what version did you upgrade from ?

fpaquet 2021-10-26 03:25 reporter ~0065949	Yes, all projects are private. Account A has access level REPORTER. Account B has access level DEVELOPER. We have started this mantis installation in 01/2021 and made 2-3 upgrades this year. But i couldn't tell you exactly when the problem occured first time, but looking at the commits of https://github.com/mantisbt/mantisbt/pull/1691, this must be a regression of 0027144. So we have a conflict of requirements against 0027144. What can we do about it?

dregad 2021-10-26 17:36 developer ~0065952	What can we do about it? I can't think of a clean solution right now, as I'm not keen on introducing yet another config option for this. I'm open to suggestions, but unless you have a better idea, you may have to customize the source code to achieve your goals.

fpaquet 2021-10-29 09:18 reporter ~0065966	Customizing the source code is fine for us. We will create a patch, test it and publish it here for other people having the same issue. This will take a few days.

dregad 2021-10-31 06:15 developer ~0065974	Thanks for your understanding, and proposing to provide a patch for the community. I'm resolving this as won't fix, as the current behavior is by design to ensure data integrity as described in 0027144.