This project is not covered by Drupal’s security advisory policy.

Private Message Advanced adds the things people expect from a messaging app to Private Message: a Details page for every conversation, the way iMessage, Telegram and WhatsApp have one, and editing or deleting a message after it is sent.

Features

  • A Details page for every conversation: its name and who is in it.
  • Name a group conversation.
  • Add people. Adding to a one-on-one starts a new group, so the one-on-one keeps its history.
  • Remove members, or leave. Each change posts a line in the conversation ("Alex added Sam").
  • Edit your own messages for a set time after sending. Edited messages are marked.
  • Delete your own messages for everyone for a set time after sending.
  • Edits and deletes show up live in open conversations and inboxes.
  • A permission for each action, and settings for the member cap and the time limits.

It works on Private Message 4.x with no patch. It adds a few new base fields to the private message entity, and leaves existing threads and messages as they are.

Themeable

Everything ships plain and takes on your theme's look:

  • Twig templates for the Details page and its sections.
  • The member list is a View.
  • Ordinary forms, alterable with hook_form_FORM_ID_alter().
  • Alter hooks for a message's actions and a member's actions.
  • A CSS class on every element, and a layout-only stylesheet.

The README lists every route, form id, template and hook, and walks through the common customizations, avatars included.

Why a separate module

Private Message identifies a thread by its exact set of members: that is how it finds "the conversation between these people." Adding leave, remove and add breaks that lookup, since once C leaves the A, B, C thread, it has the same members as the real A, B conversation, and a fix has to decide how Private Message tells the two apart. That decision needs the maintainers, and the issue queue shows no agreement on it across seven issues and several years. Rather than wait on that, this module makes its own decision (see "How it works" below). If the maintainers want this merged in to the main module, I am all for it.

How it works

The members field stays the live roster, so every inbox query, unread count, access check and notification in Private Message follows a change with no further code. One small table records every join, leave and removal, and it carries the rule that dissolves the collision: a thread with any row in that table is reachable by its id only and is never again the answer to a member-set lookup. Threads that were never edited keep their uniqueness exactly as before. The rule is applied by swapping the module's thread service for a subclass that overrides the one lookup method.

A deleted message keeps its entity, so the thread's references to it stay valid: it is marked as deleted and its text and fields are emptied. Live updates ride on Private Message's own poll, which the module extends to also send the messages changed since the last tick.

In the database: one new table, private_message_advanced_log, and four new base fields on the message entity. membership_event marks a system line (joined, left, removed, renamed) or a deleted message, affected_user and thread_name hold the facts a system line is built from, and changed records an edit. No existing data is modified.

Requirements

  • Private Message 4.x
  • Views

Project information

Releases