Keystone-classic: AdminUI relationship field doesn't load full list of items (0.3.22)

[sebastiancarlsson]

Use case: I have an Article object with a field called country:

country: { type: Types.Relationship, ref: 'Country' }

Country is a list in the database of all countries in the world (around 250 items in total).

When editing this field in an Article the dropdown only has the first 50 countries in it (and does not get updated when searching), for example if I search for "South Africa" this country is not available in the list.

Steps to reproduce the behavior

Create a list with a relationship type field that points to a model with 50+ items.

Expected behavior

When editing an item in the AdminUI, the relationship dropdown element should show results based on input.

Actual behavior

Only the 50 first items of the list is shown (the dropdown does not refresh on input).

[burgerboydaddy]

Funny but I also have issue with list of countries :-)

Anyway, quick fix for problem can be done in keystone/admin/api/list.js

Removing limit and skip will load all reference items.

`case 'autocomplete':
// var limit = Number(req.query.limit) || 50;
// var page = Number(req.query.page) || 1;
// var skip = limit * (page - 1);

        var filters = req.list.getSearchFilters(req.query.q);

        var count = req.list.model.count(filters);
        var query = req.list.model.find(filters)
            // .limit(limit)
            // .skip(skip)
            .sort(req.list.defaultSort);

        if (req.query.context === 'relationship') {
            var srcList = keystone.list(req.query.list);
            if (!srcList) return sendError('invalid list provided');

            var field = srcList.fields[req.query.field];
            if (!field) return sendError('invalid field provided');`

Other way is to alter keystone RelationshipField.js (keystone/fields/types/relationship) and add inside buildOptionQuery additional query parameters that are missing (limit and page).
buildOptionQuery: function (input) { var value = input && input[0] && input[0].value || ''; var filters = this.buildFilters(); return 'context=relationship&q=' + value + '&list=' + Keystone.list.path + '&field=' + this.props.path + '&limit=500' + '&page=0' (filters ? '&' + filters : ''); },

If somebody can guide me where is client side code that makes this call, I can spend some time working on proper solution.

[sprijk]

+1

[SheaBelsky]

Is there a way for this to be done without directly editing the Keystone Node module? I use Heroku to manage my Keystone application, and I wouldn't be able to do such a fix as this because Heroku installs my modules for me. Would I need to fork Keystone itself and make that one minor change in order for it to work?

Maybe we could have an option to specify limit client side? Like a keystone.set variable?

[joejeet]

Rather than the fork, I'll suggest going back to last version of "keystone": "0.3.21" so that you can update easily in future.

[SheaBelsky]

I'm still on Keystone 3 (my package.json says "keystone": "^0.3.22"), although I haven't yet made the switch to Keystone 4 (I don't intend to do so until it's out of beta). The problem remains that any edits I make to the Keystone module don't carry over into my Heroku instance. I would still need to fork Keystone and upload it as a separate module in order to make the necessary changes. Unless there is an easier way of doing that.

[bradwbradw]

@joejeet I rolled mine back to version 0.3.21 but still seeing this issue. Does anyone know what version has an autocomplete call that isn't limited to 50 (or 100)?

edit: I am now on version 0.3.20 and relationship dropdowns seem to be working correctly

[bradwbradw]

It's very strange: in my local copy, with version 0.3.20 set up (I have verified the node_modules/keystone/package.json file, while entering keystrokes in the Relationship input i can see AJAX requests going out that have q= parameter populated with what I have entered. This seems correct, but deployed on the server, with the same version (again verifying the package file) the AJAX requests that happen on keystrokes have an empty q= parameter.

I'm deploying to Heroku using a package.json file that includes "preinstall": "npm prune" so i don't think it's to do with different dependency versions, but i'm not sure what else it could be.

[guillaumew]

I have the same problem

[joejeet]

Not sure guys I'm using 0.3.21 version on Heroku and it's working perfectly fine for me.

And I use pm2 keymetrics process manager for deployment

[guillaumew]

Thanks! I rolled back to 0.3.21 and it fixed the problem. But 0.3.22 is not good :/

[bradwbradw]

I found that clearing the browser cache can fix the problem, maybe it's hanging onto an old version of a client-side dependency

[jamiecounsell]

Confirmed working with 0.3.21 for me as well. Thanks @guillaumew, I will not upgrade to 0.3.22.

[etoxin]

0.3.21 worked for me. 50 results still show in the dropdown but this is expected. Need to search for page 2, 3, 4 results.

[Noviny]

This is fixed for Keystone 4. We are no longer working to solve issues with keystone 0.3

[jeffinmotion]

@Noviny in Keystone 4 it seems we still have a hard limit of 100 and I have the need to view/search more:

https://github.com/keystonejs/keystone/blob/master/admin/server/api/list/get.js#L54

Have I missed how to configure a list relationship to pass this limit param through the Admin UI, or does a proposal / PR need to be opened for this?

[Noviny]

@jeffinmotion It will favour a provided query limit, if one exists. It's not configurable by the admin UI, but can be configured in the code. It's significantly better to rely on filtering relationships, not pulling down more though.

[jeffinmotion]

It's significantly better to rely on filtering relationships, not pulling down more though.

@Noviny Yes, definitely understood, but my domain simply just needs to display/search more than 100 right now.

Sorry for the hassle about this, but I'm just not seeing how that limit is changed via the code—do you mean forking & altering the line of source code I noted, or providing a specific config value (and if so, which one)?

[Noviny]

@jeffinmotion Currently forking is the only real way.

We'd probably accept a pull request as long as it properly handled large collections. Most likely if there were a way on setting the relationship type to set up the maxQueryNumber or a slightly better named variable.