ModelAdmin: saved searches and default search

[sminnee]

A ModelAdmin with a bunch of search fields is an excellent power-user feature but it can end up with something a little unwieldy.

To give users more specific views on a complex data model, you can build specific ModelAdmins with customised getList() values, but this can lead to edge-case bugs such if you edit and save the record such that it no longer appears in the list. @chillu found the experience of suboptimal and might be able to elaborate.

To resolve this, a mechanism by which a number of "saved searches" could be loaded into a ModelAdmin would increase its power. Ideally, these would be user-editable, as well as providing some ability for the system to come with saved searches by default.

With this in place, it would be useful to specify a default search, which is used to present the ModelAdmin when it's first loaded.

For extra power (and complexity), the visibility of saved search could be set to only some users.

If it's possible to do this as a module, that would probably make sense, but it may need some refactoring of the core modules to provide the necessary extension points.

[robbieaverill]

Sounds like a great idea to me. Without having put much thought into it, I agree that it is probably better as an opt in module.

[sminnee]

Yeah I think in particular, user-configurable saved searches would mean more tables, which is a good reason to put it in a separate module. It also makes it easier to be more experimental – for example I've been looking at ways of making permission control more flexible without a big-bang refactor (https://github.com/sminnee/silverstripe-microacl) and it would be more feasible to pull that in as a dependency if it were a module rather than an admin patch.

Right now, however, adjusting the search is very difficult – I tried on a project to hard code in a different default search and gave up. So I suspect that we'll require core changes to make this stuff more extensible.

[robbieaverill]

Ok cool, that sounds like valuable improvements for core as well.

[altwohill]

For what it's worth, this is the pattern I use to handle it. In this example I default to only show "New" registration requests, and exclude "Accepted" and "Rejected" unless the search is changed.

<?php
// snip normal imports
class RegistrationAdmin extends ModelAdmin
{
    private static $managed_models = [
        RegistrationRequest::class,
    ];

    private static $url_segment = "registrations";

    private static $menu_title = "Registration Requests";

    public function getList()
    {
        $filter = [];
        $list = parent::getList();
        $url = $this->getRequest()->getURL();

        // Don't filter if we're trying to get to an actual model edit page
        if (!\str_ends_with($url, '/edit')) {

            $params = $this->getRequest()->requestVar('filter');
            $query = isset($params[$this->sanitiseClassName($this->modelClass)]) ? $params[$this->sanitiseClassName($this->modelClass)] : [];
            $status = "New"; // Default to new
            if (isset($query["Status"])) {
                $status = $query["Status"];
            }
            $filter = ["Status" => $status];
        }
        return $list->filter($filter);
    }
}

It does break the ability to search for any status, but this isn't a requirement for me at the moment.