Delete of filtered rows does not work on ModelAdmin

Hi all,

I am developing a project based on silverstripe/framework 3.7.1. There
I use a ModelAdmin that by default does not show up deprecated
records (i.e. rows with SostituitoDaID != 0).

I added a flag to the search context to be able to get those records in
the GridField. Here is the relevant code:

class MyAdmin extends ModelAdmin
{
    ...

    public function getSearchContext()
    {
        $context = parent::getSearchContext();
        ...
        $context->getFields()->push(CheckboxField::create(
            'q[Tutti]',
            'Includi obsoleti'
        ));
        ...
        return $context;
    }

    public function getList()
    {
        $list   = parent::getList();
        $params = $this->request->requestVar('q');
        ...
        if (empty($params['Tutti'])) {
            $list = $list->filter('SostituitoDaID', '0');
        }
        ...
        return $list;
    }
}

All is working as expected apart the deletion of those deprecated
records. Deleting other records works without issues.

My workflow is:

  1. I flag the checkbox in the filter to show up the deprecated records
    in the main GridField
  2. I select the record, entering its ItemEditForm
  3. I press the Delete button and confirm it.

After that a wrong redirection is performed (the .cms-content-header
disappears and the .cms-content-fields overflows), the filter is reset
and the record is not deleted.

Any pointer would be appreciated.

I’ve encountered a similar problem before. From memory, any records that you want to perform an action on need to be present when no filters are applied. That’s because the delete action (and others) act on the unfiltered list, ignoring any filters you applied so far. You can’t delete something that isn’t there, hence the failure.

1 Like

Thank you @JonoM for letting me know: now at least I’m confident I am not doing something insane.

I still think this is a straight bug though. When I have some spare time I’ll try to write a minimal test case and submit it to the issue tracker.

I thought the same thing, just didn’t have time right then to open an issue, and naturally, forgot about it later :upside_down_face:. It’s possible this is fixed in 4, I haven’t tested.