Drupal 9 version of privatemsg

As you can see in the issue queue, I currently don't have time for Privatemsg.

I am interested in 8.x however. Port vs Start from scratch is an interesting and non-trivial question. It might be time for a restart, as a lot of concepts are still 6.x-ish or early 7.x-ish (like only relying on the core entity system and not entity.module).

However, you need to be aware that a *huge* amount of time was invested into the 6.x and 7.x versions, and being able to rely on things like a better entity system, views etc. will only help so much. There is a huge amount of complexity related to the thread/message handling, visibility of messages, recipient types, deletion, all kinds of integration points, often through altered queries and in general almost everything is a bit special and requires additional logic and checks to ensure that private messages stay private :)

Not that porting the current code will be much easier.

Suppose better to finish long standing #744374: Introduce a pm_thread table first

.

I am also interested on helping with this port.

I am totally unfamiliar with the D7 code base (yet), so please forgive me if I'm oversimplifying things.
I'm wondering about #1: why is privatemsg so special?

Leveraging the Entity API should make views integration feasible. Threading messages should be similar to how the comment system works. Access should be granted if the user is the sender or a receiver of the message.
BTW, it could be even built upon the Message module. (edited: there is already message_private built on Message, without support for threading messages)

What am I overlooking?

Updating the title name so it's clear which module when viewed in a list.

#1 says why it is special. It is a combination of two things: a) *everything* is per-user and b) Tons and tons of features.

Note that privatemsg threads have nothing in common with comment threading. A privatemsg thread is more like the comments of a single node, but technically very different. Threads in privatemsg are virtual, they are not persisted somewhere as it is different for every user. There is an issue to maintain a thread table, similar to a materialized view but it is very complex.

Imagine this scenario.

1. User A sends a message to B, C, D
2. B responds but C has B blocked, so only A and D receive the message
3. D now deletes the first message (which only deletes it for himself!)
4. A now deletes both messages.

Which user now sees which message? Some see all, some only undeleted, A doesn't even see the thread anymore in the overview (until someone responds again).

And that is only a small subset of the complexity, now add fun things like admin access to view messages of other users, recipient groups/types, extensibility of queries, purging and many other things...

Privatemsg is much much more than sending a private message from user A to B.

Oh, hi @timplunkett ;)

If you want to do a port of this module. Then you have to start from scratch. You want to integrate #744374: Introduce a pm_thread table and support views.

The privatemsg 8 module looks a bit like the node, nodetype and comment entities in drupal 8. In privatemsg this will be thread, threadtype and message entities. The history entity will be in privatemsg the thread_user entity.

This is my idea. If anybody has some other ideas please let me know.

@Berdir, much appreciated, #12 makes its really clear.

@daffie: Yeah, considering pm_thread is a good idea. Note that privatemsg currently doesn't have types of threads/message (message is the actually entity right now, so message type would be more like it), I don't think that should be a priority for a part.

As written above, not sure if a fresh start is really a good idea. IMHO only if you know the existing source and feature set well, as we evolved and learned *a lot* of the few years that I actively worked on it. So starting new is a risk for missing many things.

Correct me if I am wrong. As far as I understand for Berdir the privatemsg module is a message centered module. If you add a pm_thread table. And you add view integration and VBO. For me it becomes a thread centered module. Where every message belongs to one thread (via a foreign key relationship). Keeping it a message centered module makes it (almost) impossible to add a pm_thread table.

It already is thread oriented, the threads just don't explicitly exist in storage, we execute complex queries to return the information we need.

pm_thread would be a materialized view that contains per-thread summaries (new messages, last update, numer of messages, recipients, title...) summary per-thread-per user. It is probably not even an entity type, as it has very custom storage operations, not the usual load/save/delete.

So, any plan should start by fixing #744374: Introduce a pm_thread table for D7, right?

With all do respect. I am not convinced that your message centered and thread calculated solution will work. And specifically in my eyes it will not be scalable. I understand that it has grown from a message based beginning. And if you want to add threads and views integration and VBO it has to change to a thread centered solution. I see no other way forward.

It's not strictly necessary to fix that in 7.x first, can also be added to 8.x directly. Getting major refactorings into 7.x or 6.x is unlikely atm.

@daffie: I don't get what you mean. It does work right now and I'm pretty sure there are sites with large amounts of private messages out there. And it has not grown, it has been redesigned from scratch to work like it does now in 6.x-1.x. And as mentioned, the point of the pm_thread issue is to improve peformance and scalability, but that is a very complex topic.

I am trying to understand how this module should work/is working. Let me start with the relationship between messages and threads. My questions are:

1. Do all messages belong to a thread? If not, why?

2. In #1193232: Move thread_id to pm_message you want to create a foreign key in the message table to the to be created thread table. Is that still something that you want?

Thinking in comment module POV:
1) user has pm field attached somehow on user entity, a kind of core contact extension would be great (there's contact storage module at least)
2) so each user carry a set of threads, thread entity is created manually with some app logic
3) thread have a comment field that implements custom field access on thread entity

PS: that's just a high level thoughts on that

Hi guys, here is my sandbox with some thoughts how privatemsg can look like on D8: https://www.drupal.org/sandbox/id.jk/2395689

Lot of functionality is missing, nothing is documented and most of the things is probably implemented incorrectly, but I am going to fix most of the issues and make it usable to the end of the year.

I need this functionality for my own project so I'll continue work anyway, but I'll be happy if any parts of my sandbox module can be used as a part of future D8 version of privatemsg. Any feedback is appreciated.

I've added several commits to my sandbox and made module at least minimally usable. See sandbox description for details.
I am not going to work on adding missing D7 features for now (currently I need ability to search messages and threads and I'll focus on this).

If anyone is interested in my code - please contact me: I'm not going to promote my sandbox to the full project and probably delete it after some time.

@Berdir was reading through comments and was thinking why couldn't threads be managed by adding a referenced field in private message entity. My thinking is threads are only relevant in the context of replying to an initial message. Sorting could be handled by timestamp.

When user creates a NEW private message the referenced message field would be NULL indicating it was the start of the new thread. When other users reply to that message it's message ID would be included in referenced message field for subsequent messages in thread. It seems that it would be a pretty simple way to create threads with low overhead.

Build thread from message:
1. If message's referenced field is NULL querying all messages that reference it's MESSAGE ID will produce thread
2. If message's referenced field is not NULL querying all messages that reference the same MESSAGE ID contained will produce thread

I'm no programmer so I may be oversimplifying but just thought I would contribute my 2¢ in hopes of helping or learning something.

Would privatemessages be easier to code if it only needed to be able to be between any two user?
so the scenarios described in https://www.drupal.org/node/2134735#comment-9360837 wouldn't occur?

I think alot of user would like a good and solid Private msg system that would just work between 2 user

Hello, just wanted to let you guys know that there is a Drupal Module Upgrader (upgrades module code from 7 to 8) not sure if you knew about it already, but if not, then check it out!!! might help make porting life easier.

Do we have any new developments regarding this module? We have a project that requires messaging between two users. Threading would be be very nice. We are reluctant to build this on D7...

Yep, we're looking for something as well for our site rebuild.

Hoping for a D8 version...

I also only need PM between two people.

Why not just provide a migrate plan to https://www.drupal.org/project/message_private and be done with effort duplication...

Thanks for the mention @giorgio79. Message Private came about due to a common requirement to keep all forms of messaging on a site/system 'under the same roof' / using the same stack.

Privatemsg has a lot more features currently and has been around a lot longer, so I don't want to make any bold statements about it as I don't know the module very well.

However, in terms of an upgrade to D8, I imagine upgrading #2613152: [message_private] Message Private to D8 is a much more manageable task than upgrading Privatemsg, especially if both are on a voluntary basis.

On Message Private replacing Privatemsg in D8; that is up for debate and I'd be willing to discuss with anyone interested via IRC. If this were to happen, there are some PRs that would need to be submitted to Message module to make it more general purpose, among other items.

I would be all for this, but it is a slow process at the moment (mostly due to upgrading the dependencies 1st) and requires discussion. I certainly think using an existing stack for private messages makes a lot of sense. Perhaps looking into writing a module / plugin for Courier which would provide a "Private Message Channel" could be another solid idea for D8, without effort duplication as you stated.

Maintainer of Courier here (awoken by previous mention) , I'm following this issue in anticipation of creating a private message plugin. But if this project has stalled than I believe we (> @mccrodp) have the necessary expertise to get something going.

Ping me on IRC.

@mccrodp and I are getting the ball rolling on this project. Please get in touch with us on IRC if you have any well thought out opinions on the future of private messaging in Drupal.

As outlined in #2630490-4: Turn chatrooms and messages into entities, we've parked this for the time being due to time constraints v.s. development complexity.

If the dependency blockers on message_private upgrade get resolved, I will continue to upgrade that as previously planned and possibly release a 2.x branch in the future which integrates with Courier.

There is also a possibility to collaborate with Chat Room module as there may be some overlap here, will see.

Any updates on this? Thank you.

+1

I tried to install the sandbox project https://www.drupal.org/sandbox/id.jk/2395689 on Drupal 8.2. But failed.

Unable to install Privatemsg, pm_email_notify.mail has unmet dependencies.

This seems to be where development is at to get the features of this module into Drupal 8 #2622814: [privatemsg] Privatemsg

I find I need this module and I'm ready to contribute to a D8 port. Is the initiative still active? Where's the discussion happening?

So I think the Drupal 8 port should obviously come from the 7.x-1.x branch, however like Berdir says, a fresh ground-up D8 rewrite would be the way to go here.

I've gone ahead and cleaned up the page with a list of functionality for the different branches at https://www.drupal.org/node/2039283 , I'm sure there's more that's been missed here but I think a 8.x-1.x branch should include atleast the basics.

if you know something about the status of some functionality either not mentioned, or marked incorrectly please update that page.

@me-taras that patch looks like boiler-plate Content Entity code :(

Maybe efforts should just be focused on the Private Message module which has been build for D8, uses more Core APIs such as Entities and Fields, and already has a Beta build.

@AaronMcHale I would say, that this could be a possibility if D8 dev's from this project could have commit/maintain access on that project, because private_message seems to be maintained by just one person it seems slightly risky to recommend that this project be the replacement. I've contacted that project's owner to see if I can get maintainer access.

@dgtlmoon that makes sense, I think though ultimately it would be more productive for everyone to focus on one solution rather than different projects that do the same thing so if there's anything I can do to help encourage that to happen then do let me know :)

It looks like @Jaypan is open to co-maintainers: #2868286-26: Issues to be resolved for a full release

There are lots of features this module provides that neither Private Message nor Message Private provide and that many people are used to and expect, for example: #2879121: Anonymous communication. So there would need to be some work done to get those up to par with what people expect from this one.

I also think that for either of those other two modules to take the place of Privatemsg, some sort of migration of data will be necessary.

I personally am not doing any D8 development, so I will not be helping with any of those efforts. I can, however, create an 8.x branch for this module, if other people want to do something with that.

Just my 2 cents...

I tend to favor modules like Privatemsg (or Private Message) because they are a "one drop" solution. In this perspective, a module like Message Private, that relies on a "chain of modules", is riskier on the long-term (maintenance, popularity, etc.).

I don't code, so I am not in a position to support a solution or another. I will only say that I would favor a D8 version of Privatemsg.

But in the end, I tend to think in terms of time, and more particularly for the maintainers. I tend to think that the Drupal community would be better off with less modules supported by more maintainers than having users and maintainers scattered around tons of modules. I understand that each module has a specific approach to a problem in terms of "philosophy" and "coding approach". But in the end, it sums up in time given to the community.

So, a D8 version of Privatemsg would be nice. But maybe its time to consider an "association" with Private Message and a migration path for D7 Privatemsg to Private Message. Of course, the maintainer of Private Message has the right to refuse any "association" to preserve his/her module. After all, it is his/her time and efforts.

To answer the Privatemsg vs. Private Message question, I would say that thing should be weighted in terms of efficiency and speed (with of course the participation of Private Message author). Considering the "inherent" problems of Privatemsg (among which the Views "connectivity"), what would be the most efficient: coding a new version of Privatemsg or getting all together to get the most out of Private Message with a path for migration from Privatemsg?

Well... that was a rather long post. So, I guess its my Saturday morning... 4 cents ! ;)

NG

@Northern_Girl I can appreciate what you're saying when it comes to "a pancake stack of modules" (so to speak) with chaining dependencies, but as a developer I can also say that there is an upside to that.

If the stack is well maintained and developed it means that for the private message module at the top of the stack there is less code to maintain and so it is more maintainable and easier to get new releases out. So as long as the modules that it depends on are actively developed and have a lot of interest in making sure they are up to date (as in the case with Message Private) then I think it ends up being an advantage rather than a disadvantage, since you have way more people with a vested interest in making sure the code at the core of the module is working and up to date.

Obviously that's just based on my experience as a developer so feel free to disagree, but I do think it's a useful insight.

Any updates on this issue? Thanks

I have had a quick look at private_message considering a migration path. A problem with private_message is that it stores recipients per thread whilst privatemsg stores them per message.

This means the cases such as where a user hasbeen blocked by another user mid thread (or the originator can communicate with two users but those users are blocked with communicating with each other) is not supported by private_message.

del

The alpha version for Drupal 9 was published