The activity system we were using was built around a separate table.
Whenever the user posted something, or deleted a post, we would sync
the table. The advantage of this was that we could aggregate activity
of all different types very efficiently.
It turns out that it came with a huge disadvantage: there was no
efficient way to enforce permissions on activity. If a user posted
something in a private tag, everyone could still see it on their
activity feed. My stopgap solution was to only sync activity for posts
that are viewable by guests, but that was way too limited.
It also turns out that aggregating activity of different types is
really not that useful, especially considering most of it is the user
making posts. So I've gotten rid of that whole overly-complicated
system, and just made the user profile display separate lists of posts
and discussions, retrieved from those respective APIs. The discussions
page is an actual discussion list too, which is pretty cool.
It's still technically possible to aggregate different activity types
(basically just aggregate API responses together), but we can do that
later if there's a need for it.
This is probably my favourite commit of the day :)
- Fix composer crashing/not showing alert on error
- Make a general ValidationException which takes an array of field ⇒
messages to be outputted nicely by the API
- Return all discussion post IDs from API requests which add/remove
posts, so the post stream updates appropriately. Related to #146
- Always unload posts that are two pages away, no matter how fast
you’re scrolling
- Retrieve posts from cache instead of reloading them
- Fix various bugs. Maybe #152, needs confirmation
- Use contextual namespaces within Flarum\Core
- Clean up and docblock everything
- Refactor Activity/Notification blueprint stuff
- Refactor Formatter stuff
- Refactor Search stuff
- Upgrade to JSON-API 1.0
- Removed “addedPosts” and “removedPosts” relationships from discussion
API. This was used for adding/removing event posts after renaming a
discussion etc. Instead we should make an additional request to get all
new posts
Todo:
- Fix Extenders and extensions
- Get rid of repository interfaces
- Fix other bugs I’ve inevitably introduced
Only preloading data for basic requests w/o query params, at least for
the moment - if we have to preload for something like
/?q=test&sort=newest, we end up having to duplicate a whole lot of
logic between JS/PHP.
Explained in d1e7453ffd11d8b58672f6771e62c53e7441670b.
If we ever come up with a better way of doing this it should be easy to
change over, since modification of these properties by extensions is
abstracted by an Extend API.
@franzliedke I didn’t realise that static properties are static to the
class they are defined on, and not each individual subclass. All of the
static members of the SerializeAction class (which are intended for
extensions to alter per-action) are being inherited by all actions.
Any ideas on how to work around this other than defining every static
member on each individual subclass?
Get rid of Permissible - too complex and inefficient. Replace with:
- a “Locked” trait which works similarly but only evaluates logic on
hydrated models.
- a “VisibleScope” trait which also works similarly but only scopes
queries
This is all we need, Permissible is overkill. There is only one
instance where we have to duplicate some logic
(Discussion::scopeVisiblePosts and Post::allow(‘view’, …)) but it’s
barely anything.
Haven’t decoupled for now, we can definitely look at doing that later.
Permissions table seeder slightly updated.
Also did a bit of a query audit, there’s still a lot to be done but
it’s much better than it was. Some relatively low-hanging fruit
detailed in EloquentPostRepository.
