Lost of entered data - APPLICATION ERROR #11

[dlite]

Hi all,

I just upgraded to mantis-1.1.2. Now I have the problem that if I didn't fill out all required fields I get the "APPLICATION ERROR #11" and when I press back in my browser (FF2, FF3, IE6, IE7) the entered content disappears. Is there a way to fix this?

--
Best regards

[mettaben]

I'm having this issue too. Is there a resolution?

[BAMaustin]

Has anyone found a workaround for this? I've had to re-create several bug reports where I didn't notice a REQUIRED field was not filled in. After the 3rd one vaporized after I'd just wasted 20 minutes writing a detailed report, I was hoppin' mad and had to take a break from the computer.

Typically I've missed REQUIRED fields because they are a pop-up menu items with a "(select)" for a default. So my eye passes right over it as already having data.

Seems like 'Submit'ting incomplete reports into Mantis ought to store it as a WIP record for some period (24hours to 7days). If it isn't completed in that window of opportunity, it gets discarded. Or maybe the 'Submit' button should pre-process the record. If any required field is not complete, Mantis should pop up a warning window and not complete the 'submit' process.

I'd actually like to see reports on how many reports were started and not completed... and by which users. Those may be the folks I need to chat with desperately. Maybe they're so frustrated that they can even figure out how to complete the problem description.

Brian

[bbach]

+1

[vzw614]

This is a known issue in v1.1.2

http://www.mantisbt.org/bugs/view.php?id=6736

[bbach]

Thanks. -- Bud

[esutton]

Is there a work around for this?

I just upgraded to 1.2.4 and users are complaining about the bug tracking system I selected being broken when they forget to enter required fields. Any tips are appreciated.

[atrol]

esutton, I am not able to reproduce this issue with version 1.2.4

[esutton]

Thank you for your reply.

Do you think it could be the result of recently upgrading from 1.1.8 to 1.2.4 ? I did a mysqldump, installed a new Bitnami updated LAMP 1.2-4 stack, then a new Mantis 1.2.4 Bitnami Module, then did a mysql restore with the dump.

I tried temporarily turning off the required attribute for the custom field and the problem went away. It came back when I made the custom field required again. Can you think of anything I can look at for clues?

-Ed

[atrol]

Are you able to reproduce the issue on my test environment?
Try entering an issue in project "A" where I set also a custom field required
http://62.75.242.233/mantisbt-1.2.4

[esutton]

The error originates here. The application error dump confounds users. The actual error message telling the user a necessary field was empty is not visible unless the user scrolls the browser to the far right.

APPLICATION ERROR #11
Full path: C:\Program Files\BitNami-WAMPStack\apps\mantis\htdocs\bug_update.php
Line: 148

# Produce an error if the field is required but wasn't posted
if ( !gpc_isset_custom_field( $t_id, $t_def['type'] ) &&
( $t_def['require_' . $t_custom_status_label] ||
$t_def['type'] == CUSTOM_FIELD_TYPE_ENUM ||
$t_def['type'] == CUSTOM_FIELD_TYPE_LIST ||
$t_def['type'] == CUSTOM_FIELD_TYPE_MULTILIST ||
$t_def['type'] == CUSTOM_FIELD_TYPE_RADIO ) ) {
error_parameters( lang_get_defaulted( custom_field_get_field( $t_id, 'name' ) ) );
trigger_error( ERROR_EMPTY_FIELD, ERROR );
}

Can I create a new project on your test site? I signed up for a new account on your test site. I will keep checking email.

-Ed

[atrol]

Did you change setting $g_display_errors ?
If so, remove your changes and try entering issues / using backspace

[esutton]

Never mind.

I imported the Mantis DB from Windows WAMP stack into a LAMP Mantis 1.2.4 and the application error #11 now works as expected (see screenshot ) and informs users of the error. Thanks you for your assistance, but I think I will just move it all to the Linux install and forget about trying to solve the issue on my WAMP installation.

Thank you for your assistance. My software manager really likes the new color coded schemes and improvements to 1.2.4. I much prefer Mantis to Bugzilla.

Thanks again,

-Ed

My unmodified config_defaults_inc.php set $g_display_errors:

/**
* --- error display ---
* what errors are displayed and how?
* The options for display are:
* 'halt' - stop and display traceback
* 'inline' - display 1 line error and continue
* 'none' - no error displayed
* A developer might set this in config_inc.php as:
* $g_display_errors = array(
* E_WARNING => 'halt',
* E_NOTICE => 'halt',
* E_USER_ERROR => 'halt',
* E_USER_WARNING => 'none',
* E_USER_NOTICE => 'none'
* );
* @global array $g_display_errors
*/
$g_display_errors = array(
E_WARNING => 'inline',
E_NOTICE => 'none',
E_USER_ERROR => 'halt',
E_USER_WARNING => 'inline',
E_USER_NOTICE => 'none'
);

[atrol]

I imported the Mantis DB from Windows WAMP stack into a LAMP Mantis 1.2.4 and the application error #11 now works as expected (see screenshot ) and informs users of the error. Thanks you for your assistance, but I think I will just move it all to the Linux install and forget about trying to solve the issue on my WAMP installation.

Seems that the Bitnami WAMP uses some PHP configuration which causes problems when setting the errorhandler for MantisBT.
I tried the complete Bitnami Mantis Stack on Windows which works fine.
If your software manager has no problems using LAMP I would continue using LAMP.

[esutton]

That could be it. The difference between the combined Bitnami Wamp+Mantis install and what I did which was Bitnami Wamp install, followed by Bitnami Mantis module install.

I think LAMP is the way to go. We already have a Jenkins build server running on it and Jenkins has a Mantis plugin which is functional.

http://jenkins-ci.org/

Thanks again,

-Ed