the address field in the messaging_destination table stores the email address of the user (at least for messages sent via email; it stores the uid for simple messages, and I haven't tested other sending protocols). the problem is that this field isn't updated when a user changes their email address.

I was going to create a patch to fix this somehow, but first I wanted to check if we should be storing the address here at all... we already store the uid in the 'uid' column, so couldn't we just grab the user's current email address when building a message?

Comments

jose reyero’s picture

jose reyero commented

This should be updated for mail, see messaging_user(op = 'update');

However we should 'generalize' this feature for all sending methods (sms, xmpp...)

This value is currently needed, for cases like anonymous users we don't have a user that has an email. So for practical purposes we store all mails in this table and we just need to query the same table always (for registered and anonymous).

Also for the future this will enable us for having a different mail for notifications than for the user account, or keeping track of messages sent to each address, so I wouldn't like to drop it even if it duplicates user mail column.

joshuajabbour’s picture

joshuajabbour commented
Status: Active » Closed (fixed)

ok, figured it out... it was actually a conflict with another module over here. no problem with messaging.module...

joshuajabbour’s picture

joshuajabbour commented
Project: Messaging » Notifications
Status: Closed (fixed) » Active

Ok, figured out why I was so confused. I actually submitted this original issue incorrectly. The messaging_destination table does update correctly (though there was a conflict with a custom module on the site I'm working on that caused it to fail occasionally-- but this wasn't a problem with messaging.module).

Where I originally noticed an address not being updated was the 'destination' column in the 'notifications' table. AFAICT, this field is a duplicate (as the address is stored in messaging_destination, and referenced by the mdid field. Is that correct? Should this field be dropped?

jose reyero’s picture

jose reyero commented
Title: messaging_destination 'address' not updated on user setting change » messaging_destination 'address' not updated on user setting change (yes for mail, not for other methods)
Category: bug » task

You're right about that field, it is a duplicate.

However I think we better keep it for some more time, as it is not used (shouldn't be) anymore after the subscriptions is created and on the other side it stores the address with which the subscription was first time created, which is helpful for destination/address related issues.

The update user account / update destinations may still have some issues with other methods than mail, still have to figure that out.

So let's update the issue's title and add to the 'to do' list.

joshuajabbour’s picture

joshuajabbour commented
Title: messaging_destination 'address' not updated on user setting change (yes for mail, not for other methods) » notifications table / destination field not updated on user setting change (yes for mail, not for other methods)
emilyf’s picture

emilyf commented

I am having this same problem with beta6 of notifications and messaging. It's not updating the email address if a user changes it. I apologize if this is the fault of another module, but it seems to me it's notifications or messaging that is the issue. I don't know what other module would be doing it.

I installed the admin tools when I was trying to figure out why I was not getting the notifications. It shows that it's trying to send messages to an 'admin@mysite.com' when in fact I have changed that user's email to something else. Here is the log output that is showing it's sending to the wrong user:

Process log
Type Message
Type Message
info Starting notifications process
info Processing queue
send interval= Immediately
info Starting queue processing
send interval= 0 max sqid= 15
info Queue processing
cron= 1 max_sqid= 15 send_interval= 0 send_time_after= 1279653504 mdid= 1 send_method= mail module= notifications_tags
info Processing queue rows
cron= 1 max_sqid= 15 send_interval= 0 send_time_after= 1279653504 mdid= 1 send_method= mail module= notifications_tags limit= 1
info Processing for sending
method= mail interval= 0 module= notifications events= 1
info Composed messages
number= 1 send_method= mail
info Sending out notifications
method= mail address= admin@mysite.com messages= 1
info Sending message.
message= Message: method= mail, destination= admin@mysite.com, subject= New : test

leenyx’s picture

leenyx commented

I have noticed the same issue with beta7. Also the same happens when changing the interval settings, there is no update on the database after the user updates the settings with the UI, even after a cron job.

liquidcms’s picture

liquidcms commented
Priority: Normal » Major

i agree there is a bug in notifications here.

when a user updates their profile page (email, send interval, send method, language) that user's entries in the notifications table should be updated accordingly

gease’s picture

gease
he/him
Primary language Russian
Location Praha
commented

Destination field doesn't get updated in notifications table and for messaging table it happens with some delay. I mean mail and 6.x-4.x version. And notifications are being sent to outdated address for some time.
messaging_user doesn't have implementation for 'update' operation, so I have no idea how this update is implemented, and it looks more of a bug than a feature.