Add support for filtering by relationship fields in the admin UI

[timleslie]

Let's say you have a list posts with a related field author (that links to the authors list). Currently, the "simple search" functionality (#319) available from the admin UI won't dereference this relationship. So if you filter by "Jane" in the admin UI, you'll only get posts with "Jane" in the name, not posts where the author has "Jane" in their name.

Ideally, Keystone would be able to apply these "simple search" filters to related collections and apply them to items in the list being viewed.

Note, this functionality is closely related to, and dependant on, the "Implement configurable search fields" (#343) but is a distinct piece of work.

[timleslie]

As a first pass we should be able to filter by just the ID (using the label inside a select component).

[molomby]

As discussed, the first step is building UI to allow selection of a single item from a related list. Ie. a searchable select field.

The exact behaviour is going to depend on the number of items in the related list. If there aren't many (<50?) the interface could load them all then maybe filter down client-side as the user types (I believe this is the current behaviour?).

However, the related list could potentially contain millions of items. This requires a mode of operation where no items are loaded automatically. The user can type into the field and, when less than a certain number are matched (20?), they populated into the select field.

This UI/behaviour should also be used when setting a single related item in the new/edit form.

[jesstelford]

It would be easy enough to do the filtering by queries, it'd just be a matter of figuring out which things to filter by:

query searchPosts($search: String) {
  allPosts(where: {
    OR: [
      title_contains: $search,
      body_contains: $search,
      author: { name_contains: $search },
      comments: { comment_contains: $search }
    ]
  }) {
    id
    title
  }
}

It would be possible to recursively gather up all the possible title_contains, etc, filters for a list, something like:

function listFieldsAsSearchPaths(list) {
  return list.fieldsArray.map(field => {
    switch (field.prototype.constructor) {
      case Text:
        return `${field.path}_contains: $search`;
      case Relationship: {
        const paths = listFieldsAsSearchPaths(getListByKey(field.ref));
        if (!paths) {
          return null;
        }
        return `${field.path}: { ${paths} }`;
      }
      default:
        return null;
    }
  }).filter(filter => filter)
  .join(',\n');
}

const query = gql`
  query searchPosts($search: String) {
    allPosts(
      where: {
        OR: [
          ${filters}
        ]
      },
      first: 20
    ) {
      id
      title
    }
  }
`;

(Note: This example has the limit set to the first 20)

[jesstelford]

The above could also act as an initial implementation for #319 & #343

[MadeByMike]

From duplicate issue:

The queries for this kind of filtering already exist:

query {
  allPosts(where: { author: { name_contains: "Jane" } }) {
    id
    title
  }
}

[stale]

It looks like you haven't had a response in over 3 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contributions. :)

[gautamsi]

what about adding adminConfig item for search

here $search is predefined variable we document that someone has to use

listConfig.adminConfig = { searchQuery: `query <name>($searchText: String!){all<Listname>s(where:{mycondition: $search}){<required fields can be filled by query builder based on view>}`}

or we just get the querybuilder based on variable name,

listConfig.adminConfig = { searchQuery: `{OR: [{field1: $search},{field2_contains: $search}]}` }

we will replace the where clause condition from this config value.

[gautamsi]

this way I can have it customised for each list.

[stale]

It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)