View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016554 | mantisbt | bugtracker | public | 2013-10-31 05:46 | 2014-12-08 00:34 |
Reporter | RGM | Assigned To | dregad | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.15 | ||||
Target Version | 1.3.0-beta.1 | Fixed in Version | 1.3.0-beta.1 | ||
Summary | 0016554: 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. | ||||
Steps To Reproduce | Create public Project or subproject | ||||
Tags | No tags attached. | ||||
RGM, I am able to reproduce the issue with a user that has only global manager rights, but you wrote
The user is assigned to the private project as a manager and he does not see the project? |
|
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. |
|
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? Now the user does no longer lock out himself but still locks out other 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. We shouldn't allow that a global manager locks out other global managers. To keep it simple: |
|
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.
They have that by definition... |
|
I meant a project specific manage_project_threshold, not the global one. The workflow would be: 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! |
|
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 ;-)
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 |
|
There are users that like it the other way around, e.g. 0010411 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. |
|
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.
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. |
|
MantisBT: master e08fc01a 2013-10-31 23:50 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 |
Affected Issues 0016554 |
|
mod - manage_proj_update.php | Diff File | ||
MantisBT: master 7fe9e02d 2013-11-03 03:10 Details Diff |
Revert "Add user to project when locking themselves out" This reverts commit e08fc01af521334465e4cd356e8a55c8386960f7. Issue 0016554 |
Affected Issues 0016554 |
|
mod - manage_proj_update.php | Diff File | ||
MantisBT: master 618ffb2c 2013-11-03 03:25 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 |
Affected Issues 0016554 |
|
mod - core/project_api.php | Diff File | ||
MantisBT: master c4bae104 2013-11-04 01:13 Details Diff |
SOAP tests: add case for private project lockout Issue 0016554 |
Affected Issues 0016554 |
|
mod - tests/soap/ProjectTest.php | Diff File |