Hi,
I need to create a social networking site with Drupal 6 (yay). As a social networking site, there is obviously a need for an "Activity log" of some sort. The Activity module had its last commit abut 4 months ago -- and judging from the issue queue, that's not because it's immaculate.
Then, I read this message:
I am not sure what "Content log messages" are. However, I was thinking: would a module that exports just:
1) A database structure
2) Rules integration to "add" a record and that's it
3) Views integration
...simply do the trick?
Basically, other modules already call Rules events (or, well, they should). So, the "glue" to connect these events to this module would be quite minimal.
So, I am wondering: does something like this exist already? Surely, it ought to!
Bye,
Merc.
Comments
Hi merc, I saw this
Hi merc, I saw this yesterday but wasn't sure how to answer you, as I not sure what content log messages are either. But imo, for whatever it's worth, I think it's a terrific idea. I'm already using rules heavily, and I think a generic solution to activity, rather than a specific one as activity is, would be very nice. This would enable activity log for all rules integrated modules. That would be golden.
Ok...
Hi,
OK, I have a provisional version of the module up. I haven't tested it yet -- I will wait for a few more responses, and avoid wasting time if the idea for some reason is not good.
Merc.
Would Views2 do this?
The D6 version of views can pull system messages from the db already -- I suspect that this could get you some (or even all) of the way there --
Unless I'm misunderstanding your question --
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Subscribing. FWIW, Notice
Subscribing.
FWIW, Notice Feed is the D6 equivalent of Activity, though with a somewhat weaker API. I would love a more robust version - and although I think that Views can do this, it probably needs some heavy configuration before it would work like the Actions module.
Notice feed + impressions
Hi,
@icecreamyou: Notice Feed is just an add-on module for the "friend" module. Not what anybody needs.
@billfitzgerald: The problem with using system messages is that they are not user-oriented. In a social networking site, you want to know 1) The user who did something 2) The "target user" 3) The node involved, if present. Then, you want to be able to view messages and filter them according to those parameters. The system log doesn't allow you this kind of granularity.
So yeah, I think an activity log module based on Drupal 6 is indeed important.
I am thinking of releasing it. However, with Drigg, User Karma, Extra Voting Form, and now FriendList, I am getting a little overloaded. Especially since this hasn't attracted that much interest. So, I will need to see.
Bye,
Merc.
hi merc, I don't think a lot
hi merc, I don't think a lot of people use groups like this unfortunately. I don't think you should judge the interest from just this thread. I would think that everyone who is interested in activity would be interested in your module, as this promises to be a more integrated activity. I would definitely love to see this released. I hope more people express interest soon.
OK...
Hi,
@Miraploy : OK, good point. I am writing this message after successfully testing an activity log module written in less than 2 hours and... already fully functional! The module is 10 lines. Its rules and views integration "is" the module. And it works amazingly well. I am already showing messages when somebody updates contents, logs in, views contents... it's so easy, I just don't understand why nobody else has done it.
But, I am no social networking expert. The db structure where the keys are uid, target_uid and target_nid are the keys... well, that was out of my butt. I don't know if that's enough, and what admins will want to be able to filter things by.
Since this is another fundamental aspects of Social Networking, and since people keep on whining about the lack of this kind of features when they say that Drupal 6 is not ready for social networking (which is true, BTW), I would have expected more interest about this issue when somebody actually does something about it. That's all.
Merc.
Alright...
Hi,
OK, I have checked in the Activity Log module:
http://drupal.org/project/activity_log
Please send your comments about this being a duplicate of "Activity" to sjobs@apple.com. The comment will be carefully considered.
The next obvious step is adding default views, and some default actions.
I am not 100000% sure that the current "views" definitions are enough to show user activity. Where it's not, activity_log_query($uid, $uid_target, $nid_target) will do the trick (although it will require some light coding).
I will probably make some general views and events available as I actually get to use the module.
Friendlist: ticked. Activity log: ticked. I now ought to have a rest.
Bye,
Merc.
Not quite a tick
Hi,
It might not be quite time to rest just yet.
One of the current limitations of Activity Log is that it can only have one target user and one target node.
Question: is this a real limitation? I have looked and looked, and haven't found a Drupal "action" which will involve more than a user at a time. However, as I said, I am no expert. And I consider Activity Log a first pre-version, just to see if "it can (should?) be done".
Bye,
Merc.
Suggested db structure
Activity_log
uid | target_id | target_nid | action_id
uid is obvious
target_id can be a uid or a second nid (reason below)
target_nid is the object being acted on
action_id would make this much more complex (I would be willing to help with development as you seem to have your plate full) but also increase the use case
The reason for action_id is to allow for clustering of the feed. This feature of Facebook helps reduce the clutter. eg. "Mercmobily is now friends with cridenour, Michelle, and 2 others. "
The reason I would suggest generalizing the target_id would be for cases where a user may post a comment on a node. At that point you have a node_id and comment_id and depending on the action_id, you could display the right message.
Thoughts?
IDs and commplexity
Hi,
We need to keep the structure sane and simple. "Simple" is the recipe for successful, functional modules.
I agree that it would be cool to have a cid (commend id) since it's such a strong part of a Drupal site. But here you are suggesting a structure which isn't clear when you look at it -- a target id which can be a node or a user, and a target nid. This structure also won't work in Views, where each field needs to have a definite purpose.
Plus, in the two available "connections" modules in Drupal, you can always add one user at a time.
Finally, your comment about displaying the right message doesn't apply, because the message is just text added by an action. The message is not "worked out" according to the data: the message is there, full stop, and then the data is there to help index things and find things.
Bye,
Merc.
Clarification
Well on second thought commenting could be handled by nid - so target_uid could remain the same.
And I understand that right now the message is just text added by an action. However, I suggested a change to allow the module to aggregate data. The ability to keep the log from becoming very cluttered can more than justify it in my eyes. Simple is good but a module requires useful functionality to really be considered functional. There are ways to keep this simple without limiting functionality.
Not following you
Hi,
Sorry, I am not following you.
If you are suggesting a way other than text messages, then I am sorry but that's not possible with the current design of the module.
Please work with the current structure of the module, and suggest changes. I am finding hard to follow your ideas. Please have a look at how Views and Actions work, and have a look at the current code if you propose structural changes.
I am battling Views with the current structure as we speak, and I am not even sure I will come on top. Any more complication will lead to the complete impossibility to create views with it.
Let me say it again: I am not sure this is the right way to go about activity. This is an experiment. Let's see if it works. It might well be that we do need an activity module after all.
Merc.
Views is more than capable
Views is more than capable of handling my suggestions. However, I am complicating things too much.
Good luck.
Wait a sec...
Hi,
Wait a minute. If you write that, it means that you must be really good at views -- which I am not.
Are you able/willing to help, if I send you the current snapshot of the module (which is finally able to see "what friends are doing") and the export of the view I am battling?
It does require the latest snapshot of token and views.
The problem I am having is that I am linking to friendlist_statuses like this:
This is way, way less than ideal because it restricts the join to the requestee_id.
How do I do this... the other way around? Maybe by defining a fake field and using 'handler' => 'views_handler_relationship', ?
Please let me know if you are willing/able to help!
Merc
I'll take a closer look at
I'll take a closer look at this tonight / tomorrow.
Definitely willing to help - hopefully able :)
Things have changed...
Hi,
Things have changed. Please have a look at my latest message.
I really think the different DB structure I proposed would actually work. I made up tons of use cases, and they all seem to work.
I am going to code it right now, since code is better than 10000 words...
Merc.
I'm interested
I've been out of town and am still trying to catch up. Activity seems to be stalled. If you were writing a whole new module that duped Activity, I'd be concerned. But this seems to be a whole new way of getting a user's activity leveraging existing modules and writing glue code, which sounds like a good approach just based on reading this thread. Not sure when I'll have time to give it a play as I have client work to catch up on but I'm definitely interested.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
OK...
Hi,
OK thanks.
Feel free to have a look at the current code and let me know what you think.
I am struggling with Views right now... ugh. It's hard. In particular, I really want to find a way to create a view to see "My friends' activities", and linking to FriendList's data through View is hard (Friendlist is currently the only Drupal 6 module that integrates properly with Views).
Bye,
Merc.
OK...
Hi,
In http://drupal.org/project/activity_log I give a first idea of what can be done. However, absolutely nothing is set in stone. The main thing is that the module this way has some limitations:
It's hard to have activities that involve multiple users as target. This is for 2 reasons: the first one is that Drupal as a whole doesn't seem to have actions that involve multiple nodes. The second one is the database structure of the module, that is inherently simplistic (and it should be).
It needs a Views master (and I mean, a master) to get the queries right. Seriously
So, MAYBE a better idea is to scrap half the idea of this module: not using Views, but still using actions. And not using text messages, but using meta-messages.
So, the main difference between this module and the other one is that everything is managed through Rules (events and actions) rather than a specialised API.
if I vote for 5 stories, I would like to see a message like "mercmobily voted on the stories A, B, C, D and E" in my activity log. Having 5 different messages is simply lame. However, I don't think the database should be any more complex than what I have explained. Instead, I think the aggregation should happen at presentation time.
Idea: we really do scrap views, and have the database this way instead:
uid_render - the rendering of UID
action_string - The string of the action
action_string_multiple - The string of the action if there are multiple objects
oid_target_type - Type of target (node, comment, user)
oid_target_render - Rendered target
timestamp
This can easily be done through Rules/Actions.
The output of the message will always be:
timestamp: uid_render action_string oid_target_render
For example:
23/9/2008: mercmobily has written the comment "OK..."
However, if I wrote several comments, rather than having this as output:
23/9/2008: mercmobily has written the comment "OK..."
23/9/2008: mercmobily has written the comment "Another"
23/9/2008: mercmobily has written the comment "And another"
The output should be:
23/9/2008: mercmobily has written several comments: "OK...", "Another", "And another"
This can be done because at output time the system checks if more than 1 record has the same uid/action_string/iod_target_type -- if that's the case, it groups the target_types together.
Does this look like a sane way to go? Or, do you see major faults/pitfalls in this?
I think it might work. The changes to the Rules code would be minimal. However, the "views" idea would basically die, because there would be some serious processing involved (well.. actually, I am not sure. Maybe a "views" guru could well handle this?
Bye,
Merc.
This is exactly where my
This is exactly where my thoughts were headed. Having the same action_ids would accomplish the same as your process of acting on the same oid_target_type.
To be completely honest, as long as we provide blocks (and probably Panels integration) there is no need for views - though I believe it could be done through a handler. I personally don't see the use case.
I'll definitely be interested to take a look at the code later tonight.
Views wouldn't work for this
Views wouldn't work for this AFAIK but it definitely sounds like a useful structure. But to throw in my two cents here, I'd like to see a way to expose this to UR/Friendlist/etc. - so for example you can see messages about only your friends. I don't think it would really require different messages - like how activity has different messages for different relations to the person who did the action - but I do think that some kind of filter on which messages to display would be nice. This is also applicable to OG - for example, most of the time you wouldn't want users to see messages about posts in a group if they're not in that group.
I agree
Hi,
I totally agree. I think the way to go about this is to have a hook system where other modules can throw conditions to the data being displayed.
Or... "something like that".
Initially, it will definitely work with Friendlist, and I will tell Alex what to do so that it works with User Relationships as well.
I am staring at the main query function right now, let's see what happens. It's a bit of a pain, because the target can be a comment, a user or a node. This makes the query a little harder to create.
And yeah, I have given up on Views. Integrating this with views only makes sense later, when we know that the data is going to stay the same. And, it might be impossible to actually integrate it with Views. Possible or not, it's not something I am gonna torture myself with...
Bye,
Merc.
Update
Hi,
Here is an update.
The idea above actually seems to make a lot of sense, and it seems to be functioning. I decided not to go to bed until I had "resolved" the issue of Drupal effectively lacking a functioning, well-integrated activity module. But, it's 2:57 and it's a little late.
I scrapped the idea of the "rendered" fields -- not sure what on earth I was thinking about.
I am writing now the function that queries the current activity table. After that, I will write the function that "optimises" it (as discussed above, "merging" multiple entries). After that, all that's left is a theme function to render it... and the module should be at least usable.
What I am planning on doing tomorrow (although it's already tomorrow) is a nice way for friendlist-like modules to hook into the query and filter things out so that you see "your friend's activity". This is the neatest, and most important, functionality that we need.
A Views integration is not excluded. However, I am not the person who's gonna do it -- and I am not even sure it would be beneficial. The real strength of this module is in Rules, which can log pretty much anything, and the idea I had about optimising the messages.
If all goes well, Drupal might end up having a working Activity Log module by tomorrow.
I realise that some of are in the wrong timezone or busy with other things. However, I am for getting things done. And it can be a little hard catching up with me... Marius, the only tester of my FriendList module, knows this well :D
Bye,
Merc.
On views
I asked merlinofchaos to take a peek in case he had any quick thoughts on views integration. He says:
"My guess is that he needs to set it up like the statistics table is set up; which is its own base table that includes a relationship(s) to the user table."
I haven't dug into views code at all for D6 so I'm no help but I thought I'd pass that on in case it sparks any ideas for you.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Update...
Hi,
I am pleased to announce that I have a working version of the Activity Log module working.
The input here was important -- thank you cridenour; I know it might have sounded like I didn't wanna hear from you, but I was in the middle of the most frustrating time with Views...
Right now:
there is no "action_id". This can be done... but I think it would be a level of complexity that is simply not needed. I might be wrong, obviouslt
there is no "views" integration. Right now, I am trying to figure out what the best db structure is, and writing a function that covers all of the use cases. Then, Views will have to/need to replicate that function's scope. I won't be the person doing it. However, a Views guru will have a clear idea of what we expect from it
I will upload the code in 5/6 hours, when I have a working version going.
Is anybody still listening BTW?
Merc.
>> Is anybody still
I'm following quite closely. This module will rock when it goes live.
Brian Vuyk
Web Design and Development
Long Sault, ON
http://www.brianvuyk.com | brian@brianvuyk.com
(613)534-2916
Brian Vuyk
Senior Developer, PINGV Creative
bv@pingv.com | (315) 849-9733 | Skype: brianvuyk
Still listening
Still listening but waiting until it settles down to try it out.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
I just noticed...
Hi,
"I don't think it would really require different messages - like how activity has different messages for different relations to the person who did the action"
Ugh. To me, that's a sign of a module that has tried to go waaaayyy too far in terms of implementing feature requests that should be marked as "won't fix" or "by design".
Merc.
Update
Hi,
Here is an update on the status.
I am getting there -- although the end is a little further than I expected.
As it turns out, the database structure does need two tables. one for the action, and one for the targets.
I am rewriting things now to fit the new db structure.
However, a lot of what's been said still applies.
Basically, this is becoming an activity module based on Rules -- and using a custom Rules action so that things are recorded "the right way" onto the database. Right now, I am writing it without Views support, because I need to come to terms with the DB structure first. However, I am keeping Views in mind while programming it.
Bye,
Merc.
Together with
Together with activitystreams.module, this will make drupal catch up friendfeed and facebook, I have a vision. Thanks for the hardwork.
laught, light n laughter
Its sounding like you are
Its sounding like you are making a lot of progress. Its hard to collaborate because of the timezone difference but feel free to post what you have even if its just "working" so we can look through and help decide on the best path (if this isn't it - its really up in the air at this point) and really hammer this thing out in the next few days.
:)
OK...
Hi,
@cridenour: OK. I realise it's hard to help out... especially with 700 lines of code per day. However, it's not a matter of time difference since I am working on this non-stop, and am stopping for sleep breaks at more or less random times.
@michelle: OK
@everybody: please keep in mind that this is an experiment. It's meant to show how a glue module could possibly be implemented. To start with, I will have an API function to list results and some blocks, so that people can actually see how the first half of the integration (and the most important one) with Rules has worked out.
I am now finishing off the themes functions so that everything is nicely broken down. After that, I will do the 3 basic blocks, a rough Views integration, some documentation to the code... still a fair bit to go. It will be done by tomorrow.
Bye,
Merc.
Update - remaining items
Hi,
The experiment is going well. In fact, it's very very nearly finished. I committed what I've done. I am now going to take a big rest.
Here is the current TODO list:
user->uid == $user_creator
Please note that this whole module is about "Can this be done?". That's it.
There are about 10 hours worth of work to do. Whichever way it goes, I think this module is a fantastic testbed to see if gluing can work for this particular case. And in any case, I will be using this on my own site. So, I am happy either way.
So, one day to go, and I will take a long coding holiday... (I will still debug/patch/support, obviously. I will just stop writing 750 lines of code a day...)
Bye,
Merc.
Thanks for all the effort
Thanks for all the effort here, Merc! It looks to be shaping up well...
A note about the activity_id - sorting works better with a serialized field than a timestamp because on large sites users often submit things at the same time. (Think about it - there are 60 * 60 * 24 seconds in a day - 86400 seconds - and if the site gets 200,000 views a day and 10,000 posts a day there's a fairly high likelihood that a lot of posts will end up with duplicate timestamps. Not that the order matters that much in such a case.)
OK: done
Hi,
OK, done.
The module is done, and it seems to be working.
I added a comprehensive README.txt file. Please have a look.
Once I get some feedback from here and Lapo and , and IF I don't decide to kill it based on the feedback, I will make a general announcement to the general forums to see if others are interested and if this can be "it".
As I said, it's a "test", it's a way to see if this can be done... so let's see what happens.
Bye,
Merc.
I have actually used
Actually, this is already supported in the latest module. We are using the worklfow-ng logging module also for this in my company. The logging module needs still to be ported to rules 6.x - the idea behind this module is to provide a generic log mechanism for data objects like node and users.
I wonder what's the distinction to your new module is, mercmobily?
For rules I furthermore plan too look into this open questions
* Is there a way to write it in a generic way, so that even more data types are supported? (comments, ..)
* Make log messages translatable in the UI - for this we need to change the token replacements handling.
* Is it useful to have multiple related data types per log messages or does one suffice? Is there an easy way to implement this?
So if you or, someone wants to help porting it, help is of course really welcome!
Answer
Hi,
The "Activity log" module is not a generic module to log system messages. Is a module that focuses solely on the Social Networking side of this.
The database structure reflects this. The way things are logged (or not logged) reflects this.
Please read this file for more information:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/activity_lo...
I will be very open to discussion with people about this very topic ONCE they have read this README.txt file very carefully.
About this question:
In Activity Log, which I repeat is an experiment, I have a simple way to deal with that. Have a look at the readme file, and the source. The source is extremely clear, and with no trickery what so ever.
Merc.
hm, if a generic module can
hm, if a generic module can do it, I prefer that.
From your readme:
Why a generic module won't cut it
Recapitulating I can't see why any social networking related improvements can't be implemented for the generic module - so I don't see why another special module is needed.
Decisions decisions
Hi,
"I can't see why any social networking related improvements can't be implemented for the generic module - so I don't see why another special module is needed."
I disagree. I see a lot if "This could be handled by a generic module" in talks. However, I see very, very little practice. The problem is that when you try and solve a very specific problem with a very generic module, you end up either with an over-complicated generalised solution, or a crippled specialised solution -- or - very often - both.
I don't think a generic module will ever ever cut it. I think if you read the code of "Activity Log", you would see how so much code focuses on dealing with the social part of it. Since I don't think a generic code would cut it, I am not going to be the one writing it.
*** However, I would love to be proven wrong. ***
In the meantime, we need to decide if we should keep Activity Log in the Drupal Project repository or I should pull it and only use it for my own site(s), while somebody, IF I am wrong and IF has the time, comes up with a generic module.
Comments are most welcome.
Merc.
P.S.
Hi,
Fago, please have a look at the source code of Activity Log as well, to see what gets done in terms of theming and with the INSERT into the database.
Merc.
I would suggest keeping it
I would suggest keeping it in the Drupal project repository.
I do think that if a general solution could be made available that handled the social networking usage well, it would be a better way to go than a specialized solution.
However, since such a general solution is not available at this time, I think it is important that this module be made available to fill the need for a good activity-tracking module. Especially if it is as useful as it sounds from a read of this thread.
Good work merc - I look forward to having an excuse to test / use this module!
Brian Vuyk
Web Design and Development
Long Sault, ON
http://www.brianvuyk.com | brian@brianvuyk.com
(613)534-2916
Brian Vuyk
Senior Developer, PINGV Creative
bv@pingv.com | (315) 849-9733 | Skype: brianvuyk
The only one problem...
Hi,
The only one problem I have is that I might end up in a circular conversation like this:
(BTW, [somebody] != fago or anybody in particular. In fact, [somebody] changes over time )
[somebody] Why did you write a specialised module?
[me] Because I felt it was needed
[somebody] Why didn't you port the existing general logging module?
[me] Because I didn't think it it would actually do it
[somebody] You are wrong
[me] Fine. Prove me wrong. But I am also free to work on whatever I like
[somebody] You should work on what's good for the community
[me] I should work on whatever I believe is the right way of doing things, and whatever I find right and fun
[somebody] You should have ported the general module and patched it
[me] I don't think a generic module could do it, this is a social networking iss-
[somebody] Yes it can
[me] Fine, show me
[somebody] People now won't improve the generic module because they will use yours
[me] Well, if mine is there...
[somebody] Because if you, now there is just confusion
[me] So the fact that now there IS a social networking activity glue module that does the job is irrelevant?
[somebody] You should have patched existing code
[me] I didn't think there was any point in patching a general purpose module since I didn't believe that a general purpose module could do it
[somebody] You are wrong. You should have tried
[me] I need to actually get things done and create modules that do one thing well using existing infrastructure and integrat-
[somebody] No, now all you did is create confusion
And so on. Now, repeat this for a long time. 6 months on, the generic module is not there, and [somebody] blames me for the lack of it. The circular thing begins again.
Now compare this to:
[somebody] Why did you write a specialised module? It's wrong. You should have improved the existing one
[me] Great. [I pull the module, my users on the sites I run have a great activity module, 1 year later people are still trying to figure out a way to get a generic module to get user activities like the one on Free Software Magazine]
What Activity Log needs is people believing in it and using it. It needs a decent Views integration (the basics are there, bit I am not good enough at Views to go far). I believe in it enough for using it myself. But I have 0 energy to fight [somebody] . I have a life as well.
So, right now I am leaning towards pulling it, emailing it to people who want to use it, maybe put it in my sandbox rather than repository, and wait for the "generic" one to come by. If it comes, great. If it doesn't, in a year or so, I will come back and if there is 0 resistance, then I will add it.
I don't want to be begged, BTW. I just want to try and do what is right for the community. I got enough crap for writing FriendList and not get User Relationship's maintainership. Once is enough.
Merc.
.
"Pulling it" is not an option. You created a project, you put the code in CVS, you released it to the community as GPL. You are free to abandon the module, of course, if you choose not to continue but you can't rewrite history. CVS doesn't forget.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
If it makes sense, pulling is actually an option
Hi,
A project with 0 users and 0 releases can be pulled on the basis of "I am an idiot I shouldn't have published it" -- which is the case here.
From my comment: "maybe put it in my sandbox rather than repository"
So, it's clear that I am not being precious about the code itself. I am being precious about not wanting to be the maintainer of an unwelcomed module.
Plus, I might well be wrong. It does happen. I fully trusted two girls who promptly dumped me for a random guy, and I could have sworn by them. As I said, this is an experiment. So, if Fago/anybody can use the module as a template, or as a "feature reference" to see what the specialised module should be able to do, I am also very happy.
I just want to see if as a published project it makes sense.
Merc.
merc, You wrote a good
merc,
You wrote a good module that filled an existing hole. Until it's proven that this could have been done with a general module and implemented, than your module has a lot of value.
You don't have to debate people on whether you should have done this with a general module or not. You wrote the module in the only way you thought possible. That puts you one up over anyone who argues you did it wrong, but won't put their code where their mouth is.
Leave the module up - it will get a lot of users. And if someone does try to argue that you should have done it different, invite them to code up a better solution.
Please don't pull this - it has a lot of potential.
Brian Vuyk
Web Design and Development
Long Sault, ON
http://www.brianvuyk.com | brian@brianvuyk.com
(613)534-2916
Brian Vuyk
Senior Developer, PINGV Creative
bv@pingv.com | (315) 849-9733 | Skype: brianvuyk
Don't pull it
Going through this whole thread really late but I feel like you need a little cheering...
If you are doing something that you can't find any other way to do then we are all very grateful that you are sharing it with us (I certainly am).
For those that are criticizing without showing the goods, let them criticize... one day they will use your module (yeah to you) or do it on their own without sharing (shame on them) or do it on their own better and share (then you won't have to support your module to get the same functionality, good for you !).
Chill out man, you're providing some incredibly useful modules to the community and they are proving to be top quality.
Why would you ever try to
Why would you ever try to get a module removed from d.o.? You can abandon it if you want, but you should always leave the code there for someone (in this case, a lot of people) who might need/want it - especially while there isn't a generic solution. If you think people will end up using a different solution, just say so in the description.
Besides, I appreciate the specificity of modules like this one. Often it's easy to end up with gigantic monolithic modules that suck the resources of a site but aren't terribly useful for a specific need. Views is one example - its source is probably one of the largest single downloads in all of d.o.'s CVS, but it can be relatively easily replaced with custom code for anyone who knows enough to write SQL queries. When have, say, less than five views, you don't really need all that extra code being loaded so frequently; and the backend can just get in the way. (Not to criticize Views in any way - it's one of the best modules out there. It's just big.)
I missed some of your answers
Hi,
You included some of the answers within the blockquote tag... I had missed some of it.
Sorry, my bad. When I say "we need to know", I meant "we need IDs". I realise that we can have any message we like. However, Activty Log has target user ID and target object ID in separate fields. This is crucial to know in a social networking scope -- but hardly useful in a generic system logging scope which just aims at logging what "what happened".
Why is it crucial? Because you have to make queries about both who did the activity, and who/what was affected by it.
No, I don't mean grouping by category. As I explained in the README.txt file, I meant that if the same activity is repeated and just the target has changed, and if there haven't been too many targets connected to that activity, and if the new activity has happened close enough in time to the previous one, then a new activity shouldn't be logged -- instead, the targets should be added to the previous one. (I'd read this sentence 3 or 4 times in order to "get it"...)
This is what I mean by "grouping", so that things look like this:
Joe voted for the stories: "one", "two", "three"
rather than:
Joe voted for the story "one"
Joe voted for the story "two"
Joe voted for the story "three"
You can argue that the module should just log things in a flat table. I very nearly made the module that way. That is, rather than having two tables: one for the activity, and one for the target(s) connected to the activity. The presentation layer should then load the table, and check for repeated fields itself. However:
It's a hugely un-normalised database structure. Dangerous.
The presentation layer is much more complex. Finding duplicates and grouping things up starting from a flat table is not as easy as it might seem
If you want 10 lines of activity exactly, and you have 4 repeats, you will end up with 7 actual lines. It's hard to impossible to basically query the database and know in advance how many activity lines -- after grouping -- you will get. This might not seem like a big issue, but I think it is.
It just feels wrong
Sure, but this is hardly the issue here.
Hopefully this post will shed some light...
Merc.
For Fago: also...
Hi,
I just want to make sure that I am trying my best to give you the compelling reasons why I think this needs to be handled by specialised module.
I am very interested to see if my reasons convinced you. Please let me know -- I am very interested.
Merc.
Please give it a try...
Hi,
Alright, please give it a try and let me know if it's actually worth it!
Merc.
It's hard to impossible to
It's possible, but it involves some creative subqueries. By the time you have enough subqueries to make it work, you're better off using two tables anyway - or loading the entire table and limiting the number of results in PHP, which is a terrifically suboptimal choice.
Will have to delay testing as I'm very busy ATM, but I've already talked to a few people who are interested.
For cridenour...
Hi cridenour,
Did you get a chance to read the README.txt file?
I am asking because you had the "Action ID" argument there, and I am very curious to see if my "verb + action" idea fully convinces you.
Bye,
Merc.
Merc, I will hopefully get a
Merc,
I will hopefully get a chance to read it tonight. I am actually going to a Drupal meetup here in Cincinnati and I'm going to pick their brains on this matter. Will post their thoughts and mine after.
Thanks,
Chris
OK...
Hi,
OK. Please keep in mind that this is a subject where often "theory" and "practice" don't match :-D
Please have the README.txt file handy...
Merc.
merc After reading readme
merc
After reading readme and looking a bit at the code, I can say that I will agree that action does add a lot of complexity. The only way to find out if it is necessary complexity is to wait and see what people want to do with the module. It seems great in its current form so lets definitely continue along this route. I won't be able to sit down and code until the weekend but I will hopefully be able to contribute to the views integration then (if its not already done by then).
Thank you!
Hi,
Thank you so much for your encouraging words. I think a good route is to get this module out. Then, we'll be able to adjust it for version 2.
As of Views help... PLEASE! I must say there is no way on earth I can get it done. I mean, it would take me 5 days full time, whereas it would take a lot less to somebody who actually knows Views :-)
Thanks,
Merc.
Activity rise again
http://drupal.org/node/314433 looks like new branch
Merc maybe you join forces with activity?
Doubt it
Hi,
The current Activity Log is a glue module. It works in a completely different way, and it doesn't need any specific integration.
It also has a much saner db structure.
Finally, the maintainer interrupted communication with me about what to do half-way. Next thing I knew, he restarted working on it.
I think I want to at least see if an activity module based on glue and a simple db structure would actually work for people. I am using for an internal side right now, and it's fantastic. However, as I said, it's an experiment and I am not precious about it. So, if it turns out that a glue is not what we need, I'll pull it/whatever. Activity Log right now should be in the sandbox -- I was silly creating a project for it.
Bye,
Merc.
Silly?
Why are you think so? You share code with community maybe someone find it useful for some custom project... Or you just wanna drop support for it by moving to sandbox?
Notice project also log user's activity but on it's own way. Your code is MUCH better! so, please, do not drop support for activity log....
I probably won't, but we'll see
Hi,
I probably won't, drop support, but we'll see.
Bye,
Merc.
Keep it up - enforcements are on the way
Hi merc,
I would definitely keep up this good work.
After reading the whole discussion - but without reading the current code - I'd put in two comments:
In the next days/weeks we'll be defining precisely what we need (in two upcoming projects) to build what we call a "heartbeat" module.
I can give you the short version already:
The heartbeat shows recent activity in the community.
Two flavors:
Message creation: what activity to pick up in the site?
Sentences & grouping
From all rules expressed above, I would softly conclude
So, that's shortly what we're up to in the next weeks.
I'd be happy to share you the details of this part of the project, and to collaborate, since you seem to have walked already a long way on this route.
Wimmmmm
Wim Janin
Drupal Tech Architect
ONE Agency
My humble opinion
Hi,
OK. A piece of advice: don't over-engineer it. I think the current "Activity" module suffers of that problem. I think we need to keep things very
OK.
OK
This is currently covered by Activity Log.
Working out what you want to log beforehand is a losing battle. Activity Log is based on Rules, which means that you can pick on
Here it gets interesting.
OK. Having a "added 7 pictures" will require an extra field in Activity Log: a flag that tells the module that you want to count.
OK
That's just the formatting of the timestamp...
OK.
OK, this is starting to look like a bloodshed now.
I think the secret to make an Activity module work is to follow the KISS principle: Keep It Super Simple.
This requires some compromising in terms of results.
I am looking into the OpenSocial API right now. I will make sure that Activity Log is totally fine to work with it. However, I am dead against the idea of "tokens", "meta messages", etc.
Don't get me wrong. I designed it that way. Then I looked at it. Looked at the ramifications. And chucked the diagrams in the bin. (That was a fun night.) And then sat down and re-designed Activity Log the way it is now.
Verbs do work well and cover a good 98.8% of cases. The remaining 1.2% can be accommodated with "language hacks" -- if you really need those messages.
It's also quite possible that you will be able to design such a system with tokens, meta messages, etc. If you are, please do so by any means. The Activity Log source code will still be of help. But, I will personally focus on enjoy my personal programming time by creating a simple way of creating such a module, and will join forces with people following the same philosophy. (We have to work in something we believe in after all)
OK
I thought about the multi lingual side of it. I feel that can be done easily with the current Activity Log design with t() and with theming. If you do have a multiligual site, you will basically need to create a theme function for the sentence that will take care of that.
Again, Activity Log allows that. But, some might find it too ugly that way. Plus, it hasn't been tested in real life.
thing is, most sites are not bilingual. The increase in complexity in having a meta system to store sentences which are then translated etc. is tenfold -- and that's for everybody, not just people with a multilingual site. So, my feeling is that if you really want to have a multilingual site with translated activity log, you just need to deal with that 10x complexity -- at theme level.
OK.
In the end, I tend to agree. Views doesn't seem to cut it in this case.
This is what I'd do if I were you:
Download Activity Log and study the source. It's immensely commented. Plus, the readme explains everything you might want to know about why it works that way
Download "Activity". They seem to follow more the ideas you talked about above. The code is not as easy to read, and that's partially because it's a lot more complex than it could be in my very humble opinion (Note: I briefly talked to the maintainer when I started developing "Activity". He then disappeared -- and then development for "Activity" commenced again. I guess I motivated development, which is a good thing.)
At that point, it will be up to you. Starting yet another module would probably get a few people frustrated. (Although, if you design something that is MUCH better than Activity Log and Activity, and if your code is good, then you might make everything else obsolete). The ideal situation is that you join either Activity or Activity Log -- I hope at least one of them fits your requirements.
But, Activity Log will always be simple. With trade-offs, but it will work, will be good for OpenSocial, will not have strange bugs due to its complexity.
Bye,
Merc.
enforcements are on the way ...
Hi,
I totally agree to join one of the modules. I think activity is rather complex for what it does and activity log has a too little logic to fit our needs (I work with Wimmmmm) . We talked yesterday on IRC and I will certainly look in both modules. As i said yesterday, I really believe in your concept with the logging and combining everything through trigger rules and actions.
As you might guess , we need all features Wimmmmm mentioned above, so "The ideal situation is that you join either Activity or Activity Log" is a good idea.
most thankfull greatings,
Stalski
Another possibility...
Hi,
Another possibility is that you are totally right. I feel that the current Activity Log module would actually be a good starting point for you anyway. It does a lot of what you mentioned. And if you do get further -- that's great.
One thing worries me: you have a list of strict requirements (I guess paid for) and they are quite ambitious. However, I feel that they might be an overkill for most Drupal users. I don't know how dedicated you are. So please don't take offense at all. However, my fear is that I abandon Activity Log, and then one of the following happens: 1) You never finish your module 2) You finish it but it's way too complicated for most Drupal users 3) It's a nightmare to configure. I am NOT saying this will happen, or that I believe i t will happen. I am just saying that maybe it's worthwhile keeping a low-profile, simple activity_log module (which is basically finished). Then, if/when you complete it successfully (which I think you will), we can either kill activity_log with an upgrade path to yours, or... well, see what happens.
What I don't want, is Drupal to stay without a working activity module for much longer (Yeah, Activity's development has recommenced, but it's not there yet).
Having said this, it's also quite possible that you guys might actually join "activity" advance Activity and push "activity_log" out of existence. Again, that's also a possibility. In the meantime, however, I'd like to give people the option to use/have activity_log.
Bye,
Merc.
Hi merc, I'll indeed have a
Hi merc,
I'll indeed have a look via stalski into the code.
And yes, we have a list of rather strict requirements, for paying projects, and right now I have pretty much the same set of requirements in three projects, so we need to make a general solution, that works for those 3 cases. Benefit is it will be thouroughly tested, and in Belgium/europe we need multilingual support right from the start.
We'll decide internally what the best route will be (taking all good ideas, starting from one or another module, or else).
I just wanted to share this with you, so you'd know, and you'd also be able to decide how you want to combine forces or keep your work clean & targeted - it's a free world.
I'm also very interested in your OpenSocial efforts, and where it would have an impact on features of an activity module.
To be continued!
Wimmmmm
Wim Janin
Drupal Tech Architect
ONE Agency
Sounds promising
Hi,
Your message sounds really promising. I will be delighted to come and help if I see that I will have fun programming the beast.
There is no doubt that the potential we would have together is way more than us singularly.
I halted development of "my" activity log (which mind you is still an experiment blah blah) for the exact reason you mentioned (kudos for the intuition): OpenSocial. I am waiting for those guys to finally release their Shindig integration module. At that point, I will work with them to figure out what information they need in terms of "activities" (and, especially, if shindig needs to add activities). This will indeed change the way the module works. I might discover that my idea is a pile of poo, or that your idea will never work with OpenSocial, or that they will both work, or whatever.
In any case, let's keep in touch. You sound like fun to work with, and communication is flowing freely which is a huge plus.
Bye,
Merc.
Also...
Hi,
Also, if we could find a way to get activity_log to use "tokens" (brrrr bloodshed fear) in a meaningful way, and still use Actions for interfacing with it (which would be a huge plus), maybe you could just explain activity_log a lot and get it to work "your way".
Bye,
Merc.
A great outcome of this
A great outcome of this would be to have Activity, Activity Log, and your upcoming module result in "the one solution to rule them all"
It will take more time at the outset to coordinate efforts, but the end result would be code that had broader community support, which would lower your maintenance hours over time.
And, if it's not possible (ie, a module maintainer continuously refuses to respond to issues in the issue queue) then you can point to those issues where you tried to establish that collaboration.
FWIW the functionality you want to build sounds very useful; but, if it falls into the nether world of YASNM (Yet Another Social Networking Module) its rate of adoption will be lower than it needs to be.
Please, please, please, take the time to work with the existing codebase -- it will benefit the community (less duplication) and your module (greater uptake, broader community support).
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
There is actually no existing codebase...
Hi,
Right now, there is "Activity" and that's pretty much it.
It's a module that is waaaaaaaaaayyyyyyyy overcomplicated, buggy, and incredibly hard to read. My autistic brain says "I can't patch this". So, I won't. Plus, I feel that the activity module needs to be gluish, simple, and straight to the point.
There is also "Activity Log", which is an experiment, really.
And now there are other guys who want to write something that seems to be half way between one and the other. However, some of their requirements really worried me. The risk is that they end up with something as unmanageable as Activity. They are talking about "meta messages" -- I might be wrong, but my autistic brain says "bloodshed" when it sees that.
And that's the thing: right now, myself and the Activity people have very diverging ideas on how the Activity module should be build. I am for 1) Simplicity 2) Glue 3) Existing modules.
My goal now is to try and explain clearly what my ideas are. However, the risk is that we end up with three modules: "Activity" (the one that is in my opinon overcomplicated etc.), Activity Log (which is an experiment) and this new module. I can try and persuade them to join one or the other, depending on which design they believe is the way to go.
Or, offer Activity Log as the basis for a new module which will kick everybody else's butt. That would be great too.
Bye,
Merc.
I am half asleep...
Hi,
Sorry, I am half asleep.
I just realised that your message wasn't for me.
"mercmobily, the world doesn't revolve around you" (repeat three times).
Anyway, I agree. One module that rules them all would be grand. I hope we'll get there.
Sorry,
Merc.
Who are the other guys : heartbeat ?
Merc,
are you refering to project heartbeat at http://drupal.org/project/heartbeat ?
If so, now that they have released some code, can you tell us whether you will indeed "forking" or not ?
@billfitzgerald Great
@billfitzgerald Great advice! I've been following this thread, and the idea is intriguing. It's very important, IMO, to take the time to look around, and try to collaborate with what's already out there. Now that activity development has resumed, it would be really great if your efforts went into making it fill your requirements, Merc.
i say join force
I say either the hearbeat or activity_log maintainers join forces and create an activity module that can be multilingual "as heartbeat module" and with clean clode "as activity log" that way we don't have multiple modules basically working towards the same concept which is social activities. I am for one like both features on these two modules and I hope that both can collaborate on a single module as "activity module" is not cutting it for most, otherwise there wouldn't be two new activity modules in the works.
thanks mercmobily & Wimmmmm for your contributions.
bending technology to fit businesses.
Refresh?
Hey all,
Coming late to the party thanks to a post to the devel list...
I'm just wondering the state of things vis-a-vis heartbeat and activity_log. Looking to implement something and was going to start from scratch, but it looks like there's a lot of work here.
I'm just curious if/how the two modules have been reconciled.
http://www.chapterthree.com | http://www.outlandishjosh.com
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Activity
I don't know about the status of those, but the Activity module has come back to life since this was first posted and is shaping up to be pretty nice.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Activity streaming modules
Hey all,
I started the heartbeat module about a year ago and kept working on it untill now. This module was made through specifications that were set up for a number of clients we worked for at that time.
One of the biggest problems for the heartbeat module was that it was a proof of concept and you could even tell this by looking at the code. I did not have a goal then, so the module could do too many jobs and had too many responsibilities.
This is all fixed in the new release. Heartbeat has become an API to log activity that can be displayed by heartbeat itself, views of by custom code. All other functionality is provided by an other contribute , and maybe with a small module to add integration to collaborate.
I am telling this because i just came across some more of those modules, doing exactly what heartbeat does.
First thing what I am going to do, is talk to those developers and try to work out a collision of functionality. For me personally, what i like best in those community sites, is that they merge messages together depending on criteria. I have put this functionality in heartbeat and can not find any other module that does that same thing.
So conclusion for me is: Even if heartbeat must go, I want keep the message group functionality as you see it on facebook, netlog, ...
regards,
Stalski
The Activity2 module (read:
The Activity2 module (read: DRUPAL-6--2) has been undergoing some major developments for a little while now. We're about to launch a site with it and will be having our first release soon after (deadlines are tough). @drewish has also been doing some review lately and posting bug reports and patches.
One of our goals has been to come up with a way to be able to merge messages together depending on criteria. It hasn't been a huge priority and will most likely wait until we have some more time to do more work on it, but is definitely something on our plate. I'd love to see how you've accomplished it with Heartbeat (if I'm reading you correctly). It's def a killer feature :)
I would love to talk about
I would love to talk about how Heartbeat merges messages. The concern with how I remember it did it and the current way Activity2 works is incompatiable. This is because Activity2 allows the users to create Views rather arbitrary. So knowing at record side if a message should be grouped depends on the Views enabled. So each 'message' would have to have a View ID on it so we could say this View is for this message. And of course that gets messy.
For a good example. Lets say we have 2 Views. One is a combined this is what I have access to view. Its the all activity that happens with my friends on nodes that I can view (read node_access('view') passes). Now I have another View is this all my friends activity on photo nodes that I can view.
So each 'View' needs to have separate rules on grouping.
This is just one problem. I have a couple more at home.
It feels really difficult. So difficult that I think my recent whiteboard solution was sort of a cache. On cron calculated the group messages for each View and put them into the messages table. And that I don't think I will ever do, cause thats ugly.
Views provides built-in
Views provides built-in arbitrary grouping on any field (in the style settings, for field-based styles) so I assume it wouldn't be terribly difficult to do almost the same thing with an Activity style plugin. There's even a code comment:
Plugins may override this method if they wish some other way of handling grouping.Is this one still ON?
I've been looking for a decent module to log activities on my site for a higher-priveledged role's purpose. I've stumbled upon the Activity Log module and realized it's horrid (the current dev release that is). I scrapped most of the code and reworked the parts that I preserved. I basically built my own module to handle logging which was based not even on Activity Log, but rather on the things I learned from it.
My three questions are:
1. What happened to the advanced DB structure that was supposed to be in the module? Was the idea of grouping logs scrapped altogether? If the code is still somewhere I would like to try to merge my solution (IMHO better than what currently Activity Log is - it's production-stable) with it and maybe (just maybe) release a semi-stable alpha with the advanced features, that were proposed here.
2. Is there actually any interest in this module?
3. Is Heartbeat or Activity a stable and manageble enough solution for me to switch to? From their project pages I concluded it's not, but maybe there's someone to convince me otherwise.
PS: I know I'm gravedigging, but hey! it's a noob's priviledge!
I'm actually interested in a
I'm actually interested in a "simple" activity-type module. I liked the simplicity that activity log was striving for. I also liked that it used rules to pull it all together.
I may look at heartbeat or activity again but they seem to be trying to do too much and the bug log is growing. I typically like smaller more stable/solid modules that let others build additional modules on top of.
-
@foggyperspectiv | foggyperspective.com (blog)
I would point out that the
I would point out that the module is Activity (drupal.org/project/activity) and its the dev for 6--2 branch. Thats where the advanced db structure lives.
It is not activity_log module
FYI, Message module has
FYI, Message module has Rules/ Views integration.
Activity Log revival
I'm bringing Activity Log back to life. It'll still be using Rules, but the one key difference is that it'll be generating nodes instead of maintaining a custom DB schema. This will make Views integration much nicer. For the details, point your browser at Offering to maintain Activity Log.
cool
Sounds really good, colan, I'm looking forward to checking it out in D7. :)
Shaun
but the one key difference is
Why not use Message that already does this for you, and provides Views/ Rules integration?
Doesn't use CCK
Looks good, but I'd like to use CCK so that the schema is easily modifiable. Also, it seems a bit heavy for my purposes. I really just need a bit of logging for Syndeploy. As it turns out, I've given up on Activity Log and the rest of these modules - I'll be rollilng this functionality into the bundle. See the module page for details.