SearchKit - default displays and ACL-aware links #21929
Conversation
|
(Standard links)
|
colemanw
force-pushed
the
searchKitDefaultDisplays
branch
from
de72630 to
b2f8959
Compare
…lculate links by entity+action This adds a SearchDisplay.getDefault APIv4 action, which autogenerates the default table display which is used on the admin screen. It also refactors links so they can be calculated based on a given entity+action which does not require paths to be stored in the search display.
… path Now that SearchDisplay.Run understands this new link syntax, the admin UI can use it too. The old links set in existing search displays will still work, but in order for ACLs to be checked they need to use the new syntax.
Remove clutter if an org does not use tags. Also removes an unused copy-pasted function.
colemanw
force-pushed
the
searchKitDefaultDisplays
branch
from
b2f8959 to
dea3eed
Compare
Adds a 'view' link to the searchKit admin listing, which links to the default display Adds a 'view' dropdown to the compose search screen, with links to the default + all other displays Updates Afform to work with default search displays
colemanw
force-pushed
the
searchKitDefaultDisplays
branch
from
dea3eed to
5c952e5
Compare
|
I tested this & it seems to work well. The annoyance I continue to hit is that the label has no defaults & is not near the 'save' button - not sure what others think but I would move it & also give it a default Anyway - I was able to see the acls working fine & the save worked. However, the checkboxes to select individual contacts don't seem to be selectable (I have the follow up formatting PR applied locally). I seem to be able to replicate this locally with the admin user too so will try on the test site
|
|
@colemanw check http://core-21929-1mu15.test-3.civicrm.org:8001/civicrm/admin/search#/edit/1 - the rows cannot be selected for actions |
|
Thanks @eileenmcnaughton - I think the action checkboxes might have been broken by the previous refactor but anyway I've pushed up a fix to this PR. |
|
@eileenmcnaughton I've pushed up a default label for search displays as well, just for you :) |
Lifts the assumption that every entity has a key column named "id"
colemanw
force-pushed
the
searchKitDefaultDisplays
branch
from
ac0c0b2 to
d4381c0
Compare
|
The defaults kick in on the add display - not the original screen - which was the one that I was thinking of above. Action links work now - merging |
|
unrelated test fails |
Overview
This gives every SavedSearch an auto-generated table display, and makes use of it in the UI to more conveniently view or embed a saved search without needing to manually create a display. In the UI it's referred to as the "Search results table" to emphasize the fact that it's the same table as shown on the "compose search" screen, and is not configurable like other displays.
In the process I refactored the way links are understood by SearchKit to take ACLs into account.
Before
After