Keystone-classic: [v0.4] Loading forever in list screen without default columns

[geloescht]

Expected behavior

Items list should load when navigating to http://localhost:3000/keystone/list?columns=id%2Cfile. This happens with all field types I tested (LocalFile, String, Select).

Actual behavior

A loading screen is shown forever. The following error gets logged to the console: TypeError: this.props.data.fields is undefined

Steps to reproduce the behavior

Create a list without default columns. Open its items list screen. Select any field from the columns chooser and hit apply. Refresh the page. This last step is important, the bug does only manifest if the page is reloaded.

Error is thrown on this line: https://github.com/keystonejs/keystone/blob/master/fields/types/localfile/LocalFileColumn.js#L5 (For LocalFile, other field types have an equivalent line) Probably it's another bootstrapping issue.

[jstockwin]

@geloescht I just tried to reproduce this with the following model, but cant. I've created two items, gone to the item screen, selected field A from the columns chooser, and refreshed the page. All works as expected. What am I missing?

var keystone = require('../../../../index.js');
var Types = keystone.Field.Types;

var NoDefaultColumn = new keystone.List('NoDefaultColumn', {
    autokey: {
        path: 'key',
        from: 'name',
        unique: true,
    },
    track: true,
});

NoDefaultColumn.add({
    name: {
        type: String,
        initial: true,
        required: true,
        index: true,
    },
    fieldA: {
        type: Types.Text,
        initial: true,
    },
    fieldB: {
        type: Types.Text,
    },
});

NoDefaultColumn.register();

module.exports = NoDefaultColumn;

[geloescht]

@jstockwin Try without a name field.

[jstockwin]

I would also add that if no default columns are specified, the "ID" column should show automatically. For me, initially there are just no visible columns, meaning I can't actually click to edit the item. Once I add field A though the columns selector, I am then presented with both ID and field A columns. The ID column should have been there from the start.

I've added a demonstration of both to the e2e test.

[jstockwin]

This can now be demonstrated in current master by running the following command, with XXXX replaced with this issue number.
node test/e2e/server.js --env default --config ./test/e2e/adminUI/nightwatch.json --test test/e2e/adminUI/tests/group999FixMe/XXXX.js

When this issue is fixed, please move XXXX.js to .../group007Misc/somethingSensible.js, and also change 'demonstrate issue XXXX': function(browser) in this file to something more sensible. If you can see a way to make these tests more generic, or add additional testing, then please go ahead.

[jstockwin]

This seems to be re-occurring in current master, and is breaking travis (see here).

I've moved the test back into FixMe, and am going to re-open this issue, as I don't have time to look into this now, and it'd be nice to get travis passing again.

@geloescht @JedWatson Any ideas?

[mxstbr]

Haven't looked into it, but that's possibly an issue with the way I'm hydrating the Redux store when visiting a page with query columns! store.js would be the culprit in that case.

It's father's day tomorrow, but as of next week I'm back at Keystone and can take a look at this!

[geloescht]

Tried to track this down via git bisect, but hit a wall of untestable commits, due to this error
Cannot find module '../../fields/types/cloudinaryimages/CloudinaryImageFilter' from '/home/lukas/Dokumente/Aufträge/Obersalzberg/node_modules/keystone/admin/client'

Output of git bisect:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
37e383d190a1f62e906420493645230e5cb912b7
6aa88205a37191a09db2f081b2f3b30770c6812c
7c48d0e6c9ede1b41ab0144bf8652031e1df3395
e64dba9ed145bea6d16ee2c77e3d4aa06932816f
754a93ff0cffbed38681e436fc354c8f7d42df0a
29a79eb9d0b406cd95b5262b18897077dde59fe7
6500bacc7eb87b87a0157523ed6932d9361d01f5
3df139104b7bc7b0ba0ba971126463f786ae41ba
4e8e30439441f72ae63defed9e25fc5c54a1312b
967c3fefb4f7940d217cfb50d4724bf322ef5c89
b538421a99fed7fa2a897a149bdbaebffe3c8a4a
173da409fbf0ec2364c03999bca65cb9c32e5ef0
f89f8550702044bb179e1795533a0394eee252ce
d26c5ac03eca2d00a186605faff7ff6b2d6f9be7
d7880ac47027213166abb74eadf480ce99f4c9b8
309bb76917a0aaac001feecbdf35f0b6bb6a64a7
5cbb14280d01d06a7c19c11906b3f4a92e3327bd
edb0e3074ab56f359bfdb34ae63501ea2297e5a3
We cannot bisect more!

[mxstbr]

Cannot replicate on current master, going to http://localhost:3000/keystone/post-categories?columns=id in the test-project (post categories don't have default columns) doesn't break anything anymore.

I'm going to assume this is fixed, but feel free to comment again if that's not the case!

[jstockwin]

@mxstbr there's literally a comment above with a command to run to reproduce the issue. Run that, and if it passes then the issue has been resolved.

[export-mike]

Tests added in the nightmare branch for any regressions. https://github.com/keystonejs/keystone/commit/73d144ebe825f761e5afdd2e5b91ab95bd01408c