Fix URL parameter type for filter rules without frontend filter widget - #1585
Open
zonky2 wants to merge 1 commit into
Open
Fix URL parameter type for filter rules without frontend filter widget#1585zonky2 wants to merge 1 commit into
zonky2 wants to merge 1 commit into
Conversation
The URL parameter type ("URL type for the parameter") introduced with #1558 and
fixed up in #1563 was only honoured for filter rules that render a frontend filter
widget. ListControllerTrait::getFilterParameters() obtained the type from
getParameterFilterWidgets(), which returns nothing for rules without widget - the
usual detail page rules. Those parameters fell back to "slugNget" and were accepted
as slug as well as GET, no matter what was configured.
The type is now obtained from the filter settings themselves:
* Simple::getParameterTypes() reports the configured param_type for all parameters
of a setting, WithChildren and ExpressionRule merge the types of their children
and Collection::getParameterTypes() aggregates all settings of the collection.
* ParameterTypes::fromSetting() provides the backwards compatibility layer for
filter settings not implementing getParameterTypes(). They are treated as
"slugNget" and trigger a deprecation. The method becomes part of ISimple in
MetaModels 3.0 - adding it now would break implementations not extending Simple.
Render\Setting\Collection::buildJumpToUrlFor() builds the jumpTo URL of the detail
page as slug or as GET according to the configured type - it always used slug
before, so a rule configured as GET produced links that did not match its own
configuration.
A parameter passed via another type than the configured one now results in a 404
instead of silently rendering the unfiltered list under an URL that looks like it
is filtered. This is limited to rules without frontend filter widget; for widgets
the frontend filter handles the URL (see #1563) and a value of the wrong type stays
unused as before.
As a side effect the expensive getParameterFilterWidgets() call is gone from the
regular rendering path. It is only performed when a mismatch was detected, that is
on the path ending in a 404 anyway.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The URL parameter type ("URL type for the parameter") introduced with #1558 and fixed up in #1563 was only honoured for filter rules that render a frontend filter widget. ListControllerTrait::getFilterParameters() obtained the type from getParameterFilterWidgets(), which returns nothing for rules without widget - the usual detail page rules. Those parameters fell back to "slugNget" and were accepted as slug as well as GET, no matter what was configured.
The type is now obtained from the filter settings themselves:
Render\Setting\Collection::buildJumpToUrlFor() builds the jumpTo URL of the detail page as slug or as GET according to the configured type - it always used slug before, so a rule configured as GET produced links that did not match its own configuration.
A parameter passed via another type than the configured one now results in a 404 instead of silently rendering the unfiltered list under an URL that looks like it is filtered. This is limited to rules without frontend filter widget; for widgets the frontend filter handles the URL (see #1563) and a value of the wrong type stays unused as before.
As a side effect the expensive getParameterFilterWidgets() call is gone from the regular rendering path. It is only performed when a mismatch was detected, that is on the path ending in a 404 anyway.