`defaultColumns` has no effect in collections

[iamlinkus]

Pulled the latest payload-3.0-demo repo, modified the default users collection like so:

    {
      slug: 'users',
      auth: true,
      access: {
        delete: () => false,
        update: () => false,
      },
      admin: {
        defaultColumns: ['email', 'createdAt'],
      },
      fields: [
        {
          name: 'date',
          type: 'date',
        },
      ],
    },

Nothing changed in the admin panel. Seems like defaultColumns get completely ignored. Tried rebuilding, cleaning out cache... nada.

On a fresh and clean db, no preferences set anywhere.

[denolfe]

Reproduced w/ the demo repo, but could not within the monorepo's test suite. Not sure why that would be different.

[denolfe]

It looks like the only way to get these changes to be reflected is a DB drop. My suspicion is that we're persisting this in prefs collection somewhere, and that needs to be cleaned up.

[DanRibbens]

Correct, collection list columns are set in user perferences.

Deleting a user will drop all preferences. We should consider adding to the UI a reset preferences option from the account view. Giving admin users this ability would be much nicer than having to delete records from the database, especially if it is in production.

[iamlinkus]

Are preferences set even when the user never actually changes the preferences? When I was testing it was ok a clean install and fresh db, while the admin panel hasn’t been touched apart from just navigating to the users collection page without touching anything else and even then it had no effect, defaultColumns did nothing. Removed any automatically added preferences to the db, and still notiing. I don’t think it’s where the issue is, unless preferences are stored somewhere else and they’re set automatically even without the user touching the column preferences on the admin.

[DanRibbens]

I believe the defaultColumns are saved as the user's "preference" when they initially hit the collection. It is something I've wanted to remove so that defaultColumns are never persisted this way, but haven't had the time to do.

If you really are coming in after having deleted all preferences records, then I don't know what the situation would be. Is there a possiblity that the API response is being cached or something else unique to your setup?

[iamlinkus]

Yup, double-checked. First time the user opens the collection list view, prefs are added to the db. Removing the prefs from db and restarting with devsafe the defaultColumns works (unless you then again change it through the config). Prefs shouldn't be set if the admin user doesn't explicitly modify the list view.

[JarrodMFlesch]

The recommended change has been made, now column preferences will not set until they are adjusted. The ability to reset preferences would be a future feature request as it would require some design effort. Thanks for the feedback!

Related PR

Will be available in next v3 beta release.

[github-actions[bot]]

This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.