Show conversation instead of just single post

This is the reason i have the thread_id in the database schema. right now its not used much.

the problem with threaded versus non threaded message listing is that you cant re-use the same queries on the same database schema and still have the query efficient. more correctly i think you CAN but i havent figured out the correct query to make it work.

My concern is to have this functionality work with no performance degradation regardless if you show threaded or non threaded discussion.

I am fine with defaulting to threaded-only format, but i havent decided whether i should be so strict. help me decide please.

@nbz: i wrote the whole query builder myself from scratch. it is not something you can find documentation about online or on drupal handbook...

so if you'd like to find out more about it i will be more than happy to explain it to you if we speak on IRC.

in http://drupal.org/irc you will find instructions on how to get to #drupal. one you are in #drupal you should ping me (litwol) and we'll chat.

i use http://www.mirc.com/

i'll explain everything when you get on irc.

Patch in #12 doesn't apply:

patching file privatemsg.module
Hunk #2 FAILED at 357.
Hunk #3 succeeded at 488 (offset -2 lines).
Hunk #4 succeeded at 592 (offset -2 lines).
patch: **** malformed patch at line 97: @@ -642,12 +654,15 @@ function privatemsg_privatemsg_list_alte

Ah, that works! Say, what is your thinking in removing this?

- $output = theme('privatemsg_to', $message);

And what is it that this line does (or did before you removed it)? I'm not up on the Forms API:

- $form_state['rebuild'] = true; //rebuild this message for ease of use

Can we set the breadcrumb for the view page here? (Home >> Private messages) Callbacks apparently don't do that automatically like local tasks do.

Patch #15

patching file privatemsg.module
Hunk #2 FAILED at 357.
Hunk #3 FAILED at 488.
Hunk #4 succeeded at 596 (offset 3 lines).
Hunk #5 succeeded at 641 (offset 6 lines).
Hunk #6 succeeded at 658 (offset 6 lines).
2 out of 6 hunks FAILED

The first bit adds a "conversation between x , y and z" line above the messages and is potentially broken in a threaded view. What needs to be done is show the recipients per message.

Yeah, I understand what it's supposed to do, but I don't see (in privatemsg_preprocess_privatemsg_to() ) how this could be broken. If, per our previous conversation, replies to a thread cannot change the recipients, then each message will have the same recipients as other messages in the thread.

(That's not completely true, since it's possible for a user to be dropped from a thread if they no longer exist or if they no longer have permissions.)

Can we/should we iterate over all the recipients in the thread instead? If this feature is broken by threading, then it seems we should fix the feature instead of simply removing it.

The second line re fills in the form with the data you sent.

Thanks. The Forms API documentation doesn't quite make sense to me. It probably makes sense to someone that's been working with it a while, but I'm still trying to get my head wrapped around menus. The description "The 'rebuild' key overrides the 'redirect' key: when it is set to TRUE, the form will be rebuilt from scratch and displayed on screen" doesn't indicate that the form values are retained.

I will look into #3.

Something like this should do it:

$links = array(l(t('Home'), '<front>'), l(t('Private messages'), 'messages'));
drupal_set_breadcrumb($links);

Since the message recipients are the same each time a message is fed to the function (if using your other patch), $vars['recipients'] will always be the same, except in the instances I noted. Still, the theme call could be moved so the function only gets called once -- and so that users no longer in the conversation are included, but not linked.

The breadcrumb for "Read private message" on my site is "Home" instead of "Home > Private messages."

I made a couple formatting changes, but this is basically #24. I'm unclear on the purpose of the max() function in the _alter routines. max() expects an array, does it not?

Nevermind. MAX() is a MySQL function in this case, not a PHP function. Patch in #24 is good to go.

When posting new patch please set the code needs review

Patch works. Whether or not the way we're making database queries is correct is litwol's call, though.

Oh, the template and css file names need to be changed to include "participant" instead of "recipient" (for consistency).

instead of coding around query builder limitations we should patch query builder to allow us executing the quries we need. If we don't use query builder then we disallow other modules easy integration.

I really want to get this issue resolved and commited soon. But only if we fix the query builder in this or very next patch.

Is this feature already present for the Drupal 5 version of this module?

I haven't aplied the patch yet, but in going over the changes I noticed these issues:

- privatemsg_preprocess_privatemsg_to() doesn't account for threads with only one participant. Highly unlikely, but what happens if a user is deleted?

$query = _privatemsg_assemble_query('privatemsg_participants', $message['thread_id']); -- Should it be ..., $thread_id? Just for consistency?

$query = _privatemsg_assemble_query('privatemsg_participants', $message['thread_id']); -- this assumes no messages have been deleted. Any deleted messages may be the last from/to a given participant, and thus that user will not be listed as a recipient nor get future replies.

Just tested against a deleted user and, yes, theme() returns whatever the site settings have named an anonymous user.

As best as I can tell, threading hasn't changed outwardly since #31. Patch in #41 seems to be doing its job.