Feature proposal #8002open
Move system action behavior to core CB Activity
Instead of using CB Auto Actions to exclusively implement notification logging and other functionality move this to core CB Activity. This will be a simple on/off feature for several notifications. Creation of new notification behavior would still be done exclusively from CB Auto Actions, but default cases should be handled by CB Activity.
Updated by krileon over 1 year ago
The actual handling of the activity logging should just be in their respective plugins. For example CB GroupJive is already handling access and display of its activity and notifications then it should also just handle logging that information as well. CB Activity would still be responsible for core activity and notifications.
Basically once and for all need to determine who is responsible for what. This is a bit hard to determine as we want to avoid duplicate code. Having a simple and strong API in CB Activity that plugins then use would be the best approach. This means it needs to be extremely simple to create and log activity and notifications, which it currently is not. Basically plugins shouldn't need to deal with table objects and instead call an API against their streams directly, which will handle the table objects. Basically a more robust stream API that handles more than just display. Example as follows.
$stream = new Activity(); // Establish a stream
$stream->load( STREAM_ID ); // Load the stream we intend to use (this would be a param in GJ)
$stream->setTarget( 'group', GROUP_ID ); // Set the Target and Target ID
$stream->create( ... ); // This would handle creating a new post on this stream
Currently to create a new post you have to use an ActivityTable object directly and that should be avoided. Notifications are a bit trickier. For example if we need to push notifications to dozens of people we don't want to build dozens of objects in PHP to do this. We need to do a mass insert query. So we'd need to first build a list of valid recipients then we can safely go ahead with a mass insert. This means the notifications stream objects need to also handle creating entries to multiple recipients.
The reason a lot of this wasn't put into plugins directly previously is because of how streams are currently built (from a set of parameters), but them changing in #7454 will remove that obstacle.