This chapter provides the Administrator with additional information related to Application Errors and common problems in MantisBT. Useful additional reference information and support may also be found on the MantisBT website, more specifically the Forums and the Bugtracker.

Additional information about MantisBT common errors.

This error occurs whenever MantisBT tries to access an issue having a Category which has been deleted from the database. It will most likely happen when the Category specified by $g_default_category_for_moves has been deleted, and an issue is subsequently moved to another project where its current category does not exist. There are two ways to resolve this issue: Recreate the missing category Find the missing Category's Id This can be done by checking the value of default_category_for_moves in config_inc.php and/or in Manage Configuration. Alternatively, the following SQL can be executed SELECT DISTINCT category_id FROM mantis_bug_table b LEFT OUTER JOIN mantis_category_table c ON category_id = c.id WHERE category_id <> 0 AND c.id IS NULL Recreate the missing Category The category's id must be manually set to reflect the value retrieved above (e.g. using SQL or your favorite DB admin tool) Assign a new category to the issues referencing the missing one Identify the corrupted issues and corresponding missing categories SELECT b.id, category_id FROM mantis_bug_table b LEFT OUTER JOIN mantis_category_table c ON category_id = c.id WHERE category_id <> 0 AND c.id IS NULL Determine which Category id to use instead of the deleted one Update the issues This can either be done manually using your favorite DB admin tool or with SQL, e.g. UPDATE mantis_bug_table SET category_id = (NewCategoryId) WHERE category_id = (OldCategoryId) Finally, to avoid future occurences, you need to set $g_default_category_for_moves to a valid Category Id. This must be done as appropriate, either globally in config_inc.php, or via the Manage Configuration page, for all occurences of the parameter. Note: to retrieve a category's ID, you can either Look up the value directly in the database: mantis_category_table, column 'id' Go to Manage Projects, click the Edit button for the desired category and look for the the value next to 'id=' in the page's URL

This error may only occur when Form Validation is enabled with $g_form_security_validation = ON. There are several known cases that could trigger it: Multiple submissions of a form by clicking on the submit button several times (user error) Invalid or unauthorized submission of a form, e.g. by hand-crafting the URL (CSRF attack) Expired PHP session In the first two instances, MantisBT's behavior is by design, and the response as expected. For expired sessions however, the user is impacted by system behavior, which could not only cause confusion, but also potential loss of submitted form data. What happens is driven by several php.ini configuration settings: The ratio session.gc_probability divided by session.gc_divisor, which determines the probability that the garbage collection process will start when a session is initialized. session.gc_maxlifetime which specifies (as the name does not indicate) the minimum validity of session data. With PHP default values, sessions created more than 1440 seconds (24 minutes) ago have a 1% chance to be invalidated each time a new session is initialized. This explains the seemingly random occurence of this error. Unfortunately, this problem cannot be fixed without a major rework of the way sessions and form security are handled in MantisBT. As a workaround, the Administrator can Increase the value of session.gc_maxlifetime Set $g_form_security_validation = OFF. Note that for security reasons, it is strongly recommended not to do this. Users may also install local tools to avoid loss of form data, e.g. Lazarus Form Recovery add-on for Firefox. Further references and reading: MantisBT issues 12381, 12492, 13106, 13246