The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.If a user starts a thread the recipient doesn't get a notification message. Notifications are received for subsequent messages in the thread
In PrivateMessageNotifier the problem starts when checking to see if the recipient has been away long enough to receive the message.
$thread->getLastAccessTimestamp($recipient)
This calls getLastAccessTimestamp in PrivateMessageThread.php. However, if I log the account->id(), it returns the id of then owner/sender of the message. Not the recipient's user id.
public function getLastAccessTimestamp(AccountInterface $account) {
\Drupal::logger('PrivateMessageThreadTodd')->notice('In getLASTaccesstimestamp in Private Message Thread the account ID is ' . $account->id() );
$last_access = $this->getLastAccessTime($account);
return $last_access ? $last_access->entity->get('access_time')->value : FALSE;
}The result is a timestamp that equals the creation timestamp, since they're equal, no notification is sent. To handle this, I've added another if statement just below the $away_time check in the shouldSend function, but I'm sure there's a better way to handle this.
if ($message->getCreatedTime() == $thread->getLastAccessTimestamp($recipient)) {
$notify = TRUE;
}| Comment | File | Size | Author |
|---|---|---|---|
| #5 | private_message_notification_on_new_thread_3043898.patch | 874 bytes | cqbent |
Issue fork private_message-3043898
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
bryantt commentedComment #3
bryantt commentedComment #4
bryantt commentedComment #5
cqbent commentedThanks bryantt for coming up with a workaround - this issue has plagued me for a while now. This issue occurs for users who have their send notifications set to "Only when not viewing the thread". Turns out this is not actually an issue with getLastAccessTimestamp function. It has to do with how threads get created. When a new thread is created the module adds the author and the recipient(s) as members to the thread and sets their last access time to the same timestamp the thread was created - even though the recipients have not actually accessed the thread yet. So when the module calls the getLastTimestamp function its actually calling it for the author and recipients and is getting the same exact timestamp as the thread creation timestamp. The fix that bryantt created gets around this issue by checking for an exact match between the creation time and the get last accessed time - since they would only be an exact match if it was a new thread (That's what I hope at least). I've added this fix as a patch with some comments. Hopefully it's useful to somebody else. It would be great if a more permanent fix could be incorporated into the module.
Comment #6
sagesolutions commentedI've tested out the patch and the first notification is now sent. Woohoo!
However, I agree that the patch isn't ideal. I think there could be an instance where in a custom module a thread is saved and at a later time the first message is saved, which means the notification would not be sent.
Possibly a better approach would be to keep track of the first message id in the thread, or number of messages in the thread. Then you can notify if the message is the first message. Alternatively, you could notify if there is only one message in the thread.
Setting issue to needs work.
Comment #7
paulrad commentedComment #8
paulrad commentedComment #9
paulrad commentedI can confirm that the issue was resolved in the 3.0.x branch after the creation of the
pm_thread_historytable and refactoring of thegetLastAccessTimestampmethod and no longer exists.Comment #10
artem_sylchukThanks for checking that, marking as fixed