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 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:
... 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 /etc/httpd/conf.d/mantis.conf. Regarding your current problem: httpd server logs would perhaps indicate what went wrong.
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
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