allow Search Displays to use all columns from their Saved Search

[ufundo]

Before

• Search Displays (except the default display) always have a separate list of columns from their Saved Search
• this starts off being all the columns, but then diverges if the Saved Search changes
• if you add a column to the Saved Search, you have to add it to any Search Displays based off it manually
• you can get round this using the Default Search Display, but then you can't tweak the search settings

After

• by default new table displays will show all the columns from its Search
• you have the option to customise the columns if you want
• pre-existing search displays will be treated as having custom columns defined

Technical Details

The motivation here is that, unlike the other table settings for headers/tallies/actions etc, the Display columns somewhat duplicates the Search Display it depends on.

Comments

This is useful for reporting. You can generate a Managed Search Display which includes a somewhat dynamic list of Custom Fields (like https://lab.civicrm.org/extensions/search_kit_report_starter_pack/-/merge_requests/30), and you can create a Search Display that show them all.

It's first step on an alternative to #33959 .

TODO:

• permissions issue to fetch the default display if you dont have Access CiviCRM
• it might be nice to allow a sort of hybrid mode: tweak the display for a few specific columns, use defaults for all the rest

Demo:

Screencast.from.2025-11-28.17-40-16.mp4

Note how currently adding those columns after you create the display requires adding on the search, then going to the display and adding the column from the dropdown.

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[colemanw]

Ohh, nice use of the Toggle element!

[ufundo]

Ohh, nice use of the Toggle element!

Haha there are all of a sudden toggles absolutely everywhere 😁

[colemanw]

• debug

[ufundo]

oops. fixed

[colemanw]

@ufundo this is a neat idea but I have to wonder, if a display uses the default columns, then what's the point of creating the display? Aside from a few other settings (header/footer, etc) the bulk of display configuration is the columns themselves. I would guess that 90% of users who create displays do so to configure the columns: rename headers, rewrite text, add in-place edit, configure links and buttons; all that stuff is lost with that toggle.

[ufundo]

if a display uses the default columns what's the point of creating the display?

In broad terms this is a step towards making the default search display more like a normal display rather than a magic thing.

Currently if you want to use a search, you have three choices:

a) use the Search Display listing page - but then you can't add filters, can't give it custom permissions, can't use the afform placement tags to make dashboard widget, include in the listing

b) you can create a display, and put it in an afform. That's 2 extra steps, and your columns get fixed. If you add new columns to the search, you have to add them to the display as well, which is faff. If we enable adding [all custom fields] to a search, the display isn't going to adapt

c) if you use the default display, you can't make any edits to the headers/actions etc. If at a later point you decide you do want to customise the display of the columns, you can't. You have to create a display, try to update your afform to use it, it's a faff.

I think adding a setting like this makes (B) work. It also means we could start to phase out (A) and (C) so that (B) is the easy common path which works for all cases, compared to at the moment where we have 3 slightly different ways to view a search kit listing, each with slightly different limitations.

[ufundo]

it might be nice to allow a sort of hybrid mode: tweak the display for a few specific columns, use defaults for all the rest

This could be a nice follow on. But I think it does require a three way control, which is never great from a user perspective.

You'd need 3 modes:
fully custom - existing behaviour, only display columns defined in the display
fully automatic - ignore columns defined in the display, just show the default columns from the search
semi-automatic - start with the default columns from the search, but add/overwrite with any columns defined in the display

Having said that, maybe a column_mode would be better setting key than the boolean currently in this PR.

[colemanw]

towards making the default search display more like a normal display rather than a magic thing.

Yea, there's even a difference between the defaults and the magic thing. In your screencast you can see that extra unlabeled column with hamburger menus for edit/delete/disable actions. But if you flip the toggle to enable custom columns, it disappears.