Queued messages are not removed if account deleted

Hi, 

Can someone log a bug about queued messages not being removed if an account is deleted.

The queue should be searched for the email address of the account being deleted. If there are any messages queued in the email field that match the deleted used they should be removed.

It would also be nice if it was possible to remove any queued messages to be sent to members about the account that was deleted. For instance... if someone joins... edits their profile... they could trigger a large amount of matches... then if they deleted their account... all those queued emails are really garbage as they would now link to an invalid account. A search of the body field for the URL of the deleted member would take care of that...

Thanks

.

Messages are sent every 10 minutes by default, in most cases the letter will be sent anyway, before user is deleted.

Not if they join and have over 1k matches... then delete their account...that's a lot of spam mail to be sent....

Why do they have 1K matches; most of those should have already went out.?

why wouldn't they if they are from a popular location... and in my case... a female... No... sometimes they can create 5-10k matches... and would takes days to send...

Ok, I think it make sense if user is deleted as spammer:

http://www.boonex.com/trac/dolphin/ticket/3277

Regarding to many matches - try to tune matching to be more strict.

thanks, but I don't understand why only if they are deemed a "spammer"? If they "unregister" on their own there could still be hundreds of messages in the queue that are pointless as they reference a profile that has been deleted... It should be a standard function.. to removed any emails they have triggered and queued.

Finding user by email in message body is not guarantee to delete exactly this messages, it maybe that email address is mentioned somewhere else and then this message will deleted as well.

Also finding user by email can slow down regular deletions, since it will perform full table scan to find it.

Then it might be wise to add another table to the sys_sbs_queue table which holds the ID of the user who triggered the messages? 

Come on, I'm asking you to fix something. I understand it's not ideal for the current version, but don't push it off like this. It just makes you look lazy. You guys are developers, find the solution and evolve the usefulness of your product a little.

ok, but in such case this is structural change, so we can implement it in next major version, like 7.2:

http://www.boonex.com/trac/dolphin/ticket/3277

works for me, thanks!