Red Hat Bugzilla – Bug 161656
mantis error handling almost completely broken
Last modified: 2007-11-30 17:11:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Description of problem:
Due to the fact that FC4 ships with PHP5 and the shipped version of mantis is a pretty old version (which is _not_ php5 aware). The error-handling is completely broke. I tried to fix it manually so i now get at least _some_ error messages but at the above url you cat try to sign up using email@example.com as username and a valid email adress and simply get the welcome page again. In the original, you get an invalid username error (the @ is not allowed). On an unmodified installation, (_not_ on the above url!) you can try signing up with an already existing username and get the same result without any error message at all which is pretty confusing.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try signing up as new user with an invalid or already existing username (just _one_ example).
Actual Results: Either no error message at all or (depending of the current context) a numeric error code like "APPLICATION ERROR #12"
Expected Results: The numeric error codes normally get translated in to a much more elaborated description. There should be error messages in various situations.
... referring to the 'above url' which actually is shown below in the
"Additional Bug Information".
Oh... I somehow missed to request a build for 0.19.2. Should be done now
(together with 1.0.0a3 in devel branch) so you can expect updated packages soon.
It's getting worse:
Tonight with the nightly yum update the new version 0.19.2-2.fc4 was
installed. Now, nobody is able to login anymore :-( No error messages, just
the login page appears again and again.
Did the db-schemata change with that version? If yes, one should provide and
execute some migration script in the postinstall scriptlet of the rpm.
mantis provides such a migration functionality; you have to append '/admin' to
the mantis URL after removing/modifying access restrictions in
Regarding your current problem: httpd server logs would perhaps indicate what
Yes i know, and i was able to fix it this way. But updating in an unattended
fashion like when having nightly yum updates enabled doesn't work if the rpm
postinstall doesn't resemble this. Until that is solved, you probably should put
a big fat warning about auto-updating into some README.Fedora or better into the
initial welcome page so that an admin gets aware of it when first installing
BTW: the error logs didn't show anything and: IMHO, the error handling still is
broken. If you take a look at core/print_api.php in function
print_mantis_error(), the global array MANTIS_ERROR is referenced there. But
this array isn't global. It is read in core/lang_api.php within the function
context of lang_load(). After reading, it's content is transfered into the
global array g_lang_strings. This results in print_mantis_error() printing empty
Now, after the manual upgrade from within the mantis admin pages, i experience
other strange things. For example clicking the signup link does nothing but
redirecting back to the welcome page. This again seems to have to do with
referencing nonexistent global variables (in this case: g_allow_signup which is
set in config_defaults.php but doesn't seem to get recognized by the
config_get() function which is used initialy in signup_page.php to trigger that
redirect if signing up is not allowed.
I'm further investigating ...
Reassign to current maintainer.
Fritz, are you still running mantis and FC-4?
I just made a small security update to the package, but I doubt this will fix
your issue. Fact is, I am not leaning toward doing a mayor update to the 1.x.x
for the FC-4 branch, so I strongly suggest you update to a newer FC.
FC4 will not receive further updates.
Closing since the bug is not applicable on FC5 and newer