I just ran into the same problem on our 1.2.0rc2 installed version today

I think this one should have set "Target Version" to 1.2.x because standard functionality which was working in 1.1.x is broken.

Isn't it the core/email_api.php problem in the
function email_send_confirm_hash_url( $p_user_id, $p_confirm_hash )

line (#472 if I'm not wrong):
lang_push( user_pref_get_language( $p_user_id ) );

which doesn't work (maybe with certain languages, I'm not sure).

If so, try to comment this line (this works for me).

"Target Version" to 1.2.0 IMHO indeed.

Can confirm that commenting line #472 of core/email_api.php with lang_push( user_pref_get_language( $p_user_id ) ); solves the problem for now.

Thanks for the bug report, and finding which line caused the issue. I should have fixed it now (in both 1.2.x and 1.3.x branches). I suspect this problem arises when a user language preference is incorrect or invalid in some way. Now it should fall back to the default language of the MantisBT installation when the user language preference is not correct.

Please test this for me (as I couldn't reproduce the original issue) and reopen if the problem still remains. Thanks!

still not working
watergad wrote that he changed email_api.php
but email_api.php is not in the changeset
@dhx did you forget it, or was this only a workaround for the bugs you fixed in lang_api.php and user_pref_api.php ?

Try adding these two lines to the bottom of config_inc.php to see if it makes a difference:

$g_send_reset_password = ON;
$g_enable_email_notifications = ON;

Also, password reset emails aren't sent for protected accounts.

This is a fresh test installation without any special configuration in config_inc.php

Content of config_inc.php:

$g_hostname = 'XXXXX';
$g_db_type = 'mysql';
$g_database_name = 'XXXXXX';
$g_db_username = 'XXXXXX';
$g_db_password = 'XXXXXX';

Am I right, that the values in config_defaults_inc.php are taken if there is no other configuration?
If yes, they are set as you requested.

I think this was a typo, I didn't find in source:
$g_enable_email_notifications should be
$g_enable_email_notification

My test users are not protected

Further hint:
After requesting the new password and getting no mail I logged in with the old password which still works.
Sometimes I get the following message, but can go on working without further problems.
APPLICATION ERROR #2800
Invalid form security token. Did you submit the form twice by accident?

If you want you can try my test installation to verify the behaviour (This is the latest nightly build from today, which contains your latest commits in GIT)
http://www.atrol.de/mantisbt-1.2.0rc2-2010-02-08

I think the patch from 0010780 may fix this issue? We forgot to backport it to the 1.2.x branch which may explain why I couldn't reproduce this problem (I use the 1.3.x branch typically).

Please checkout the latest 1.2.x master branch from git.mantisbt.org and see if things are working again. I can confirm that with my setup, the lost password functionality is working fine on the latest version of 1.2.x.

I noticed this patch yesterday and tried already. But behaviour didn't change.
To be complere sure I will setup a fresh installation with the next nighly build of 1.2. First I will setup a 1.3 to find out whether we are looking for something which has to be backported or a still not fixed problem

Also not working with 1.3dev (where I had to tweak the new encryption code to get it run, but this is another story ...)

Have a look at 0011493
maybe this is related

Same here. Just downloaded 1.2.x master from 13-2-2010 and the error is still there. When disabling

lang_push( user_pref_get_language( $p_user_id ) );

oin line 494 of core/email_api.php then all works fine. Also, the user I've tried that with has a proper language configured, so the note from the latest changeset doesn't apply here. The problem must be something else.

Can someone please try reproducing this problem with the following error verbosity settings in config_inc.php:

   $g_show_detailed_errors = ON;

$g_display_errors = array(E_WARNING => 'halt',

E_NOTICE => 'halt',

E_USER_ERROR => 'halt',

E_USER_WARNING => 'halt',

E_USER_NOTICE => 'halt',

E_ALL => 'halt');

This should hopefully provide more information on any errors that may be occurring.

Thanks

I've tried it and what's strange: when using those settings and uncommenting lang_push( user_pref_get_language( $p_user_id ) ); in email_api.php, again no email is sent out :-( and no error message produced.

Cross tests performed:

When creating an error elsewhere, I get a very detailed error message, so that part works.

Commenting the line in email_api.php again, emails get sent out.

So, something in either user_pref_get_language() or in lang_push() must happen that avoids sending email but doesn't throw an error.

I still had this problem after using the changeset below, but I have now fixed it with a small change.

In user_pref_api.php, in the user_pref_get() function, there is a line (around line 480):

if ( auth_get_current_user_id() == $p_user_id ) {

I have changed this to:

if ( auth_is_user_authenticated() && auth_get_current_user_id() == $p_user_id ) {

The problem seems to be that if there is no logged in user (and there won't be for a password reset from the login screen), the auth_get_current_user_id() function will throw you back to the login screen immediately. Checking whether the user is actually logged in gets round this.

Thanks DominionSpy, your changes are correct and I've applied them to the repository. Apologies with the delay in getting this fixed.

If anyone still experiences problems with the latest git checkout of the 1.2.x or 1.3.x branches, please reopen this issue again.

Thanks