Part 1 - Building your action logging
IMO the Message module could be a perfect alternative for the activity logging you are trying to implement. Using this module, you can create your own custom "Events logging" (to register things that happened in a site).
Specific to this question here, I'd create one or more so called "Message types" that contain data about:
- the usernames (of the latest editors of content).
- the relevant date(s).
- any data about the actual entity (node, user, etc) or event you want to track, such as the node's id, its title, author, relevant field values, etc.
You could even track things like updates to nodes, i.e. how data looked like before and after they got updated, a kind of "light" revisioning (only for those node attributes you want to know about).
About Message types: think of them as equivalent to Content types, whereas you create messages (instead of nodes) of a specific Message type (instead of Content type).
Part of the Message Stack
The Message module is part of the Message Stack, which consists of these modules (quotes are from the module's project page):
Message:
The Message module is the core of the message stack. It enables logging and displaying system events in a number of different use cases. Events that are recorded over time are sometimes call activity streams. Exportable messages subtypes can be created for different use cases with custom fields and display (view) modes.
Message Notify.
This module provides a method for sending a message via a notifier plugin. Message Notify comes with plugins for email and SMS and may be extended to other transport mechanisms as required.
Message Subscribe.
With this module, users who subscribe to content will be notified when events occur that involve that content. The module leverages the Flag module, which provides a subscribe functionality to users.
These are the basic components and dependencies of the message stack:
Think of the Message Notify / Message Subscribe modules as successors (replacements?) of the Notifications / Subscriptions modules ... even with Drupal 8 successors available also.
Just looking at the available documentation about the Message Stack, it's not obvious to get going with it. But if you want to have a closer look at the Message Stack in your own environment, then experiment a bit with the Answers module (disclosure: I'm a co-maintainer), together with the Answers Notification sub-module, which allows logged in users to subscribe to selected questions, so that they receive notifications (using the Message Stack) when Questions receive Answers.
Rules integration
A really interesting facility of the Message module is its perfect integration with the Rules module. Have a look at the answer to "How to implement a follow author (or user) function?" for way more details on that.
As an example, here is a (rather basic) custom rule:
- a Rules Event like "Before saving a new node", of "After updating an existing node" (or variations of these events).
- a Rules Action to "Create a message" (of a selected Message type).
That's really it ...
Example included in Commerce Kickstart
A great sample of this can be found in Commerce Kickstart, which uses the Commerce Message module, to create such "Events logging". In that case in the format of an Order History, as shown in this screenprint (from this module's project page).
Replicate/replace the Activity module
Should you want to do so, it seems perfectly possible to build a view (report) that contains the data similar to what you can do with the Activity module as shown in this screenprint (from this module's project page).
More info about the Message module
The Message module is an amazing module, it is fully entity based, which implies that it perfectly (out of the box) integrates with modules such as Views and Rules.
Though there is not a lot of documentation about it (which is what makes it a hidden D7 gem ...). A possible way to get started with it, and to get an idea of the kind of things it can be used for, is to have a look at the answers to:
Tutorials:
Part 2 - Building your journal style Newsletter
After you've implemented your action logging, similar to what is described in "Part 1", it really becomes a piece of cake to complete it with the journal style Newsletter. Because your action logging will be fully entity based, and therefor perfectly integrates with modules such as Rules and Views.
If you then also add the Views Rules module to it, you've reduced your Newsletter challenge to building some rules that:
- Run at specified intervals (eg when cron runs).
- Process (= Rules Actions) a views result (using Views Rules) to create an appropriate "digest" of relevant messages contained in your action logging.
- Send that digest by eMail to only those users for which the Views results are not empty (i.e. if there is anything new that happened in the site, and which the user wanted to be informed about).
PS: for dozens of other questions (+ answers) about the Message Stack, refer to this.
