SearchKit - Add links/menus/buttons to search displays

[colemanw]

Overview

New SearchKit feature gives the ability to configure sets of links, buttons, or menus in search displays.

Here's an example of adding a menu to a display:

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@colemanw I can't see how to configure these - this screen shot is from the test site created by this PR - should it be here?

http://core-19673-7eotb.test-1.civicrm.org:8001/civicrm/admin/search#/edit/1

[dptarrant]

Found them under the +Add button. I think this is overkill at the risk of confusion. Not even sure how I got to this display

.
I don't think there would be a lot of row by row decisions to Delete, Edit, etc. Linking Contact name to the contact seems to be the path that would be safer and sufficient. What am I missing?

[colemanw]

@dptarrant, err yes I would say that adding 3 sets of links to your table is indeed overkill! One would be sufficient :)

The purpose of adding this feature is to bring us closer to being able to replace tabs on the contact summary screen with search displays. For example, the Activities tab can be completely rewritten as a search display, but it requires this feature to add the links on the right.

[dptarrant]

right, back to my bias - complex being possible is great, but not at expense of simple. Devil in the UI details. Broad potential usage of the capability is also great, but not needed for this particular use case - IM(not so)HO. Can we hide more things under the hood for Version 1?

[colemanw]

Sorry @dptarrant I don't understand your comment. This PR adds a single unobtrusive button to the SearchDisplay configuration screen (so unobtrusive that @eileenmcnaughton couldn't find it in her own screenshot :) ). Also, I don't understand what you mean by "not needed for this particular use case"... I just explained, in words and with a screenshot, why this feature is needed for this particular use-case.

I think you might be confused about how the PR review process works. "Hiding more things under the hood" is a great idea, but that's not what this PR is for. To review this particular PR, you would try out the new feature and report whether or not it works. If it works but you have suggestions about how to improve it further, we could merge this PR and then open a new issue for your suggestions.

[dptarrant]

got it. hard for me to stay within the lines.

[eileenmcnaughton]

OK - I see it now - I agree it IS unobtrusive. But I also think these links will be important for some screen replacements and since we use all 3 currently.....

One thing that I think we will want to work on is exposing more actions. That is a bigger question than this PR & will take a bit of leg work to get to but we have an underlying mess around bulk actions vs individual actions - ie lots of bulk actions would ideally be available as individual actions. At the point when we solve that we might want to be able to choose which individual actions to expose as links etc. That's very much 'down the road' though