Most forums have an option to confirm that a PM is read by the recipient... that would really complete this lovely module!

#5 att1.jpg11.57 KBSophia
#5 att2.jpg11.94 KBSophia
#5 att3.jpg21.03 KBSophia


litwol’s picture

Status: Active » Postponed

definitely post 1.0 feature.

Berdir’s picture

This is the same as #340175: no info/flag if sent message was read or no, right?

The problem is what we should do with multiple recipients. Should it display "read" if all recipients have read the message, or only one of them ? Or even display it for every recipient...

Sophia’s picture

Oops... I didn't realize it was already suggested
/me must learn to read properly :D

Anyway, I know that phpBB flags the message as "Read" when only one participant has read it... which is not really what I would prefer but it is how they do it.
On the other hand, Invision boards offer the "Message Tracker" as a separate screen, which shows a list of which message was read by whom and when.

Welcome to your messenger
Read Messages
The messages shown here have been read by the person they were sent to.
Message Title - Message For - Date Read

I'd say the second method is better all around.

litwol’s picture

also if we offer such feature, i think we /must/ give users option to disable the feature and not tell anyone if they read it or not. performance-wise it is better to use the 2nd approach on the 2nd screen.

Sophia’s picture

21.03 KB
11.94 KB
11.57 KB

If you need some inspiration for the future, see attached screenshots of how it works on Invision boards:

1) Shows the option when sending a message to track it or not
2) The menu that shows PM tracking as a separate screen
3) The screen where messages are tracked. The PM is only added there after it's been read.

Also, FYI, neither phpBB nor Invision offers the option where you can disable other people tracking their PM's to you... so don't worry too much about that ;)

jacr’s picture

Why not using the Participants Message on top of the Message.
Participants: user1 (unread) and user2 and user3 (unread)...

igorik’s picture


Is there any progress with this issue?
probably it will be not finished to 1.0. version, but I appreciate some info if this is real big hard issue or just it has not so big priority as other issues.

Because, it is really good and handy thing to know if your message was read or not yet.


nbz’s picture

There has been no progress and from what I can see, no interest in progressing it (yet?) either.

igorik’s picture

I am really interesting in this issue. Maybe a lot of people resign that so useful and basic thing is missing from the beginning (it was in D5), maybe not, however, if it will be someday added into privatemsg, it will be great.
I am 100% sure that I am not the only one who think that it is really useful and good feature and it is good to have it.


Fogg’s picture

subscribe +!

Bilmar’s picture

subscribing - Sounds like a cool new feature. I can definitely find uses for it that would benefit users. It would be most useful if the sender can see which recipients have read the message (when sent to multiple). If there was to be development here I will be available to help with testing. Regards

igorik’s picture

maybe it could be hooked with rules, and after the message was read, admin can create some rule

YK85’s picture


BenK’s picture

Title: "Message read" feature » Message read notification (read receipt)
Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Postponed » Active

Subscribing to start thinking about this.... Chatted briefly with Berdir in IRC about this and marking it active again. Since we've been doing a lot of new features in D7 branch and then backporting to D6, I'm changing the version, too.


BenK’s picture

Priority: Minor » Normal
BenK’s picture

Hey Berdir,

After our chat in IRC, I put more thought into this. I think the key is to keep things simple while also allowing for multiple messages per thread and multiple recipients. So here's what I'm thinking:

A. Create three permissions: "View who read this," "Track who read this," and "Allow user to disable tracking". The "View who read this" permission would allow users to see who has read a specific message in a thread. The "Track who read this" permission would be used to only report read data for roles who have this permission selected. Finally, the ""Allow user to disable tracking" permission would be used to allow certain users the ability to disable the tracking on their own at the user/edit page (similar to the option to disable Private Message altogether).

B. Create a link on each and every message within a thread called "Who read this". This would appear in the links section of each message next to "Delete message" and "Block author". Clicking this link would open up an overlay that lists in table format each user who has read the message. (For D6, this could just open up a new page with the same table on it.) For messages with large numbers of recipients (like messages sent to a role), a pager would be used to limit the number of messages that appear on the screen at any one time. I'm not sure if we have any data available that could be used to sort these users... otherwise, we could just display them alphabetically and allow clicking the column header to reverse the sort order.

C. Add a new column at /messages called "Last Message Read". If the last message in a thread has been read by at least one recipient, display "Yes" (otherwise "No"). And if it has been read by more than one recipient (let's say, three), then display the number who have read the message in parenthesis like this: "Yes (3)". The "Yes (3)" would be a link to an overlay popup that shows all of the users who read the last message in the thread (the same table as if you clicked the "Who read this" link on the last message in the thread). If we wanted to get really fancy, "Yes" and "No" could appear on top of icons that shows a message being open or being closed.

What do you think? I tried to keep things simple and the UI integrated into what we already have.


artscoop’s picture

It is indeed a needed feature.
I have some users complaining about not being able to know if they were read.
And they want to unregister because of this.

Lasac’s picture

i to would like to see this feature in what ever way.

mirujune84’s picture

add this to your header in mail :

$headers['Disposition-Notification-To'] = $from;
$headers['X-Confirm-Reading-To'] = $from;

Lasac’s picture

mirujune84: could you explain a bit further, what does your suggestion exactly do?

Berdir’s picture

That is about e-mails, it has nothing to do with privatemsg.

mirujune84’s picture

This is for "read receipt" notification. getting ?

Lasac’s picture

mirujune84: but we are looking for a way how to do this for the privatemsg_module and not for e-mails. getting?

scarvajal’s picture


BeaPower’s picture


soelver’s picture


This feature is something that moderators on our site really would like to have. When sending messages to users, they prefer to see, if the message have been read (and if the user is ignoring them, or if it simply haven't been read yet).

Would it be possible to have this function for messages with only 2 people in it?
I understand the problem when more people are involved, but if it could be solved when only 2 users are writing to each other, it would be really nice if they could see whether the message was read or not.

Thank you for a wonderful module :)

fizzbin’s picture

I'd also like to see this backported for 6.x.
The ability for a team leader in a workflow-type setting to see who isn't reading their PMs seems invaluable. Hey, even AOL mail back in the stone age had read notification!

While I don't know precisely how this module actually works internally, I think this query on the backend (MySQL) would provide the basis of the requested functionality, just simply show who hasn't read their PMs yet (minus notes to self - see the last line):

SELECT, pm_message.subject
FROM pm_index 
LEFT JOIN pm_message
ON pm_index.mid = pm_message.mid
LEFT JOIN users 
ON pm_index.recipient = users.uid
WHERE pm_index.is_new = 1 
AND = $uid 
AND pm_index.recipient != $uid;

That's all people are asking for I think, at the bare minimum.

It would also be nice to have the recipient name also a link to the user profile, if the sender doesn't know who corresponds to the username. Could one of the Privatemsg devs tag in on this? While I have a github account, I'm just getting started on modules and feel I'll do this relatively easy feature a grave disservice - but I'm happy to help out any way I can. Also, while Rules integration was mentioned by #12, I don't think it's necessary, it's just more likely to add code bloat and complexity. This thread started back in 2009 with no real traction, so let's just keep it simple.

In the future, if we could somehow have a View happening (e.g., similar to og_unread for Organic Groups notifications), that would totally rock.

fizzbin’s picture

Can someone (Berdir?) walk me through a pull request on github?

I have a really basic working version of this for 6.x-2.x. I implemented hook_perm() so this can be shut off for certain roles. It just grabs the result of the query I posted in #27 and sticks results in a table on a node.

I know there are just a few changes required for the 7.x version of the database API and perhaps a few hooks, and since this if my first contrib, I haven't even looked at D7 API. Perhaps someone with a bit more Kung Fu can make the results sortable and/or paged. If someone can clean up the mess I made, it'll be a good learning experience.

One big caveat I couldn't get around: database abstraction.
$nummsgs = $result->num_rows;
I don't think num_rows is safe with anything but mysqli.

example output:

Unread PMs
Unread private messages you have sent:
Recipient Subject Date
test Does this work? 2012-05-31 14:59:59

OR (no unread messages)

Unread PMs
All of your sent messages have been read.

fizzbin’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Status: Active » Needs work

Switching the issue version back to 6.x until I can wrap my head around 7.x APIs.

I'm wondering how far BenK got with #16.

Berdir, I found your github and blog, and I'll be in touch.

Thanks for writing a quality module.

Berdir’s picture

There is no need to involve github. I usually just use that for personal feature branches of my modules.

The correct way to submit changes is using patches and uploading them here.


Basically, you will need to clone the privatemsg git repository (here on d.o, see instructions on the project page tab, *not* github), copy your module in there and then git add the files and finally git diff > some_name.patch. Detailed instructions in the link above.

Alternatively, if you don't need to do any changes in Privatemsg's files, you could also create your own project that depends on Privatemsg. You can create your own sandbox project, see

fizzbin’s picture

Thanks Berdir for the advice!

I'll probably just sandbox this, since the latter situation applies. Also, I'd like someone else to look at the code I wrote before it's promoted to production, since some of the things I had to do to get this working seemed rickety to me. Feel free to take a look at my github repo, and any criticism from more experienced members of the community is most welcome.

Berdir’s picture

I added a bunch of comments here:

What I think would be useful would be a link on each message that links to a page where you only list people who haven't read that specific message. You can add such a message using one of our hooks, see for an example.

fizzbin’s picture

Thanks for the github feedback, cheers, very helpful!

Hellsyl’s picture

There is a version of this module for D7 ?

ptmkenny’s picture

@Hellsyl No, there's no version of this patch for D7. You're welcome to port it to D7 though. :)

Hellsyl’s picture

I'm unfurnatly not a php programmer. I'm trying but its not working for now.

oadaeh’s picture

Issue summary: View changes
Status: Needs work » Closed (won't fix)

This issue is being closed because it is against a branch for a version of Drupal that is no longer supported.
If you feel that this issue is still valid, feel free to re-open and update it (and any possible patch) to work with the 7.x-1.x branch (bug fixes only) or the 7.x-2.x branch.
Thank you.