Better decouple activity system from different features

Problem/Motivation

We have modules named activity_* (such as activity_creator) which form Open Social's notification and stream system. They should be fundamental systems that know how to route activities for the activity stream as well as notifications to various different delivery methods.

However, over the years we have added subtle things to these modules that require the modules to have knowledge of what features are using the system. This makes the system more rigid and makes it harder to change our stream and notification infrastructure.

Steps to reproduce

Proposed resolution

We should identify the places where the modules know about implementation details from features that use them.

For example there is the field_activity_entity field which is a dynamic_entity_reference → field. By default that field allows referencing any entity, which from a system perspective is what we want. However, instead we've added configuration to the field to limit what can be stored in it which means that we need to update our activity system for every new feature. We can remove this coupling by removing the configuration and allowing everything. If we really need validation of what's in there or if we need different behavior for different types then we can utilise Drupal's plugin system so that features can ship the parts of the notification logic that they need, but the storage layer is agnostic.

Remaining tasks

Below is a list of known issues, but investigation should reveal more.

• Ticket pending: field_activity_entity should allow any entity type so its configuration isn't dependent on modules
• Ticket pending: field_activity_recipient_group and field_activity_recipient_user should never be filled at the same time, so rather than being two entity references they can be a dynamic_entity_reference field for recipients; especially now that we have cross-posting and an activity might show up in multiple places. Idea: This might also show the difference between "notification" and "stream item"

User interface changes

API changes

Data model changes