View Issue Details

IDProjectCategoryView StatusLast Update
0016554mantisbtbugtrackerpublic2014-12-08 00:34
ReporterRGMAssigned Todregad 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.15 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0016554: Project privacy change from public to to private kicks manager out
Description

When a project manager changes the privacy from public to private, he can't see the project anymore.
The user has global manager rights and also in the project.

Steps To Reproduce

Create public Project or subproject
Change privacy to private
--> No user except the global admin has access to the project

TagsNo tags attached.

Relationships

related to 0014857 acknowledged Project view status 
related to 0010411 assignedvboctor Changes to project_view_state and view_state to create only private projects 

Activities

atrol

atrol

2013-10-31 17:55

developer   ~0038406

Last edited: 2013-10-31 18:19

View 2 revisions

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?

atrol

atrol

2013-10-31 18:17

developer   ~0038407

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.

dregad

dregad

2013-10-31 20:10

developer   ~0038409

we should automatically assign him to the project

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

atrol

atrol

2013-11-01 17:29

developer   ~0038422

Last edited: 2013-11-01 17:30

View 2 revisions

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?

atrol

atrol

2013-11-02 03:27

developer   ~0038424

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.

dregad

dregad

2013-11-02 06:37

developer   ~0038425

Last edited: 2013-11-02 06:51

View 2 revisions

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...

atrol

atrol

2013-11-02 08:15

developer   ~0038426

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.

RGM

RGM

2013-11-06 04:51

reporter   ~0038450

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

dregad

dregad

2013-11-06 11:24

developer   ~0038451

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.

dregad

dregad

2013-11-06 11:46

developer   ~0038452

@RGM - thanks, let us know your feedback.

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

atrol

atrol

2013-11-06 12:11

developer   ~0038453

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.

rombert

rombert

2014-01-27 04:15

developer   ~0039197

@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.

dregad

dregad

2014-01-27 05:10

developer   ~0039198

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.

Related Changesets

MantisBT: master e08fc01a

2013-11-01 03:50:27

dregad

Details Diff
Add user to project when locking themselves out

Automatically add the current user with their access level to the
project's user list if after updating it they can no longer access it
(i.e. by making it private).

Fixes 0016554
mod - manage_proj_update.php Diff File

MantisBT: master 7fe9e02d

2013-11-03 08:10:03

dregad

Details Diff
Revert "Add user to project when locking themselves out"

This reverts commit e08fc01af521334465e4cd356e8a55c8386960f7.

Issue 0016554
mod - manage_proj_update.php Diff File

MantisBT: master 618ffb2c

2013-11-03 08:25:03

dregad

Details Diff
Add user to project when locking themselves out

Automatically add the current user with their access level to the
project's user list if after updating it they can no longer access it
(i.e. by making it private).

Reimplements e08fc01af521334465e4cd356e8a55c8386960f7, but at the API
level (ie. the logic is now in project_update() function instead of
manage_proj_update.php), so Mantis behave consistently from GUI as well
as SOAP.

Fixes 0016554
mod - core/project_api.php Diff File

MantisBT: master c4bae104

2013-11-04 06:13:15

dregad

Details Diff
SOAP tests: add case for private project lockout

Issue 0016554
mod - tests/soap/ProjectTest.php Diff File

Issue History

Date Modified Username Field Change
2013-10-31 05:46 RGM New Issue
2013-10-31 17:55 atrol Note Added: 0038406
2013-10-31 17:55 atrol Status new => feedback
2013-10-31 18:17 atrol Note Added: 0038407
2013-10-31 18:19 atrol Note Edited: 0038406 View Revisions
2013-10-31 20:10 dregad Note Added: 0038409
2013-10-31 20:10 dregad Assigned To => dregad
2013-10-31 20:10 dregad Status feedback => assigned
2013-10-31 20:11 dregad Target Version => 1.3.0-beta.1
2013-11-01 13:02 dregad Changeset attached => MantisBT master e08fc01a
2013-11-01 13:02 dregad Status assigned => resolved
2013-11-01 13:02 dregad Resolution open => fixed
2013-11-01 13:02 dregad Fixed in Version => 1.3.0-beta.1
2013-11-01 17:29 atrol Note Added: 0038422
2013-11-01 17:30 atrol Note Edited: 0038422 View Revisions
2013-11-02 03:27 atrol Note Added: 0038424
2013-11-02 06:37 dregad Note Added: 0038425
2013-11-02 06:51 dregad Note Edited: 0038425 View Revisions
2013-11-02 08:15 atrol Note Added: 0038426
2013-11-02 08:18 atrol Relationship added related to 0014857
2013-11-02 08:19 atrol Relationship added related to 0010411
2013-11-06 04:51 RGM Note Added: 0038450
2013-11-06 11:24 dregad Note Added: 0038451
2013-11-06 11:46 dregad Note Added: 0038452
2013-11-06 12:11 atrol Note Added: 0038453
2014-01-27 04:15 rombert Note Added: 0039197
2014-01-27 05:10 dregad Note Added: 0039198
2014-02-04 10:39 dregad Changeset attached => MantisBT master 7fe9e02d
2014-02-04 10:39 dregad Changeset attached => MantisBT master 618ffb2c
2014-02-04 10:39 dregad Changeset attached => MantisBT master c4bae104
2014-12-08 00:34 vboctor Status resolved => closed