View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0007125mantisbtbugtrackerpublic2006-05-23 20:102007-12-21 23:16
ReporterchillaxAssigned Tograngeway  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.3 
Target Version1.1.0Fixed in Version1.1.0a4 
Summary0007125: Application Error #200
Description

Requires more than one project in installation.
Change the status of a bug in Project A (resolve for example)
Don't actually change the status but just get to the page where you set the resolution, etc.
Change to Project B from the dropdown on this page (bug_change_status_page.php)

Should give you an application error #200
"A required parameter to this page (bug_id) was not found."

Additional Information

Expected result:
Take me to the bug listing for the project I selected from the dropdown.

TagsNo tags attached.

Activities

runner80

runner80

2007-05-16 04:37

reporter   ~0014539

I have the same issue with 1.0.6 and 1.0.7. Is there any resolution yet?
vboctor

vboctor

2007-05-18 03:02

manager   ~0014551

Confirmed on latest code as of today. Is there a use case which cause you guys to hit this often? For now, I've target the fix for 1.1.0. Patches are welcome.
elmsfu

elmsfu

2007-06-06 12:12

reporter   ~0014690

Clarification: This is actually a bug for several pages (manage project, ). Any page that requires data from the gpc api to render. Also you don't have to change any of the drop downs.

Problem: If the name ends in '_page.php' then set_project.php redirects to the referencing page. However, it doesn't pass on any variables via GET or POST, hence the error.

Suggested Solution: I think the best solution is to reload the same page only for a explicit list of pages (My View, homepage, view issues, summary page).

I'll get a patch up soon.
runner80

runner80

2007-06-20 10:45

reporter   ~0014780

No, I don't hit this often, so I can wait for the 1.1.0 fix. Thanks for the info!
roleary

roleary

2007-07-29 02:32

reporter   ~0015269

Personally, I think a better fix for this might be to either disable or hide the Project selection drop-down on certain project-specific pages. If a user is working with a specific bug, it doesn't make sense for them to change the project anyway, since the bug is project-specific. If they did, where would you take them? Back to View Issues or something? Seems to me it would make more sense to just disable the project selection in the first place.

Not to mention it would be easier to implement ;)
grangeway

grangeway

2007-07-30 14:01

reporter   ~0015301

A fix for bug_change_status_page.php will be included in 1.1.0a4