"You, Bob, and 7 others have commented on 'Dog Training'" <show more>

Sometimes very similar messages are not worth showing the user, or especially (with #1073056: This is a New Message/You have 4 New Messages) highlighting for the user. For example, messages relating to the fact that a specific node was updated 7 times would be horrible clutter as 7 distinct messages in a row. Better to have something more like Facebook's "Bob, Janet, and 7 others updated/commented on this node". Like Facebook, I think it would be neat to retain the potential for a user to click something and still see those individual messages without needing to dig around for revision history and such.

From previous conversations with Amitaibu, it strikes me that their are a few options here.

  1. When a redundant message comes up, update the existing message text to specify the most recent user to take the action, increment a +X, (Bob +7, where Bob is most recent to act.), and duplicate the message into the new user's realm as appropriate. (Rather than duplicating in all realms.) Random bonus thought: User realm version should be You, Bob, +6 others.
  2. Messages are stored individually, but when their is a redundancy detected, a special message is created that acts as a "summary message". A flag in the database is set that deactivates the non-aggregate messages for normal viewing, but leaves them in place and available for special queries to audit the details of the summary. As new redundant messages come in, they are created as deactivated and the summary message is updated.
  3. Messages are scanned in hook_views_pre_render according to some kind of logic based on redundant messages of the same type targetting the same content. It is generalized for message types to opt in for "redundancy consideration" instead of hardcoding specific types.
  4. Scanning a la (3) is simplified by generating a message_set_id and looking for it as messages are saved. Then hook_views_pre_render can just check for set ids. Probably not worth the trouble.

Comments

Grayside’s picture

Assigned: Grayside » Unassigned

Not thinking about this right now, leaving it in case someone else wants to take a stab.

igorik’s picture

it souds really interesting, hope someone will take over this issue.

Grayside’s picture

As I said in #1180870: Is this module still in development? Is there some roadmap for it?, I've decided this really belongs outside Drupal, as the load for this kind of processing is too much and really has no need to be part of the Drupal system (except perhaps for the database credentials).

If someone wants to work on this, I'd say it's a submodule or separate project that focuses on a drush command. Note that drush can't really provision the database with new tables in the Drupal way, so how it would store its information is a good question.

bluegeek9’s picture

Status: Active » Closed (won't fix)