It turns out that the idea of “sending” a notification is flawed. (What
happens if the notification subject is deleted shortly after? The
notified user would end up with a dud notification which would be
confusing. What about if a post is edited to mention an extra user? If
you sent out notifications, the users who’ve already been mentioned
would get a duplicate notification.)
Instead, I’ve introduced the idea of notification “syncing”. Whenever a
change is made to a piece of data (e.g. a post is created, edited, or
deleted), you make a common notification and “sync” it to a set of
users. The users who’ve received this notification before won’t get it
again. It will be sent out to new users, and hidden from users who’ve
received it before but are no longer recipients (e.g. users who’ve been
“unmentioned” in a post).
To keep track of this, we use the existing notifications database
table, with an added `is_deleted` column. The syncing/diffing is
handled all behind the scenes; the API is extremely simple (see
Core\Notifications\DiscussionRenamedNotification +
Core\Events\Handlers\DiscussionRenamedNotifier)
Perhaps also in user activity stream. They are used in the mentions
extension.
In order to generate the excerpt, each formatter can implement a
“strip” method which basically converts block formatting into inline
formatting.
Also make some tweaks:
- Merge SerializeAction::$include and
SerializeAction::$includeAvailable into a keyed boolean array
- Set defaults for SerializeAction::$limit and $limitMax
- Rename SerializeAction::$sortAvailable to $sortFields
- An API action handles a Flarum\Api\Request, which is a simple object
containing an array of params, the actor, and optionally an HTTP
request object
- Most API actions use SerializeAction as a base, which parses request
input according to the JSON-API spec (creates a JsonApiRequest object),
runs the child class method to get data, then serializes it and assigns
it to a JsonApiResponse (standard HTTP response with a
Tobscure\JsonApi\Document as content)
- The JSON-API request input parsing is subject to restrictions as
defined by public static properties on the action (i.e. extensible)
- Also the actor is given to the serializer instance now, instead of
being a static property
- In order to be consistent with the Ember/LESS naming scheme, renamed
Flarum\Web to Flarum\Forum.
- Moved common classes into Flarum\Support so that Flarum\Admin doesn’t
depend on Flarum\Forum. Also moved Actor into Flarum\Support as it
doesn’t belong in the domain.
This allows me to override the handle() method in subclasses (where
I need access to the request object) without having to overwrite
run(), too.
The class is still abstract.
Perhaps this should be an extension, but it is pretty essential and I
can’t think of many instances where it wouldn’t be wanted. Would be
very easy to extract later on if need be.
