Bug 161656 - mantis error handling almost completely broken
mantis error handling almost completely broken
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mantis (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gianluca Sforna
Fedora Extras Quality Assurance
https://www.isdn4linux.de/mantis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-24 19:16 EDT by Fritz Elfert
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-09 05:14:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fritz Elfert 2005-06-24 19:16:47 EDT
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 whatever@foo.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):
mantis-0.18.3-2

How reproducible:
Always

Steps to Reproduce:
1. Try signing up as new user with an invalid or already existing username (just _one_ example).
2.
3.
  

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.

Additional info:
Comment 1 Fritz Elfert 2005-06-24 19:24:17 EDT
... referring to the 'above url' which actually is shown below in the
"Additional Bug Information".
Comment 2 Enrico Scholz 2005-06-25 11:07:07 EDT
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.
Comment 3 Fritz Elfert 2005-06-27 06:13:11 EDT
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. 
Comment 4 Enrico Scholz 2005-06-27 08:02:43 EDT
mantis provides such a migration functionality; you have to append '/admin' to
the mantis URL after removing/modifying access restrictions in
/etc/httpd/conf.d/mantis.conf.


Regarding your current problem: httpd server logs would perhaps indicate what
went wrong.
Comment 5 Fritz Elfert 2005-06-27 13:28:00 EDT
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
this package.

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
error messages.

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 ...
 - Fritz
Comment 6 Ville Skyttä 2006-10-10 13:48:58 EDT
Reassign to current maintainer.
Comment 7 Gianluca Sforna 2006-10-20 20:14:09 EDT
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.
Comment 8 Gianluca Sforna 2007-01-09 05:14:24 EST
FC4 will not receive further updates. 

Closing since the bug is not applicable on FC5 and newer

Note You need to log in before you can comment on or make changes to this bug.