My thoughts are to build a stream of all the activities every user / party does/ is involved in throughout the site. There are a bunch of modules that try and do this for users and in true party fashion we make it our aim to make whatever applies to users apply to parties instead.

From my own research I have found that http://drupal.org/project/heartbeat is the best module to work with due to its involvement with D7 and its development activity.

What we'd have to do:

- Research exactly what bits of heartbeat we need to make work with party. I think we can provide tokens or something
- Create some "Streams" that means we can use panels to add a stream that shows all the activites a particular party is involved with
- Make sure simplenews works with Heartbeat + Party
- Figure out if scalability is an issue. If simplenews e-mails 10,000 parties how does heartbeat store this? Is it 1 activity to 10,000 recipients or 10,000 activities each to individual parties? I think the latter but can heartbeat handle the insane number of acitivities party would be sending it?

CommentFileSizeAuthor
#12 1550498-12.patch2.54 KBrlmumford
#7 1550498-7.patch2.53 KBrlmumford

Comments

joachim’s picture

joachim commented

What it needs to be able to handle is gathering data activities both by a particular party, as well as done to that party.

Eg:

- Bob buys a product
- Admin user changes Bob's details
- Staff user phones Bob.

All of those should be listable for Bob.

Ages back when I was pondering this it seemed to me that an activity consists of these parts:

- subject
- object
- verb

Though the party we want to list can be either subject or verb, so maybe it's more like 'party', 'actor', and 'verb'.

spencerfromsc’s picture

spencerfromsc commented

Sorry, just catching up with the queue. The Statuses project has Heartbeat and Activity integration and will provide most of what you're looking for, I think. Not sure how long the migration will take, though.

jeff veit’s picture

jeff veit commented

http://drupal.org/project/role_watchdog is interesting too.

yautja_cetanu’s picture

yautja_cetanu commented

http://drupal.org/project/message

This module looks amazing!

- It is built entirely for D7 and relies on the entity API and as they are entities they are fieldable!
- This means it can use tokens to do pretty much everything you'd want to do to design how the messages should be displayed. It means all the arguments about how to messages should look "Object Verb Subject" etc etc can do done on a site by site basis.
- It uses rules and so these rules can be done on loads of different stuff

And in my opinion the biggest 2 reasons is that its used by commerce kickstart and drupal commons 3.x!

yautja_cetanu’s picture

yautja_cetanu commented
Title: Start Integrated Log of all Activity - Integrate with Heartbeat » Start Integrated History Log of all stuff - Integrate with Message

On one of our clients we've ended up calling it a "History Log".
On Salesforce they call essentially the same thing "Chatter" (Because you can comment and like all entries)

I like History Log because it reserves the word "Activity" for the thing captaindav is doing with the B2B starterkit. (Activities are entities that are Tasks and Events and I think will become part of "Project Entities")

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented

Bumping the issue as we're working on some of this stuff in Party Simplenews.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented
Status: Active » Needs review
StatusFileSize
new 1550498-7.patch2.53 KB

Here's a first patch. It basically provides a framework for storing messages about a party.

We define a message_type_category so that we can group all the party related messages together easily. We also make sure every message_type in that category has a party field.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented

If everyone's happy with the general idea of integrating with message for this sort of thing, I suggest we commit this and start separate issues for the different things we may want to log.

andrewbelcher’s picture

andrewbelcher commented
Status: Needs review » Needs work

Looks like the new file is missing a line ending...

Looks like a good start for a framework... I think put it in and then the individual modules can implement their own logging (probably making use of module_exists() and it's own config). I'm wary that Party could become huge with additional modules and I would like to keep the bare framework in Party and use Party Extras or entirely distinct modules for all the additional integration.

Some ideas that should go into follow ups once this is committed:

  • Document some 'how to log things for parties' so we have a consistent pattern.
  • Provide a central config page where you can choose what get's logged. I'm thinking it's built by party_log probably using hooks/some other method to get the list of options.
  • Provide some views or other interface to be able to easily expose for a specific party.
andrewbelcher’s picture

andrewbelcher commented

Also there is no translation on the message type definition, is there a way we can do that?

andrewbelcher’s picture

andrewbelcher commented

And it depends on Entity Reference?

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented
Status: Needs work » Needs review
StatusFileSize
new 1550498-12.patch2.54 KB
  • Added the line at then end of .module
  • Added entityreference as a dependency
  • I haven't added the translation because I'm not sure what the most appropriate way of adding it is. Message module haven't translated the strings in the Message types they've created.

The main reason for having this in Party was to enforce the convention of the Message type category being 'party_log' and the party reference field having one name.

Totally agree with all the follow-ups you suggested.

andrewbelcher’s picture

andrewbelcher commented
Status: Needs review » Reviewed & tested by the community

Yes, I agree with the framework going into party, but let's try and keep it at the really core common parts. We can always have a more advanced logging framework in Party Extras if we want to do more advanced or complicated things. Some of the follow ups I suggest may actually be more suitable for there (a kinda UI type module?)...

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented
Title: Start Integrated History Log of all stuff - Integrate with Message » Provide a framework for and Integrated History Log of all stuff (Integrate with Message)
Status: Reviewed & tested by the community » Fixed

Gracias Mucho!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.