RGM, I am able to reproduce the issue with a user that has only global manager rights, but you wrote

The user has global manager rights AND ALSO IN THE PROJECT

The user is assigned to the private project as a manager and he does not see the project?
Really?

We should display a warning message if a user would lock out himself when changing project to private or we should automatically assign him to the project.

we should automatically assign him to the project

I think this is a better approach. I'll take care of it

Should we add this also to function mc_project_update or add it to function project_update to avoid redundant code?
Or is it the responsibility of the SOAP client to handle this case?

Now the user does no longer lock out himself but still locks out other managers.
Do we have to add ALL global managers?

Some more thoughts:

There are use cases where adding just the current user is wanted, there are other use cases where some of the global managers (most of the time not all) should be added.
There can't be an automatism which fits all.

We shouldn't allow that a global manager locks out other global managers.

To keep it simple:
Undo the project_add_user functionality.
Allow the setting to "private" only if the current user has already manage_project_threshold rights for the project or has create_project_threshold rights.
Introducing set_project_private_threshold is a bit too much for it.

I did think about this before implementing the change, but I reached different conclusions.

IMO the main goal to set a project private, is to prevent people from having access to it by default.

Because of this, we should avoid/limit adding users to the project, especially in a "background" way that could escape the attention of the manager/admin making the change as that could go against the initial intention.

For the same reason, I think it does make sense to "lock out other global managers", considering that it is the responsibility of the manager who wants to make a project private, to manually add the people who should have access to it after updating the project.

However, they cannot do this if they are locked out, hence it is justified to only add the manager making the change.

Allow the setting to "private" only if the current user has already manage_project_threshold rights for the project

They have that by definition...

Allow the setting to "private" only if the current user has already manage_project_threshold rights for the project

They have that by definition...

I meant a project specific manage_project_threshold, not the global one.

The workflow would be:
First ask your administrator to add you as manager to the project. (exactly what you automated)
After that you would be allowed to set the state to "private", but not all other global managers.

Maybe we should also think about changing the default view status from public to private for new projects.

I have updated the code and asked the user to check. Thanks!

The workflow would be:
First ask your administrator to add you as manager to the project. (exactly what you automated)
After that you would be allowed to set the state to "private", but not all other global managers.

Don't know... sounds like over-engineering things and making the process more complicated than it should be.

I think we should be working under the assumption that a manager setting a project to private knows what they are doing, and they would subsequently grant access to whomever needs it; the admin can then be contacted only by unhappy users ;-)

Maybe we should also think about changing the default view status from public to private for new projects.

I don't think so. I like the approach where things are open by default, and you can lock things down if you need it. Considering the overhead to manage private projects, we should not make them the default.

@RGM - thanks, let us know your feedback.

FYI, I'll probably revisit this, following atrol's comment 0016554:0038422

Considering the overhead to manage private projects, we should not make them the default.

There are users that like it the other way around, e.g. 0010411
As always if there is no common opinion: Introduce one more configuration option, something like $g_default_project_view_status

But I hesitate to enter a feature request for it as we shouldn't introduce too much new options before having introduced a more generic access control, e.g. 0005381 and related issues.

Probably nothing we will see in 1.3.

To finish the discussion in this thread: I am Ok with your changes.

@dregad - I see you've issued a new PR on Github. Should we reopen this bug then?

Also, wouldn't it be simpler to just fail fast when the user would lock themselves out? This way the block is explicit, rather than the user thinking that the action did not occur for other reasons ( clicked the wrong button, MantisBT bug, etc ).

Some feedback is IMO preferrable to no feedback.

Should we reopen this bug then?

The bug is still effectively resolved by the original fix, the PR (https://github.com/mantisbt/mantisbt/pull/121) is just an improvement based on atrol's comment 0016554:0038422, that's why I did not reopen.

wouldn't it be simpler to just fail

I actually thought about triggering an error to abort the update, but then I went for this solution instead as I thought it was more user friendly. I can't think of a situation where things would fail and cause a block.