Delete Architecture

I assume that for the message to be removed from the database *both* the author and the recipient need to delete it?

I vote for deleting only the message from the Inbox/Sent messages of the person doing the deleting. Another normal user should not have the right to delete messages in my Inbox/Sent messages which I might be archiving.

However, a "Call back" feature could be implemented which would delete an unread message from the recipient's Inbox.

In threaded view, does delete mean just delete one message, the whole thread or a choice?

Give the user a choice: just this message or all.

Hmm. I have a problem with the current schema. As the schema is right now, for each message that a user sends to a given recipient a record is stored only one time in pm_index. If User A sends a message to User B and User C, two records are stored in pm_index. Those pm_index records each refer to a single instance of a message which resides simultaneously in my Sent messages and the recipient's Inbox.

Going back to what I said in #1:

I vote for deleting only the message from the Inbox/Sent messages of the person doing the deleting. Another normal user should not have the right to delete messages in my Inbox/Sent messages which I might be archiving.

Unfortunately, with the current schema, a message cannot be deleted from User A's Sent messages without that message also being deleted from User B's and/or User C's Inbox.

In order to "properly" delete a single instance of a message, when User A sends a message that message must be indexed separately in pm_index with User A as the recipient/participant. So, for each message that a user sends, (n+1) records (where 'n' is the number of recipients) are stored in pm_index. When a message is deleted, only the pm_index record for the participant is deleted -- and the other participants in the thread retain their copy of the message.

The pros nbz lists in #4 of #302403: Author in both tables? are still relevant, and this moves us closer to a unified Inbox (no Sent messages) as well.

I don't see how that will work - the extra record will not contain all the participant data.

Sure it will! If User A's sent message (using my example above) is inserted into pm_index with User A as both the author and the recipient, that record has all the same information as the other records for that thread.

PS with what I was discussing above, I was assuming two new columns in pm_index: author_del and recipient_del. If either is set to zero, it would signify that the corresponding user has deleted the message. (similar to how it is done in the drupal 5 version of the module.)

I understood that. As I see it, that

• Increases the overhead for each message saved to the db
• Leaves data in the db instead of actually deleting it
• Doesn't answer my objection to allowing another user to delete messages in my PM store.

the *delete* functionality should actually delete the data. later when we implement tagging we will allow people to move messages to *trash*.

@nbz: I see the problem. Should we keep a list ("uid, uid, uid, ...") of the participants in a pm_threads table? One row for each thread, with thread_id, participants, and subject. That would allow us to get the subject out of pm_messages, since it won't be editable in a thread, anyway.

Records in pm_messages, it is true, cannot be deleted until all related records in pm_index are deleted.

Would that not make pm_index redundant?

To a small extent. Rather than putting that data in pm_index for each instance of a message (once for each participant), though, it's only in pm_threads once for each thread.

However, having thought about it, I see what you're trying to accomplish with the two delete columns and remove my objections in #5. #5-1 and #5-2 are probably a wash with any other solution; #5-3 is addressed by your schema.

There are some code offsets, but patch applies. Database fields are created, deleted messages are hidden from the view of the user that deleted. Good to go!

This does not work as intended.

I will write out more detailed info later. but for now all i did was send message from user a to b, then reply from b to a, then reply from a to b.

Then i sent into the database and set 'author_delete' for user A to 1 for both messages.

refresh the page. _nothing changes_. no visual change after the DB change.

litwol, check again after making sure User 1 is not the author or recipient of a message. It's likely that what you are seeing is due to the access check for "read all private messages." A user with that permission will be able to see his own deleted messages.

I'd like to tackle that issue in my pending access control patch, if everything else in this patch is okay.

User A is uid = 1. however viewing messages through some one else's account, even with view all messages permission, should stil abide by the fact that author set his message to 'deleted', therefore should not be seen.