(feat) Add defaultSelect Option to Collections (similar to defaultPopulate)

[matthijs166]

Currently, Payload supports defaultPopulate on collections, which allows defining default population behavior for queries. However, there’s no equivalent for the select property.

Feature Request:
Introduce a defaultSelect option in the collection configuration that works similarly to defaultPopulate, but for field selection. This would allow developers to specify a default set of fields to include (or exclude) when querying a collection, without having to manually pass select in every request.

Use Case:
In our admin panel, we have several calculated fields that depend on joins. While this is fine for an individual item view, it’s inefficient for the overview list (e.g., Orders overview), where we don’t want to query all the joined data.

With defaultSelect, we could:

• Reduce unnecessary data fetching in list views
• Keep queries lean without repeating select logic everywhere
• Still allow overriding select in individual API calls when needed

[dolanoadriano]

+1

[tlmader]

Related to my question in the Discord:

Is there a recommended way to prevent a field from being returned by default by Local API and REST? We are thinking of storing vectors in an existing collection's field, but want to only include it in responses if specifically asked for. I'm guessing custom access control can be used for this but wondering if there's a better way.

[PlagueFPS]

This is a great idea. However, I'm curious about how it would work with join fields, since those display the default columns of that collection. If this is implemented, it would need to comply with the defaultColumns config or just return null for those fields. I can see it going either way.

I think personally, I'd prefer the defaultColumns to act as the pseudo defaultSelect, with id always being returned. What do you think?