View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0004202mantisbtbugtrackerpublic2004-07-27 04:582004-08-29 02:01
Reporterdocmarco Assigned Tothraxisp  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version0.19.0a2 
Summary0004202: Project not displayed in [manage projects]
Description

I don't know, if it's a bug.
I created 3 projects, but only 2 of them are manageable via the [manage projects] page.
The "hidden" project is display in the project selector and is assignable to users. But I can't remove this project from a user!

TagsNo tags attached.
Attached Files
mantis projects.jpg (59,258 bytes)   
mantis projects.jpg (59,258 bytes)   
admin.diff (2,306 bytes)    
? mantisbt
Index: manage_proj_edit_page.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/manage_proj_edit_page.php,v
retrieving revision 1.79
diff -u -r1.79 manage_proj_edit_page.php
--- manage_proj_edit_page.php	14 Jul 2004 22:16:34 -0000	1.79
+++ manage_proj_edit_page.php	3 Aug 2004 01:49:59 -0000
@@ -22,7 +22,10 @@
 <?php
 	$f_project_id = gpc_get_int( 'project_id' );
 
-	access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );
+	if ( ! access_has_project_level( config_get( 'manage_project_threshold' ), $f_project_id )
+	    && ! access_has_global_level( ADMINISTRATOR ) ) {
+		access_denied();
+	}
 
 	$row = project_get_row( $f_project_id );
 ?>
Index: manage_proj_page.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/manage_proj_page.php,v
retrieving revision 1.11
diff -u -r1.11 manage_proj_page.php
--- manage_proj_page.php	20 Jul 2004 15:51:50 -0000	1.11
+++ manage_proj_page.php	3 Aug 2004 01:49:59 -0000
@@ -77,10 +77,8 @@
 	foreach ( $t_projects as $t_project ) {
 		extract( $t_project, EXTR_PREFIX_ALL, 'v' );
 
-        if ( !access_has_project_level ( config_get( 'manage_project_threshold' ), $v_id ) ) {
-		  continue;
-		}
-
+    if ( access_has_project_level ( config_get( 'manage_project_threshold' ), $v_id )
+    		|| access_has_global_level ( ADMINISTRATOR ) ) {
 ?>
 <tr <?php echo helper_alternate_class() ?>>
 	<td>
@@ -100,6 +98,7 @@
 	</td>
 </tr>
 <?php
+		}
 	} # End of foreach loop over projects
 ?>
 </table>
Index: core/html_api.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/core/html_api.php,v
retrieving revision 1.114
diff -u -r1.114 html_api.php
--- core/html_api.php	30 Jul 2004 12:46:09 -0000	1.114
+++ core/html_api.php	3 Aug 2004 01:50:00 -0000
@@ -426,7 +426,7 @@
 
 				# Manage Users (admins) or Manage Project (managers)
 				if ( access_has_project_level( config_get( 'manage_project_threshold' ) ) ) {
-					if ( access_has_project_level( ADMINISTRATOR ) ) {
+					if ( access_has_global_level( config_get( 'manage_user_threshold' ) ) ) {
 						$t_link = 'manage_user_page.php';
 					} else {
 						$t_link = 'manage_proj_page.php';
admin.diff (2,306 bytes)   
admin.tar.gz (10,693 bytes)

Relationships

Relationship GraphDependency Graph
related to 0004203 closedthraxisp Administration 
related to 0003483 closedvboctor some admin users permissions not completly upgraded from 0.17.5 to 0.18.0 

Activities

docmarco

docmarco

2004-07-27 06:40

reporter   ~0006385

Last edited: 2004-07-30 06:40

Analyzed the db and it seems to be correct, so far I can judge it.
If I add a 4th project it will be displayed, but still project 3 is not accessible via [manage projects] nor removeable from a user account.
Strange...

edited on: 07-30-04 06:40
thraxisp

thraxisp

2004-07-29 11:23

reporter   ~0006441

Does the user making the change have high enough priveledges on the project (i.e., greater than or equal to $g_manage_project_threshold, defaulting to MANAGER).
docmarco

docmarco

2004-07-29 15:41

reporter   ~0006459

Yes, I think so. As you can see above the user "marco" has admin level. So I guess the priveledges are high enough.
thraxisp

thraxisp

2004-07-29 16:11

reporter   ~0006461

Is the 3rd project "private" and are you on the user's list for it? Have you set a local project access override for the Lit6 project?

If this is a test environment, sending me a copy of the database (privately) would help in debugging this.
docmarco

docmarco

2004-07-29 17:15

reporter   ~0006463

Is the 3rd project "private" and are you on the user's list for it?
Yes, exactly! My priveledges on the Lit6 project are only "developer", but I'm the only admin. So who can change the Lit6 project now - or is it "locked out"?

Have you set a local project access override for the Lit6 project?
What do you mean?
thraxisp

thraxisp

2004-07-29 17:43

reporter   ~0006464

Last edited: 2004-07-29 20:42

>Is the 3rd project "private" and are you on the user's list for it?
Yes, exactly! My priveledges on the Lit6 project are only "developer", but I'm the only admin. So who can change the Lit6 project now - or is it "locked out"?

That's it. In the manage page, you need to be an "admin" or "manager" to manage the project. Your project level downgrade to "devaloper" locks you out of that page. A simple fix would be to delete the appropriate entry from the "project_user_list_table".

Some people set up a completely separate userid as admin. I set myself as admin, but have no overrides set up.

Was this set up in a previous version or with 0.19a2?

edited on: 07-29-04 20:42
docmarco

docmarco

2004-07-30 06:40

reporter   ~0006473

Your project level downgrade to "developer" locks you out of that page
Hmmm, I see. A lock out for a normal user according to his priveledges is absolutely mandatory, no question.
But shouldn't the admin always have all rights to make changes to everything?
A "lock out" for the admin and a db table modification is not pretty good.

Was this set up in a previous version or with 0.19a2?
Yes, this was completely setup with 0.19a2

I can email you my test db if you like, but I guess you're able to reproduce the scenario.
thraxisp

thraxisp

2004-08-02 20:56

reporter   ~0006569

Modules and diffs attached to resolve two problems.

There are two related changes. Administrators are now allowed access to all projects, even if they have downgraded their own privileges. The lower access level still applies for most other actions. Conversely, regular users that have been given administrator access on a project are now handled properly to manage that project.
vboctor

vboctor

2004-08-03 18:07

manager   ~0006613

I think this problem will be fixed by applying the recommended fix in 0003483. I don't agree with the attached patch since it solves the problem in specific pages. I think the problem should be fixed on the API level. In other words, if you check the access for a specific project, you return ADMINISTRATOR if the global access level is ADMINISTRATOR, independent of whether there is a local access level for this project or not. I initially didn't do that to reduce queries, but I think with caching it shouldn't be a problem.
thraxisp

thraxisp

2004-08-03 20:40

reporter   ~0006614

That doesn't address the first scenario. I'm the site admin. but don't want to get messages (for example) for some of the projects. I might re-assign myself as a REPORTER for that project.
vboctor

vboctor

2004-08-03 21:27

manager   ~0006615

That doesn't address the first scenario. I'm the site admin. but don't want to get messages (for example) for some of the projects. I might re-assign myself as a REPORTER for that project.

The way I setup Mantis is to have no notifications sent to the admin user(s). Also I don't use an Admin user for my usual work. This is for two reasons:

  • The same reason for not using "root" account to work on Linux, or "Administrator" to work on Windows.
  • As as Administrator you will see much more than what you need, which is a bit of distraction.
thraxisp

thraxisp

2004-08-04 05:42

reporter   ~0006617

Ok. Should we embed the database script from 0003483 in the upgrades?
vboctor

vboctor

2004-08-04 06:28

manager   ~0006618

See my note in 0003483. Basically, this query fixes the problem, however, it requires (as far as I know) MySQL 4.0 which is higher than minimum requirement. Hence, we need to add something equivalent.
thraxisp

thraxisp

2004-08-06 20:41

reporter   ~0006740

should be resolved by the fix in 0003483