Added new 'clear'-scope as requested in #3952

[robinbonnes]

…/october/issues/3952.

Format in config_filter.yaml:

    clear:
        label: Clear filters
        type: clear

[bennothommo]

@robinbonnes Please review and fix the code style issues reported here:
https://github.com/octobercms/october/pull/4744/checks?check_run_id=291252747#step:6:8

[robinbonnes]

@bennothommo fixed ✔️

[Samuell1]

I think this will be better as option in config_list.yaml something like allowResetFilter: true.

And question does this resets values to default or totally "clears" filter?

[robinbonnes]

Thats also an idea, however on this way you can specify where to place the clear filter button in the filter list (start, end) and what the button text should be (the label).

Now it does reset all filters to null, so it totally clears the filters. I think resetting them back to default is better?

[Samuell1]

@robinbonnes Yeah, it should reset to default because if something cant be null then you get DB errors.

[msimkunas]

I'm not sure if this PR is still being worked on, but here goes...

The Backend\Widgets\Filter class extends the WidgetBase class which uses a trait that provides the resetSession method which is supposed to reset all session data related to the current widget. Perhaps we can use this method instead of manually setting the scope values back to their defaults?

[robinbonnes]

@robinbonnes please also post a screenshot of what this looks like and add a PR to the test plugin

Although the PR needs some adjustments... Can we reopen this?

[msimkunas]

In my testing, this line only updates the scope container. The content of the backend list, however, remains the same.

Removing this line inverts the issue: the list contents are refreshed but the scope container no longer updates.

[msimkunas]

In order to circumvent the above issue, we should not abruptly return the partial update before the filter.update event has had its chance to run at the end of the onFilterUpdate method.

The following works (and is a bit cleaner):

$updateScopePartial = false;

switch($scope->type) {
    ...
    case 'clear':
        foreach ($this->getScopes() as $scope) {
            $this->setScopeValue($scope, null);
        }

        $updateScopePartial = true;
        break;
}

$params = func_get_args();

$result = $this->fireEvent('filter.update', [$params]);

if($updateScopePartial) {
    $this->prepareVars();
    $result[] = ['.control-filter' => $this->makePartial('filter_scopes')]; 
}

if ($result && is_array($result)) {
    return call_user_func_array('array_merge', $result);
}

The $updateScopePartial controls whether the scope container should be updated since we don't want to trigger partial updates on every scope request. Also, only the inner partial of the scope container is rerendered.

@robinbonnes Currently I don't have time to make a PR for this. Would you update your PR with these changes?

[msimkunas]

I have also noticed that there is a bug regarding scopes with dropdown options. This PR with the changes I've suggested above clears the actual filters in the session, however, the previously selected dropdown items are still selected in the backend UI. This selection is only applied when filtering the list again though.

[msimkunas]

This PR would also benefit from an optional resetDefault: true flag which, if true, would reset the scope values back to their defaults or clear them otherwise.

If you don't have time to continue working on this PR @robinbonnes, I could give it a go soon so do let me know.

[msimkunas]

One more thing. The checkbox and switch scopes must be handled differently, e.g.:

foreach($this->getScopes() as $scope) {
    $value = null;

    switch($scope->type) {
        case 'checkbox':
            $value = false;
            break;
        case 'switch':
            $value = '0';
            break;
    }

    $this->setScopeValue($scope, $value);
}

Using null as a value for these scopes does not properly reset them - those scopes are reset to their default values instead which may or may not be the desired behavior. This can be controlled with a flag (see my comment above).

[robinbonnes]

@msimkunas Thanks for your suggestions, really appreciate it! I've added it to the PR.

Some questions:

• Why add $this->prepareVars();?
• Can't a switch/checkbox be default: true?

Ofcourse you are free to work on this PR.

[msimkunas]

@robinbonnes The prepareVars method defines the scopes which are used inside the partial.

As for the default switch/checkbox value – I believe that the user setting should be respected here and the default (if provided) should be retrieved from the scope configuration.

[msimkunas]

Also bear in mind that this PR needs to reset the filter values on the client side in order to be fully functional. This requires one to somehow reinitialize the JS scope widget and IIRC the existing JS widget requires significant changes for this to be possible (i.e. it needs to unbind event handlers and properly dispose of itself upon destruction).

Another approach would be to somehow detect partial updates from within the widget and clear the scopes accordingly.

resolved

[msimkunas]

@LukeTowers The problem, I think, is that it's only one part of the solution. See my comment for more details.

[robinbonnes]

Doesn't the resetSession function also reset the list settings etc.? Maybe for now setting the filters back to their defaults and refreshing the filter partial is enough to merge this? Then in the future someone can make the JS adjustements and maybe modify the resetSession function?

[daftspunk]

Thanks for this @robinbonnes and your insights @msimkunas

This has been merged for the next release in v2.2