Separate filtering settings for activity recording and display

I was playing with the idea of trimming the table on a per user basis on cron according to an administrator defined time limit in order to try to keep the activity table under control. It does become quite unwieldy on high traffic sites.

how about an activity archive table?

Plausible I suppose, I just have no need to keep activity that is more then either a certain amount of time ago, or just a certain amount of activity per user.

If others have a need to archive this stuff, then I'd say we should look into it.

I think there are a couple things we could do both upfront before activity and
afterwards after it's occurred.

This issue and a couple of others basically have been asking for toggles on
either or both node types and operations. I think that's reasonable especially
for node types where you might have admin/staff-only generated node
content that doesn't need to be highlighted as site activity. Toggling on the
operational level is perhaps a bit less important but I could see where a
site doesn't want to highlight content removal such as delete/unpublish.

then after the fact we can archive old activity if configured to do that or
just purge if configured to do that

I agree that the toggling would be helpful. In fact the first iteration of the activity module did just that, but then we switched to the API in 5.x-3 and lost that along the way.

I've thought a few times that the interface where you set tokens needs some revamping as well since this screen can become quite overwhelming when you're working with a site with a lot of content types and you're wanting to track node activity. This new interface should incorporate this toggling feature. I was just looking for a mock that I came up with can can't find it.

One patch to help with organization of token settings screen

#247394: Better Group of Token Settings

There are probably better ways to do this than my example
but in the pictures below I've mocked up an example settings
page that allows for activity type and activity operation
configurability per activity module (via flags set in the module's
module_activity_info array).

In the first screen shot you can see that the user can select
from a list of types and operations as defined by the module's
hook_activity_info implementation.

Then based on the choices of types and operations the fields
for setting the activity messages are shown per activity role
as in the second screen shot.

Pros: gets us more fine-grained options for generating activity
Cons: makes the interface more cluttered. Doesn't account
for operation settings per type.

thoughts?

Definitely an improvement. I think a lot of this could be done with AJAX so that when you check off the content type, the options change.

#10 yes the interface above would only affect activity going forward
and previous activity entries per node type and/or operation
type would still be visible.

sirkitree I think you were referring to your UI mockup
from #197481: Admin Interface Redux ??

I think... if this is possible. To have a token that says [no-show] or [disabled] and you just enter that into the messages that you don't want shown, and then it deletes it, or gives a class to the row to be hidden or something. then there could be a "[role:admin] blah blah" and it restricts the messages to just admins.

I'm really looking for this feature. Is there anyway that we can speed things up? At the moment the activity section is cluttered with useless and random updates. Is there a way to do this with Views perhaps?

Could those that are interested please try out a revamped
admin page here: http://drupal.qoolio.org

login: activity
password: acitivity

settings: http://drupal.qoolio.org/admin/settings/activity

There are perhaps still too many fieldsets taking up space
but this is an attempt at meeting as much of the module's
needs within the current design.

Please post followups to this issue.

Hey, I think it looks pretty sweet! Does that all work?

@jaydub: Big improvement! Great work!

@dkruglyak: If you want this functionality all you have to do is clear out the message box for that particular content type/operation.

I can.

You empty the text box for 'Delete' operations for
the 'Story' token type. You keep the text in the text
box for the 'Delete' operations for the 'Page' token
type. Repeat for each 'Role' in question.

if the specific field for that combination of activity and token
type is empty, it will not be recorded. at least that is the
idea that we've been trying to get across to you....

It's not very robust and user-friendly yet but you can do fancy
filtering of what activity to display as described in:

http://drupal.org/node/227846

Someday we probably need to allow for the creation of any
number of canned activity 'views' which can be used in
display. I haven't played with it much yet but I understand that
Views 2 is supposed to allow for tying in tables that don't necessarily
have any tie to the node table as is the case now in Views 1.

When will all of this be available?

Probably with the D6 port. And I'm not sure when we'll get that going.

Regarding #27, the updated admin pages as well as a number
of changes to the various contrib modules have been updated
a fair amount since the last release. I am in a very busy period
with my day job right now so I haven't been able to post what
I've worked on. I think it might be of value to post a short-lived
5.4 branch _kind of experimental_ and roll back to the 5.3 branch
when it's deemed stable. Otherwise I'm afraid a lot of people might
download a 5.3 -dev snapshot and fill the queue with issues for things
that haven't been documented yet...

The admin settings stuff can be done in D5 as it's just jQuery magic.

subscribing
(can help with testing)

The new 5.4 branch and the new 6.x branch have each contrib
module's activity settings displayed on their own page now reached
via the activity admin page admin/settings/activity. There are
checkboxes for each contrib module's activity token type and
activity operation types. When activity records are about to
be written a check is done to see if the relevant combination of
token type and operation type is enabled and only then is the
activity record written.

Note that you should not test this out on a production site as
many token patterns have changed and no upgrade functions
have been written at this point.

#314433: Activity 6.1 & 5.4

This is addressed in the new branches.