Filtering activity types by site or node

[nickburch]

As most of you will know, Alfresco 5 introduced two new activity stream event types, Downloaded and Previewed. Kev's blog https://www.alfresco.com/blogs/kevinr/2014/10/14/configuring-alfresco-activity-stream/ explains more on it. Initially, it was a bit hard to filter out certain types, but Loftux (via https://issues.alfresco.com/jira/browse/ACE-3980 and https://github.com/loftuxab/alfresco-community-loftux/issues/17) have made it configurable on an all-nodes basis since 5.0.2

For most of our sites and nodes, people like getting the downloaded and previewed activities. However, for a handful, they don't want them. (Details in https://issues.alfresco.com/jira/browse/MNT-16237). We're considering trying to work up a fix for this, ideally one that stands a chance of being
accepted into core.

Based on the work done by Loftux, filtering really needs to happen at the time that the activity events are generated, rather than the somewhat tricky "at read time" approach from Kev's blog. However, if you're doing the filtering there, it's in quite a performance-sensitive bit of the codebase so you don't want to be taking too long on the decision. Well, at least not by default. That means that, in most cases, you have to make the decision from the data available in

ActivityPostServiceImpl.postActivity(String, String, String, String, ActivityPostEntity.STATUS, String, Client, FileInfo)‍

, so basically the Site name and the

FileInfo‍

of the chosen node.

My thinking was to add a new interface for filtering, which by default would take on the all-nodes type filtering that was added by Loftux. However, it would also optionally take a per-site and a per-node-type map of event type filters. (By aspect or site type would be nice, but that'd be slow so you'd need some sort of custom caching). Anyone who did need fancy filtering could drop in their own implementation of the interface.

Someone wanting to exclude all previews and download actions wouldn't change anything. Someone wanting to exclude all documents of type "private" could say "no to download, preview or edit" for the actions, but keep others. You could also eg exclude preview and download from a couple of sites.

It wouldn't be quite as "clean" as being able to pop an aspect on a site, or an aspect on a node, or tweak a site type to change it, but it wouldn't slow things down either.

Anyone have any thoughts? Any ideas on nicer/better ways to do this? Anyone from Alfresco want to comment on the likelyhood of a unit-tested patch for this being accepted?

[afaust]

Alfresco already has a concept that allows extensions to be easily plugged in: behaviours / policies. Similar to the copy callback policy, the activity poster service could provide an activity callback policy hook. Such a callback could then

- reject an activity entirely
- filter / augment data collected for the activity
- trigger additional activities (if relevant)

The callback for the policy would need to have an abstract API based on NodeRef (FileInfo is very restrictive, not everyone uses "only" files or folders) and the poster service would need to internally handle all the different API variants it provides to somehow be standardized on that policy API.
The only thing that may be needed is some way to alternatively bind policies not on the type of nodes but sites, either by preset (best practice for functionally grouping) or short name (e.g. special bootstrapped-sites).

But I may be biased towards adding a policy for this because I miss quite a lot of higher-level policies in various places…