Redmine

Same here. I just updated to 1.0.2 and suddently email notifications are sent to ALL users :/

Are you on 1.0.2 or latest trunk?

Sorry, I wasn't very specific.

I first upgraded to latest trunk (currently r4229) and got this problem, so I downgraded to r4210 (which corresponds to 1.0.2) but still have the same problem: email notifications are sent to all users.

I suspect migrations introduced in r4216 won't be easy to downgrade... Do users receive mail notifications they shouldn't be recipient of regarding projects privacy ? Or they just receive notification as if they chose it in "My account" page ?

Jean-Baptiste Barth wrote:

I suspect migrations introduced in r4216 won't be easy to downgrade... Do users receive mail notifications they shouldn't be recipient of regarding projects privacy ? Or they just receive notification as if they chose it in "My account" page ?

The notifications options are set to "receive all mails for all events", and this is because the second migration of r4216 isn't run due to the wrong timestamp. JB, didn't you open a ticket for that? Could you make it a related to this one here?

Regarding that migration, there is another problem with it: it assumes true and false are stored as 1 and 0 in the DB, which isn't the case for sqlite, which stores t and f. Will submit a patch soon.

Yes it's #6527. In fact they are run (at least on my laptop...) : with timestamped migrations, rails inserts a line for each migration in the internal table where it stores the migration (schema_something, I don't remember). Anyway, I'm not sure it will be easy to reverse after upgrading to a recent revision on trunk.

I let you investigate Felix (and thanks for the boolean thing, it makes me think of something on your doodle plugin I didn't report to you!)

Could everyone facing this problem please post here what DB they are using, if 20100129193402 and 20100129193813 are in in the table schema_migrations, and if the values for users.mail_notifications are either 0 and 1, t and f or some meaningful_strings. Thanks.

Jean-Baptiste Barth wrote:

Yes it's #6527. In fact they are run (at least on my laptop...) : with timestamped migrations, rails inserts a line for each migration in the internal table where it stores the migration (schema_something, I don't remember). Anyway, I'm not sure it will be easy to reverse after upgrading to a recent revision on trunk.

They are run here too, but the main problem is that the migration assumes the values from the boolean are 0 and 1, though at least on sqlite they are f and t.

I have both 20100129193402 and 20100129193813 in the schema_migrations table.
As for the users.mail_notification, two users have all, one has none and all others have only_my_events.

I confirm that Felix' github patch fixes the problem for me.

Anyone who made the update might want to have a look at http://www.redmine.org/issues/6549#note-1.

Felix Schäfer wrote:

Regarding that migration, there is another problem with it: it assumes true and false are stored as 1 and 0 in the DB, which isn't the case for sqlite, which stores t and f. Will submit a patch soon.

Regarding that, from a completely fresh (i.e. nothing else than a rake db:migrate) sqlite DB:

sqlite> SELECT mail_notification FROM users;
t

So I can't say for sure other other sqlites don't convert true in a boolean field to a 1 in a varchar(255) field, but that one doesn't :-)

we still got this problem in version 4231-devel after an update yesterday. we are using mysql.
what can I do to fix it?

christoph scheyk wrote:

we still got this problem in version 4231-devel after an update yesterday. we are using mysql.
what can I do to fix it?

The fix isn't in trunk yet. What I told Luc a few comments up should correct the problem too.

Thank you, Felix!

Does this relate to that I also see both the english and the swedish values in the select on the accountpage where they choose their setting for this?

Henrik Jönsson wrote:

Does this relate to that I also see both the english and the swedish values in the select on the accountpage where they choose their setting for this?

Probably not all strings are translated yet, which happens rather often on trunk.