This naming is clearer as to the intended effect. Changes include:
- A migration to rename all permissions
- Updating the seed migration to use the original naming from the start
- Replacing usage of the old names with new names in code
- Throwing warnings when the old names are used.
Updated GroupFilterGambit to prevent hidden groups being visible where they shouldn't be and to ensure that only the selected groups are returned on a search. Fixes#2559
- Split user edit permision into edit attributes, edit credentials, and edit groups
- Only Admins can edit Admin Credentials
- Only Admins can Promote/Demote to/from Admin
Before transactions, each test class would need to explicitly state starting state for permissions, which made the initial permission configuration somewhat arbitrary. Now, we might as well use the initial state of the default installation.
One of the User show_test tests has been commented out until
- Support slug drivers for core's sluggable models, easily extends to other models
- Add automated testing for affected single-model API routes
- Fix nickname selection UI
- Serialize slugs as `slug` attribute
- Make min search length a constant
There are two more API integration tests that explicitly add the
"Authorization" header right now:
- `Flarum\Tests\integration\api\authentication\WithApiKeyTest`
- `Flarum\Tests\integration\api\csrf_protection\RequireCsrfTokenTest`
These two specifically test authentication, so in those cases the
explicitness seems desirable.
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.
This test would have failed without commit ea84fc4. Next, I will revert
that commit and most of my PR #1854, so we need this test to ensure the
API continues to behave as desired.
