View Issue Details

IDProjectCategoryView StatusLast Update
0005861mantisbtadministrationpublic2005-09-11 08:12
Reportermalaussena Assigned Tothraxisp  
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Versiongit trunk 
Fixed in Version1.0.0rc2 
Summary0005861: APPLICATION ERROR 0000700 on manage_proj_edit_page.php?project_id=xx
Description

When I click on manage_proj_edit_page.php for a project with a user as MANAGER, Mantis returns an APPLICATION ERROR 0000700. See (manage_proj_edit_page.jpg).

No problems with a user as ADMINISTRATOR.

Managers have rigths to manage or create projects...

I got this problem since the last CVS HEAD (I have installed all files modified in the last 9 days.

TagsNo tags attached.
Attached Files
manage_proj_edit_page.jpg (54,685 bytes)   
manage_proj_edit_page.jpg (54,685 bytes)   

Relationships

has duplicate 0006032 closedthraxisp APPLICATION ERROR 0000700 when managing project 
has duplicate 0006087 closedthraxisp Application error when adding subprojects to manager 
has duplicate 0006181 closedthraxisp Can't load the Manage Profile view with Manager profile. 
child of 0005460 closedvboctor Critical Issues to Fix for Mantis 1.0.0 Release 

Activities

malaussena

malaussena

2005-06-30 04:36

reporter   ~0010647

Returning back to manage_proj_edit_page.php v 1.88 solves issue.

thraxisp

thraxisp

2005-07-22 12:15

reporter   ~0010922

I can no longer reproduce this in CVS HEAD. There were some changes in this area. Can you re-test this?

dantec

dantec

2005-07-25 08:29

reporter   ~0010941

I have the same problem with the 1.0.0rc1 release.

Ok with 1.88 version.

thraxisp

thraxisp

2005-07-25 11:07

reporter   ~0010945

I think that I may have found the problem, although I cannot positively prove that it fixes the problem, since I can't reproduce it.

The following patch should help:
diff -u -r1.91 manage_proj_edit_page.php
--- manage_proj_edit_page.php 19 Jul 2005 13:42:49 -0000 1.91
+++ manage_proj_edit_page.php 25 Jul 2005 13:33:55 -0000
@@ -240,7 +240,7 @@
foreach ( $t_projects as $t_project ) {
if ( in_array( $t_project['id'], $t_all_subprojects ) ||
in_array( $f_project_id, project_hierarchy_get_all_subprojects( $t_project['id'] ) ) ||

  • ! access_has_project_level( $t_manage_access, $t_project ) ) {
  • ! access_has_project_level( $t_manage_access, $t_project['id'] ) ) {
    continue;
    }
    ?>

Would it be possible for one of you to test this before I commit it?

thraxisp

thraxisp

2005-07-25 11:08

reporter   ~0010946

Reminder sent to: toddpw

toddpw, this is the problem that we were discussing on the IRC yesterday. This may help.

thraxisp

thraxisp

2005-07-25 17:59

reporter   ~0010953

I managed to reproduce this by deleting project with id=1. The fix above resolves it. I'll wait for confirmation before committing it.

toddpw

toddpw

2005-07-25 22:29

reporter   ~0010955

I verified with phpMyAdmin that our project id's 1, 2, 3, and 5 had been deleted (they don't appear in mantis_project_table). I'll re-try the upgrade with this applied.

dantec

dantec

2005-07-26 02:59

reporter   ~0010958

thraxisp,

I test your patch, it's OK for me. No more error.

Thanks.

toddpw

toddpw

2005-07-26 07:01

reporter   ~0010961

The patch also works for me.

masala

masala

2005-07-26 08:40

reporter   ~0010963

had the same problem after upgrading from a3 to rc1
the patch solved the problem

thraxisp

thraxisp

2005-07-26 08:41

reporter   ~0010964

Submitted patch to CVS.

manage_proj_edit_page.php -> 1.92