* flagrow/byobu#11 making posts and discussions private
* tested migrations and tested setting is_private on discussion and post manually
* added phpdoc for Post and Discussion and added the casting for these attributes
* satisfying styleci
* fixes for review
* added new private discussion event and included it in the access policy
* added new private post event and included it in the access policy
The way I read it, HTTP 405 is a generic statement about the
resource. Once a language pack is not the default, this is not
true anymore, so I figured 403 is more correct.
I want to make it a little more clear that we are checking exactly
for these two values. That may also help preventing further confusion
as to why we are not using empty() here.
Amendment to PR #1033.
This is a bit sloppy (might come up with a better solution yet), but since most events provide access to the actor but not the request, this was the easiest/quickest way to allow extensions to access the session.
Laravel's `image` validation rule allows svg files to pass validation, but we can't handle svgs so it would result in an unspecified 500 error which isn't nice.
This helps to fix a bug in flarum-ext-tags where a user could not rename or edit the tags of their own discussion if it was in a restricted tag. This was due to the order of GetPermission event listeners – the logic that determines that a user *can't* perform an action because of a restrictive tag was running before (and thus instead of) the logic that determines that a user *can* edit their own stuff.
The solution is to change the "catch-all" methods on Policies to "after" instead of "before" – that is, they will run only if the per-ability methods return null.
We also simplify the GetPermission event by passing the model as a sole "argument", as I can't imagine any cases where we'll need more than one argument.
- When no discussions are visible, the query that filters posts by discussion visibility was incorrectly making all posts visible.
- Also hide user profiles altogether if discussions are not visible.
A bit of an edge-case since it shouldn't really be possible to have a discussion with zero posts anymore, but when renaming an empty discussion (or taking any action that will create an "event post"), Flarum would crash. This is due to the MergeableInterface requiring these posts to be saved after a previous post.
When renaming a discussion, an attempt is made to send a notification to the discussion's author. However, there is no check to see if the user account still exists - this can lead to a crash. While the check should technically be in the initiating code, it will probably slip through the cracks in other scenarios/extensions, so it's probably best that we safe-guard against this in the NotificationSyncer itself.
- On the front-end, correct the check to see if the discussion has no more posts
- On the back-end, run a query to count the posts instead of using the comments_count, because the comments_count does not include other deleted posts
Laravel's alpha_dash rule allows unicode letters including those with inflections, leading to issues like #832. As per discussion in #557, we are sticking with ASCII-only usernames for now.
