components/font-awesome is ~8 MB smaller than fortawesome/font-awesome because it excludes all examples/docs. Reducing dependency filesize will be important when we want to package up a .zip for distribution.
By default this is just the same as the "startDiscussion" permission, but flarum-ext-approval comes in and denies "addToDiscussion" specifically for tags where the user can't start discussions without approval.
ref flarum/core#904
A user now must have a permission to act for *all* tags assigned to a discussion, rather than just one of them. This is consistent with the way the permissions are worked out for visibility.
Given flarum/core@2d5a7ce, the hidden badge will no longer display for discussions awaiting approval – it will only display if the discussion has *actually* been marked as deleted by the OP. Thus, this information should have precedence. (There isn't much point in displaying both badges, I don't think.)
Extensions may wish to add attributes/content to all posts, regardless of type, by extending methods on the Post component. Now the subclasses will not overwrite, but rather append to, these additions.
Previously a discussion was classified on the front-end as "hidden" if it had zero posts. This was technically a correct statement as the discussion would not be visible to the public... but it also meant that a discussion with zero posts (like one awaiting approval) was impossible for the OP to delete/hide (i.e. indicate that they made a mistake and they don't want the discussion to be approved).
Extensions can add default column values in their migrations, but Eloquent doesn't know about this when it first saves a model to the database.
This is useful in flarum-ext-approval where the default value for is_approved on the posts table is true.
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.
