Message threads, instant messenger, notifications and user blocking

Thanks for some great suggestions! At the moment my priority will be to strengthen and fix some of the existing features. I have a roadmap listing what I am working on next in the README file. I welcome any patches for these also :)

I believe this module will be a more solid foundation for private messaging with all the advantages of the message stack, views etc. as you say. So, at the moment, the feature rich choice for private messages is obviously privatemsg module.

I'm interested in discussing what you have raised to get any other ideas you may have...

Threaded communications with a possibility to answer to messages

This is on my to do list. I think comments is a fantastic idea I had not thought of. There are a few issues with this approach though.

• I will not use nodes and comments are node only in D7: #731724: Convert comment settings into a field to make them work with CMI and non-node entities
• How would we deal with comment "Reply" (To Sender) and "Reply All" (All users or Group if using Message Private OG)?

I was originally going to use an entity reference field and chain messages using messages to reference other messages. I outlined this in the README I believe. There is an alternative however and I must look into it's use, the Reply module. If comments were the ideal solution this maybe the best as it would allow a smoother upgrade path to a D8 version in future. i.e. - where #731724: Convert comment settings into a field to make them work with CMI and non-node entities is solved.

Your node option for the comments is interesting, but I don't like the design idea of it being a node, having a path on the system, etc. It may be the easiest approach to manage though, keeping it close to core and not replying on a lesser maintained contrib module. I will have a think about it. I'm not sure what the benefits of me defining a rule in code for this would be over just using a node_save call in my hook_message_insert. i.e. - Would this allow an end user to do anything special here if it's defined as a rule?

Blocking users to send me messages

I'll use flag module on the user entity for this (Block/Unblock).

Instant notifications about new messages displayed like the pmgrowl

This will be added to the roadmap.

Real time updates of new messages maybe using nodejs / views_nodejs or views_autorefresh

I have little knowledge of nodejs, but it seems like a path worth visiting for much of the instant messaging work.

Instant messenger functionality as seen in this module privatemsg_nodejs

Same as above.

Yea I'm all for providing customisation for non coders. I just wasn't sure if you had something specific in mind in this instance. I'm not sure how they would customise something fundamental such as assigning a node to a message entity to provide comments. I thought this may just end up as clutter in the Rules interface rather than provide something useful. I may be wrong though and probably am in this case, I've never been a heavy Rules user, only when using Commerce briefly. I'll have to think about Rules more in general as I guess it may be best to define important actions as Rules from the start...

Yes, I'm more comfortable with the use of Flag API for this particular feature. The ground work is all doable with Flag and it makes sense to use here.

Those points are interesting and it raises the question, do you won't to notify user's they have been blocked, or do you want the message delivery to fail silently. i.e. - The options being.

1. Deny message creation referencing users that blocked the sender - provide error notification
2. Create the message but hide it from the view of the receiver

I guess option 1 is the more common approach? Eventually perhaps there should be a "Block" and a "Hide" list to allow the user to choose to block or hide user messages.

I very agree with going no node way. Node is too heavy solution for something like this.

Btw all FOX_01 ideas are great, thread communication + reply (and reply to all), and blocking users are very fundamental functionality.

If the blocking functionality could be done using Flag, this could be very nice and simply.

Thank you!

I very agree with going no node way. Node is too heavy solution for something like this.

I am leaning towards my original plan of using an entity reference field to reference parent messages. i.e. -

1. Pass message id from customised reply button/link to reference a parent message
2. Use Entity Reference Prepopulate to populate hidden entity reference field
3. Use custom view and template to display thread of chained messages*

* unsure of the best way to go about this at present, a customised view in code or alternative method? I guess if you view a message you should really view the whole thread. Maybe this needs some kind of controller class to gather and return all referenced messages. Maybe this could be cleaned up at the display end using a jQuery accordion - much like Gmail threads. Any ideas are welcome.

.....we are talking about private messages which are often much shorter than an email.
.
.
A facebook like solution for this would be showing the last 5 messages and using views load more pager on sroll to load older messages. This has the advantage that this feature can be used for messager function (facebook as example) too.

I agree, this is a better solution, thanks.

Thought I'd add another idea to this thread surrounding:

Messages sent via a "facebook like" messenger for future reference

To get the best of both worlds:

• Messages sent via admin/content/message/create/private-message will allow a Subject field entry as exists with email
• Messages sent via the "facebook like" messenger with have either a blank subject field or "Sent via Messenger" automatically added for display in the users Inbox at user/%/messages. Perhaps only show body field in the messenger.

Messages threads

• Do not use a new message entity with an entity reference for replies
• Instead, perhaps the message entity can be the thread and configure the field_message_body to have unlimited instances
• Use field_message_body instances on the same entity for replies all contained in the one message entity (thread)

I think MessageJS would be a better candidate because of node.js and more scaleable in terms of notifications

Thank you very much for highlighting the MessageJS module. I have not looked into the nodeJS side of things yet as there are some more structural / fundamental issues that will be addressed first.

Although the MessageJS module is perhaps minimally used and maintained now, it will certainly be a consideration when looking at nodeJS for the Message Private module. Maybe they can work alongside each other well in the future.

Hi,
maybe Facebook style of sorting messages - everything connected with one user to have only in one discussion-threat, it is better or often more usable then old threated style.
Would be great to have this kind of sorting messages in your module.
I don't need threats, but however, if there will be threats, there could be an option treated/nonthreated style.
What do you mean?
Thank you
Igor

Thanks for this. Yes, threading definitely needs a little more thinking to conceptualise it fully. I'm not entirely clear on how it will be developed yet, so this needs some more research and discussion.

• I agree, for instant messenger style of messages, user to user chats should all be within the same thread
• For this to make sense outside of a messenger (which does not exist yet), should the "Subject" field be removed?
• Perhaps as suggested, if there was this Threaded & Non-threaded option in the admin UI. With threading turned On the Subject field would be hidden and messages combined into a thread

Facebook's messenger

Facebook's messenger is at the time of this post, lacking in terms of search, perhaps a result of this 1 threaded approach and not coding around it. E.g. - searching using a search term, it locates the threads where this occurs, but not the location in the thread. So, you cannot see where in the thread is the search term and you have to scroll back manually loading every 10 posts.

Loading the correct location in a thread would be possible I'm sure, but may be a little tricky. Some kind of jQuery loading in our case, for the message instances in the thread.

Compare this to Gmail: it finds the separate thread, and I think even expands the accordion for the message of the search term occurrence. I think ideally we would combine the 2 approaches here, 1 thread instead of separate threads, but expand the locations of the search term within the thread.

Message timestamps

Another important point you've raised here is a timestamp per message instance. This is definitely important and something that may be difficult with the latest approach I outlined in this comment #2367729-10: Message threads, instant messenger, notifications and user blocking, where a Message entity instance is the thread. In this approach, new instances of field_message_body are created on the same message entity instance for each new private message. i.e. - The problem is, is there a suitable method to store or retrieve a timestamp per field instance?

I've looked a little further into message timestamps using Message entity as a thread with multiple field_message_body instances for messages. I looked at using entity revisions to manage timestamps and also touched on the idea of a separate timestamp field.

Entity Revisions

It looks like Message is not revisionable, so I opened an issue to Make Message entity revisionable.

Also, this may have a large overhead as it would be creating a new revision per "reply message". i.e. - just to access the field instance's corresponding message vid in order to get the timestamp from the message revision. This would include a table called message_revision similar to the existing node_revision. I'm also not 100% sure it would work as described, but not fond of this approach currently anyway.

Date field (timestamp)

Maintain a separate field hidden from the Message UI for message timestamps field_message_body_timestamp. Make this field allow for unlimited values also and for every new field_message_body index, populate the same index in field_message_body_timestamp with the current timestamp.

I prefer this method so far and it seems to allow for using the message entity as a thread which I believe is still the best approach. i.e. - rather than a separate message entity for every "reply message" which would require entity reference field or similar for chaining a thread together.

looking forward to these features and i agree with using date field instead of entity revisions its just too heavy for what your trying to accomplish thread support is on top my list if all the ideas posted here comes through this might be the all in message communication module

Yes, message threads are currently the next feature to be developed for this module. I will most likely start this feature development in April, due to other commitments. In the interim, the new alpha-3 release will likely become the 1st full release, following any bug fixes.

looking forward to next progress of developing of this very promising module! :)

Hello mccrodp, is there any progress in last 5 months in this module? I didn't notice bigger changes,
so I am just curious if there is some roadplan with some dates and when new features from this thread will be added.
Thank you
Igor

Hey, no big developments in terms of features. Some more fundamental changes, which were more important to get right now, rather than later.

I had planned on starting the threads as the next big development, but there was no suitable solution, perhaps until now. It needs more work, but I've proposed a solution using a custom "Message Thread Entity" in a child issue: #2504863: Pluggable Message Threads. This could serve as a wrapper, referencing all message instances in order. So we can continue the conversation about threads over there.

There is no timeline really, I hope to start on the threads whenever there is a solid plan. Prior to this, my priority is #2489792: Port Message UI to Drupal 8, to make a D8 version of message_private possible.

As with #2504863: Pluggable Message Threads I am postponing any further work on this until D8 version is released.

Status update for this issue:

• Message threads (as above)
• Instant messenger: not planned, perhaps in future via NodeJs integration / MessageJS for D8
• Notifications: via some kind of Drupal status message /user (and/or as above via module integrations)
• User blocking: via Flag module when ported #2592949: [flag] Flag

Will post follow up child issues for the above when there is a D8 version and then close this parent issue.

For those, who have to stick with d7 for a while.

I was able to archive something like discussed here, about having comments for the message entity, with the reply module https://www.drupal.org/project/reply. This patch https://www.drupal.org/node/2473447 helped me out to get it working. I did not fully test it, but in case of having threaded comments for an entity, it seems to work well.

Of course, going this way would need some other changes to the message_private module as well, in case of ui/ux. Like removing the "Create Message for " link, handling inbox and sent folder and so on. But in case of threaded replies to a message, this took me pretty far.

In general I would say, this modul or the whole message stack, should be seen more as a toolbelt, than an out of the box solution, cause implementing any kind of messages into a site, always has customs needs, derived from the purpose of the site.

...but well, that's what it is already, or ...thumbs up to all the work that went in here!

That's awesome @uniquename, great job. Perhaps if appropriate you could provide a patch for this. I would hesitate to put this into the module unless it was pretty solid & integrated from the ground up / in an experimental sub-module, but it could certainly help other developers!

Yea it would need to remove / modify the local tasks in the local tasks alter hook or in the theme layer. For the views, well it looks like they can be modified as the Reply module seems to have views integration.

I agree for the most part with you here, this module is really an aim to be a skeleton, built as close to best practice as possible, allowing greater flexibility and customisation. However, Message stack does provide Rules integration, so site builders can get quite far customising with rules (and views) if the basic setup doesn't get them what they want.

FYI: Threading / Conversations will most likely be with FOSMessage in D8, see related issue: https://github.com/FriendsOfSymfony/FOSMessage/issues/19 So, ideally someone could provide a patch with a backport once it is in place in D8. All I need now is that, oh so precious, time! ;)

Thanks, mccropd. Actually it was more mangeling togehter modules than wiriting own code. So I don't really have a patch to provide... and I guess I've already overthrown this concept, cause it brings in a lot of problems regarding in- and sentbox, let's say I have a view that shows all my messages by date, if someone replies to me to an old message, how to bump it in the inbox.

But I was digging into the concept of using an entityreference field to reference the parent message and actually that also looks very promising, too;-). My idea here is, to also have entityreference_prepopulate enabled on that field and change the reply link accordingly. It could also be changed to make a "reply to all" possible by having all uids prepopulated. It could look something like this

message/create/private-message?field_message_user_ref=2,3,4,5&field_message_parent_ref=5

This would give it pretty much a standard email style reply handling, where the sender decides whom to reply to.

Having the display options for the field_message_parent_ref set to rendered entity would also automagically produce a threaded view. The threaded view could also contain links to reply to msgs that are in the thread.

In any case I will have to come up with some solution here for customer happiness ...so maybe we could start some cookbook pages, where I can leave my solution.

I've read about the d8 / FOSMessage plans, but wouldn't that mean to leave the path of having message_private sit on top of the message stack? Cause then private messages wouldn't be message entities anymore?

Sounds good @uniquename. Let me know how you get on when it's all up and running.

Re: FOSMessage <-> Message Stack. Not necessarily from what I know so far, it'll hopefully work together with it. Just have to use a hook to make the User class implements PersonInterface from the library: http://fosmessage.readthedocs.org/en/latest/book/getting_started.html#st...

Then create a custom Drupal driver as it only supports Doctrine via a Doctrine driver at the moment: https://github.com/FriendsOfSymfony/FOSMessage/tree/master/src/Driver

A custom Drupal driver would point to the Message Stack classes and a new "Conversation" class, similar to: https://github.com/FriendsOfSymfony/FOSMessage/blob/master/src/Driver/Do...

Will see when I have time, I'll put the driver in a separate module for starters, then evaluate its potential for use with Message Private.