Franz Liedke 3b5691ee28 Restore beta.9 behavior of assertCan() ... In flarum/core#1854, I changed the implementation of `assertCan()` to be more aware of the user's log-in status. I came across this when unifying our API's response status code when actors are not authenticated or not authorized to do something. @luceos rightfully had to tweak this again in ea84fc4, because the behavior changed for one of the few API endpoints that checked for a permission that even guests can have. It turns out having this complex behavior in `assertCan()` is quite misleading, because the name suggests a simple permission check and nothing more. Where we actually want to differ between HTTP 401 and 403, we can do this using two method calls, and enforce it with our tests. If this turns out to be problematic or extremely common, we can revisit this and introduce a method with a different, better name in the future. This commit restores the method's behavior in the last release, so we also avoid another breaking change for extensions.		2019-09-14 21:32:00 +02:00
..
Command	Restore beta.9 behavior of assertCan()	2019-09-14 21:32:00 +02:00
Event	Extract Flarum\Group namespace	2017-10-03 18:49:53 +02:00
Group.php	Apply fixes from StyleCI (#1793)	2019-06-12 23:50:21 +02:00
GroupPolicy.php	Remove use of event priorities	2018-01-11 14:10:37 +10:30
GroupRepository.php	Extract Flarum\Group namespace	2017-10-03 18:49:53 +02:00
GroupServiceProvider.php	Cleanup code, typehints and class references	2017-10-03 18:54:07 +02:00
GroupValidator.php	Extract Flarum\Group namespace	2017-10-03 18:49:53 +02:00
Permission.php	Clean up Eloquent definitions	2018-07-21 17:06:42 +09:30