As discussed in my initial review, it seems unlikely that we need
the ability to remove (or otherwise modify) namespaces again.
Therefore, it seems more consistent with other extenders to go
for a "View" extender with a "namespace" method.
Sorry for the back and forth. ;)
Refs #1891, #2134.
* Write source map without creating temp file
Less I/O, and one less place where we access the global path helpers.
* Drop useless app_path() helper
This was probably taken straight from Laravel. There is no equivalent
concept in Flarum, so this should be safe to remove.
* Deprecate global path helpers
Developers using these helpers can inject the `Paths` class instead.
* Stop storing paths as strings in container
* Avoid using path helpers from Application class
* Deprecate path helpers from Application class
* Avoid using public_path() in prerequisite check
a) The comparison was already outdated, as a different path was passed.
b) We're trying to get rid of these global helpers.
* Deprecate GetDisplayName event
* Add interface for display name driver
* Add username driver as default
* Add code to register supported drivers / used driver as singletons
* Configured User class to use new driver-based system for display names
* Add extender for adding display name driver
* Add integration test for user display name driver
* Add frontend UI for selecting display name driver
- Stop trying to implement Laravel's Application contract, which
has no value for us.
- Stop inheriting from the Container, injecting one works equally
well and does not clutter up the interfaces.
- Inject the Paths collection instead of unwrapping it again, for
better encapsulation.
This brings us one step closer toward upgrading our Laravel
components (#2055), because we no longer need to adopt the changes
to the Application contract.
This ensures that default values, date attributes and relationships are properly inherited, when we have deeper model class hierarchies.
This also adds test cases to ensure that inheritance order is honored for relationship and default attribute extender. As there's no way to remove date attributes, the order of evaluation there doesn't matter.
Only users that have the new `viewHiddenGroups` permissions will be able to see these groups.
You might want this when you want to give certain users special permissions, but don't want to make your authorization scheme public to regular users.
Co-authored-by: luceos <daniel+github@klabbers.email>
- Inject contract, not implementation
- Do not dispatch event in test, let the core do that
- Ensure the relevant database tables are reset prior to the test
- Use correct parameter order for assertions
Refs #2097.
- Use private over protected
- Use "public" API for building requests in tests
- Add more assertions
- Formatting
- Use correct parameter order for assertions
Refs #2012.
* Made the console command system extender-friendly
* Added console extender
* Added ConsoleTestCase to integration tests
* Added integration tests for console extender
* Marked event-based console extension system as deprecated
* Moved trimming command output of whitespace into superclass
* Renamed 'add' to 'command'
* Added special processing for laravel commands
* Code style fixes
* More style fixes
* Fixed $this->container
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.
I feel this makes the parameters a bit more clear, does not rely on
inheritance (you can only inherit from one class, but we might want more
of these helpers in the future), and has less side effects (e.g. no
creation and, more importantly, deletion of users in the database).
Refs #2052.
Test the request, not a controller (implementation detail). This also
focuses on the observable behavior instead of hacking our way into the
middleware pipeline in order to observe internal behavior.
The authenticated user is now determined by looking at the API response
to compare permissions and (non-)existing JSON keys.
