Skip to content

Commit

Permalink
Add user to project when locking themselves out
Browse files Browse the repository at this point in the history 
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 #16554
  • Loading branch information
@dregad
dregad committed Nov 1, 2013
1 parent 47f0ccf commit e08fc01
Showing 1 changed file with 13 additions and 1 deletion.
14 changes: 13 additions & 1 deletion manage_proj_update.php
View file
Expand Up @@ -56,9 +56,21 @@
$f_enabled = gpc_get_bool( 'enabled' );
$f_inherit_global = gpc_get_bool( 'inherit_global', 0 );

access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );
$t_manage_project_threshold = config_get( 'manage_project_threshold' );
access_ensure_project_level( $t_manage_project_threshold, $f_project_id );

# Save current access level to that project, so we can restore it if needed
$t_user_id = auth_get_current_user_id();
$t_access_level = user_get_access_level( $t_user_id, $f_project_id );

project_update( $f_project_id, $f_name, $f_description, $f_status, $f_view_state, $f_file_path, $f_enabled, $f_inherit_global );

# User just locked themselves out of the project by making it private,
# so we add them to the project with their previous access level
if( VS_PRIVATE == $f_view_state && !access_has_project_level( $t_manage_project_threshold, $f_project_id ) ) {
project_add_user( $f_project_id, $t_user_id, $t_access_level );
}

event_signal( 'EVENT_MANAGE_PROJECT_UPDATE', array( $f_project_id ) );

form_security_purge( 'manage_proj_update' );
Expand Down

3 comments on commit e08fc01

@atrol
Copy link
Member

@atrol atrol commented on e08fc01 Nov 1, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

@atrol atrol commented on e08fc01 Nov 2, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

@dregad dregad commented on e08fc01 Nov 2, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're copy/pasting your comments there anyway, I suggest to continue this conversation in http://www.mantisbt.org/bugs/view.php?id=16554

Please sign in to comment.