Ok, so a follow-up on this: as I said earlier, users who had selected "For any event on the selected projects only…" get updated to "Only for things I watch or I'm involved in", which isn't a desired state. The hotfix for people who have been bitten by this: open a console (run @RAILS_ENV=production script/console@ in your redmine directory) and execute the following command:

<pre><code class="ruby">User.find_all_by_mail_notification('only_my_events').select {|u| !u.notified_projects_ids.empty?}.each {|u| u.mail_notification = 'selected'; u.save!}</code></pre>

2 things: this will only work for people whose account hasn't been "written to" since the faulty migration, this won't work for users who have been to their account page and changed something, be it the mail notification options or their name or whatever. The hotfix only works because of a dangling "data inconsistency" left over by the faulty migration and corrects that, users who have changed their account in some way have overwritten this. The second thing is: I take _no responsibility_ whatsoever in what happens with your data with the above line, it worked well on my test and production rig, if it blows your DB, well, you should replay this backup you made beforehand.

So much for the hotfix, I have a probable fix for the migration, which I have to test a little bit more before posting it here.

(oh, and if you want a list of affected users, this should give you the list of mail addresses of those users, same conditions as above apply:

<pre><code class="ruby">User.find_all_by_mail_notification('only_my_events').select {|u| !u.notified_projects_ids.empty?}.collect(&:mail)</code></pre>

Replace the @mail@ in the @collect(&:mail)@ at the end with another attribute to get a list of this attribute of the affect users.)
--------------------------------------------------------------------------------
Ok, here's the commit to fix the migration: http://github.com/thegcat/redmine/commit/811bc0863015c2d2ed87f71edaec95560ada9318

Here's the diff of the proposed change, comments after that:

<pre><code class="ruby">diff --git a/db/migrate/20100129193813_update_mail_notification_values.rb b/db/migrate/20100129193813_update_mail_notification_values.rb
index bfe0a59..4b49d87 100644
--- a/db/migrate/20100129193813_update_mail_notification_values.rb
+++ b/db/migrate/20100129193813_update_mail_notification_values.rb
@@ -1,8 +1,12 @@
# Patch the data from a boolean change.
class UpdateMailNotificationValues < ActiveRecord::Migration
def self.up
- User.update_all("mail_notification = 'all'", "mail_notification = '1'")
- User.update_all("mail_notification = 'only_my_events'", "mail_notification = '0'")
+ User.record_timestamps = false
+ User.all.each do |u|
+ u.mail_notification = (u.mail_notification =~ /\A(1|t)\z/ ? 'all' : (u.notified_projects_ids.empty? ? 'only_my_events' : 'selected'))
+ u.save!
+ end
+ User.record_timestamps = true
end

def self.down</code></pre>

I didn't find any "nice" way to get this done all through @User.update_all@, so I went the programmatic way. The timestamps are disabled for the duration of the change so that all users don't their @updated_on@ bumped up needlessly to the time the migration is applied. This migration also takes into account that some databases migrate a @true@ boolean field to @t@ and not to @1@ when the field is changed to a @varchar@.

Eric: Want me to merge that with the other patch from #6541, or will you take care of it?
--------------------------------------------------------------------------------
"ChrisMcKee wrote on github":http://github.com/thegcat/redmine/commit/811bc0863015c2d2ed87f71edaec95560ada9318#commitcomment-161195:

> Oddly this didnt fix my Trunk SVN Redmine site

Chris, this doesn't fix already migrated sites, i.e. if you already applied the migration when there were the @User.update_all@ blurbs in there, it won't fix anything, the patch I submitted to github only prevents this error from happening for people who will run the migration later on.

I suspect you had already run the faulty migration, please see my "first comment":/issues/6549#note-1 on this page for a way to correct this.
--------------------------------------------------------------------------------
What modifications this making to the users table (wondering as the first script wont run in WinServer2k3)
Would I be better off restoring the user preferences table from pre-upgrade?
--------------------------------------------------------------------------------
I should add I'm using MySQL and mail notification is being set to 1 for groups while users obviously still have their own settings only_my_events.
Not so much fun in a top500 company when your VP starts to get updates on web tasks :|
--------------------------------------------------------------------------------
Chris McKee wrote:
> Not so much fun in a top500 company when your VP starts to get updates on web tasks :|

Well, maybe you shouldn't run trunk then ;-) Repeat after me: trunk is not stable, trunk is not stable, trunk…

Anyway, the line in comment 1 updates the settings correctly, but doesn't solve the problem which causes mails to be sent to every project member rather than just to those who requested it, see #6541 for more info and a patch for that.
--------------------------------------------------------------------------------
Felix Schäfer wrote:
> Well, maybe you shouldn't run trunk then ;-) Repeat after me: trunk is not stable, trunk is not stable, trunk…

To be fair id only updated to the 1.0.2 tag; the errors even in the Bitnami release + tag
--------------------------------------------------------------------------------
Chris McKee wrote:
> Felix Schäfer wrote:
> > Well, maybe you shouldn't run trunk then ;-) Repeat after me: trunk is not stable, trunk is not stable, trunk…
>
> To be fair id only updated to the 1.0.2 tag; the errors even in the Bitnami release + tag

Then you shouldn't have this migration in yet at all, this is staged for 1.1 at the earliest…
--------------------------------------------------------------------------------
Curse of automation, I think our trunk server ended up updating the main servers email settings so the database migration took place for dev into live. What a difference an xcopy makes.
Ah well even with mass mailing its still more usable than Sharepoint.
--------------------------------------------------------------------------------
Adding this to a clean 'trunk' and manually rolling back the user table and running #6541 in script/console seems to have fixed it :o)
--------------------------------------------------------------------------------
Fixed in r4246 with a modified version of Felix's patch.

--------------------------------------------------------------------------------
I just updated to my svn instalation from svn trunk (Revision: 4425 and read the above comments about using trunk) and found a funny thing:

My database didn't migrate the mail_notification from bool to string but @db/migrate/20100129193402_change_users_mail_notification_to_string.rb@ was there and looked good.

Made the migrations manually and the it worked.

Is there any reason while a migration didn't get executed? Can i look somehwere what went wrong? Nothing n log/production.log though.
--------------------------------------------------------------------------------

relates,Closed,6541,Email notifications send to everybody