Policy application has also been refactored, so that policies return one of `allow`, `deny`, `forceAllow`, `forceDeny`. The result of a set of policies is no longer the first non-null result, but rather the highest priority result (forceDeny > forceAllow > deny > allow, so if a single forceDeny is present, that beats out all other returned results). This removes order in which extensions boot as a factor.
This is important because extensions may wish to render post content
differently depending on Request factors such as the actor. For example,
an attachments extension might wish to hide attachments from guests.
This solution is a bit of a hack-job for now, but soon when we refactor
the API layer to use tobscure/json-api-server, and also refactor the
Formatter layer, it can be revised.
Permission to rename/hide/edit one's own discussion/post is only granted
if the user has permission to reply to the discussion. This makes sense
if you think of these actions as forms of "replying" to a discussion.
Fixes#1419 because suspended users do not have permission to reply to
discussions, therefore they will not be granted these "own" permissions.
* Overhaul the way model visibility scoping works
- Previously post visibility scoping required concrete knowledge of the
parent discussion, ie. you needed a Discussion model on which you
would call `postsVisibleTo($actor)`. This meant that to fetch posts
from different discussions (eg. when listing user posts), it was a
convoluted process, ultimately causing #1333.
Now posts behave like any other model in terms of visibility scoping,
and you simply call `whereVisibleTo($actor)` on a Post query. This
scope will automatically apply a WHERE EXISTS clause that scopes the
query to only include posts whose discussions are visible too. Thus,
fetching posts from multiple discussions can now be done in a single
query, simplifying things greatly and fixing #1333.
- As such, the ScopePostVisibility event has been removed. Also, the
rest of the "Scope" events have been consolidated into a single event,
ScopeModelVisibility. This event is called whenever a user must have
a certain $ability in order to see a set of discussions. Typically
this ability is just "view". But in the case of discussions which have
been marked as `is_private`, it is "viewPrivate". And in the case of
discussions which have been hidden, it is "hide". etc.
The relevant API on AbstractPolicy has been refined, now providing
`find`, `findPrivate`, `findEmpty`, and `findWithPermission` methods.
This could probably do with further refinement and we can re-address
it once we get around to implementing more Extenders.
- An additional change is that Discussion::comments() (the relation
used to calculate the cached number of replies) now yields "comments
that are not private", where before it meant "comments that are
visible to Guests". This was flawed because eg. comments in non-public
tags are technically not visible to Guests.
Consequently, the Approval extension must adopt usage of `is_private`,
so that posts which are not approved are not included in the replies
count. Fundamentally, `is_private` now indicates that a discussion/
post should be hidden by default and should only be visible if it
meets certain criteria. This is in comparison to non-is_private
entities, which are visible by default and may be hidden if they don't
meet certain criteria.
Note that these changes have not been extensively tested, but I have
been over the logic multiple times and it seems to check out.
* Add event to determine whether a discussion `is_private`
See https://github.com/flarum/core/pull/1153#issuecomment-292693624
* Don't include hidden posts in the comments count
* Apply fixes from StyleCI (#1350)
Event priorities are no longer in Laravel - see dbbfc62bef
Updated the AbstractPolicy terminology to reflect the new behaviour,
which is that there is no guarantee that the catch-all methods will run
after all specific methods have run globally. This behaviour is only
guaranteed within the policy.
