View Issue Details

IDProjectCategoryView StatusLast Update
0009480mantisbtcustomizationpublic2014-11-07 16:32
Reporternorthstar Assigned To 
Status acknowledgedResolutionopen 
Product Version1.2.0a2 
Summary0009480: Manage Config>manage columns - APPLICATION ERROR #700 Project '0' not found

After changing some columns under 'Manage Config>manage columns' and hitting button 'update columns as global default', I get error :
Project '0' not found.

Not sure if this has anything to do with the fact that I have deleted the project 'General' earlier on. This project comes supplied with the installation but I do not need it.





2008-08-07 10:02

reporter   ~0019077

i have the same problem.

  1. this happens if you are in "all projects"
  2. the caption for the button is 'update columns ... for all projects' but it sets the columns for a selected project

i like this way to configure columns. there should be the possibility to set the columns for all projects AND for a selected project



2008-08-27 02:28

reporter   ~0019253

The naming of the button "Update Columns as Global Default for All Projects" is a bit misleading because it does not update the columns for all Projects but only for the active (selected) project (dropdown in the right upper corner).

As far as I can see the button "Copy columns to" for a chosen project does not work too - no columns were updated/added when I checked table mantis_config_table afterwards...

Workaround: If you need to have columns set for all projects just set project_id in table mantis_config_table to 0 for the required fields...



2008-09-04 19:30

reporter   ~0019307

This issue is marked as resolved many versions ago. I just installed version 1.1.2, created one project, and I got the same error when I tried to manage the configuration. dominik has it right: changing the mantis_config_table to 0 does the trick. I think this needs to be an installation issue, because the config table has a value of 20 in there for some reason right after installation. The error is caused by trying to find a project with id=20, which of course, doesn't exist. Changing the value to 0 or an existing project id makes the problem magically go away.



2008-10-27 06:46

reporter   ~0019693

I investigated this error and found that
in manage_config_columns_set.php line 63 should change from

if ( $f_update_columns_as_my_default ) {
if ( $f_update_columns_as_my_default || $f_update_columns_as_global_default) {

This seems to fix it.

I don't think there is a relationship between configuration installation variables or DB entries and this issue.

2008-10-28 16:58


5744.patch (488 bytes)   
Index: manage_config_columns_set.php
--- manage_config_columns_set.php	(revision 5744)
+++ manage_config_columns_set.php	(working copy)
@@ -60,7 +60,7 @@
 		access_ensure_project_level( VIEWER, $f_project_id );
-	if ( $f_update_columns_as_my_default ) {
+	if ( $f_update_columns_as_my_default || $f_update_columns_as_global_default ) {
 		$t_project_id = ALL_PROJECTS;
 	} else {
 		$t_project_id = $f_project_id;
5744.patch (488 bytes)   


2008-11-07 20:12

reporter   ~0019811

My work-around is to update columns the way I want in another project (I have a test project for playing and things like this), then use "Copy Columns To" to copy to All Projects, then delete the entry for the test project on the "Configuration Report" screen. This way everything is done through the GUI (no touching source code, or manually doing anything to the database).



2008-11-15 18:31

reporter   ~0019908

adding a working patch in the main repository is always better than a known workaround



2008-11-30 15:34

reporter   ~0020164

This is still an issue - i'm just trying to work out from UI + code whether there's a 4th case:

i.e. I think at the moment we have:

a) user sets settings for themselves for 1 project
b) user sets setting for themselves for all projects
c) admin sets setting for all projects

Point 1: Case C is currently broken
Point 2: isn't there a case D - i.e. 'admin sets a setting for 1 project'




2008-11-30 17:31

reporter   ~0020171

@grangeway: I'm not sure what your question is. Yes, admin can set settings for one project; that's part of my work-around in note 19811, and it works.

Which is supposed to take precedence, user's setting for all projects, or admin's setting for specific project?



2008-12-05 04:22

reporter   ~0020246

Last edited: 2008-12-05 04:30

there are indeed 4 cases as you wrote:
a) user sets settings for themselves for 1 project
b) user sets setting for themselves for all projects
c) admin sets default setting for all projects
d) admin sets default setting for 1 project

I had a problem with case c. It was broken and the patch I posted earlier fixed it.
But it only made it work as expected for case c though and doesn't distinguish case d from c.

Looking at the code in manage_columns_inc.php I also see that case d is missing.

There should be an additional submit button name (in another "if" statement) to show the correct text on the Submit button for case d in manage_columns_inc.php and some code in manage_config_columns_set.php to handle it with elegance.



2008-12-05 04:29

reporter   ~0020247

I believe that the precedence should be:

users settings for 1 project
user settings for all projects
admin default settings for 1 project
admin default settings for all projects

That's the meaning of having a default setting and letting your users play with it.
If you don't want your users to use their own view there are parameters to block their privilege to do so.



2008-12-07 01:45

reporter   ~0020284


I'm not sure I agree about precedence. Think about it this way. There is All Projects settings, and a project specific setting. Each one has a global default set by admin, and a user can customize them. So the system looks for project specific setting first, by the user or the admin, then for All Projects one. Makes sense to me. Also, if admin made a setting for one project different than the rest, there is probably a reason why. Maybe there is an important custom field that makes sense to display, or some of the default fields don't apply. Why should a user that customized his All Projects setting lose these project customizations by the admin?

The best solution is probably to give each user a choice. Maybe when All Projects is selected, there should be a checkbox for "Override global per-project settings with this one".

I also think it's important to show which of the four possible settings is currently being used.



2010-07-29 04:19

reporter   ~0026161


Your patch breaks my functionality. I (as an admin) would like to be able to set the columns at project level for all users. With your patch I only will be able to set the DEFAULT for ALL PROJECTS.

What i need is a save button, to save the settings at projectlevel for all users. I dont wont to update the settings for all projects, because my projects may have unique columns.

I just want to save actual settings, so why is there no save button??



2010-07-29 05:01

reporter   ~0026162

Maybee you should change line 209ff as follows, so the administator is able to change the columns for all users for a specific project:

<?php if ( $t_manage_page && current_user_is_administrator() ) { ?>

            &lt;?php if($t_project_id == ALL_PROJECTS)  { ?>
            &lt;input &lt;?php echo helper_get_tab_index() ?> type=&quot;submit&quot; class=&quot;button&quot; name=&quot;update_columns_as_global_default&quot; value=&quot;&lt;?php echo lang_get( 'update_columns_as_global_default' ) ?>&quot; />
            &lt;?php } else { ?>
            &lt;input &lt;?php echo helper_get_tab_index() ?> type=&quot;submit&quot; class=&quot;button&quot; name=&quot;update_columns_for_current_project&quot; value=&quot;&lt;?php echo lang_get( 'update_columns_for_current_project' ) ?>: &lt;?php echo project_ยป
            &lt;?php } ?>

<?php } ?>

Issue History

Date Modified Username Field Change
2008-08-04 11:32 northstar New Issue
2008-08-07 10:02 mkornatzki Note Added: 0019077
2008-08-10 01:38 vboctor Status new => acknowledged
2008-08-10 01:39 vboctor Category bugtracker => customization
2008-08-27 02:28 dominik Note Added: 0019253
2008-09-04 19:30 kpjava Note Added: 0019307
2008-10-27 06:46 karotos Note Added: 0019693
2008-10-28 16:58 karotos File Added: 5744.patch
2008-10-28 16:58 karotos Tag Attached: patch
2008-11-07 20:12 olegos Note Added: 0019811
2008-11-15 18:31 karotos Note Added: 0019908
2008-11-30 15:21 grangeway Status acknowledged => assigned
2008-11-30 15:21 grangeway Assigned To => grangeway
2008-11-30 15:34 grangeway Note Added: 0020164
2008-11-30 17:31 olegos Note Added: 0020171
2008-12-05 04:22 karotos Note Added: 0020246
2008-12-05 04:29 karotos Note Added: 0020247
2008-12-05 04:30 karotos Note Edited: 0020246
2008-12-07 01:45 olegos Note Added: 0020284
2010-07-29 04:19 flemminn Note Added: 0026161
2010-07-29 05:01 flemminn Note Added: 0026162
2014-11-07 16:32 atrol Assigned To grangeway =>
2014-11-07 16:32 atrol Status assigned => acknowledged