-
-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SearchKit - Add display of type entity
#25871
Conversation
(Standard links)
|
e76430b
to
0ad5bcc
Compare
That is super powerful. One thing that will catch us out if we use it is indexes, or lack thereof - I'd probably err on adding indexes to all fields over none given the search context |
"missing some UI niceities like a button to fill or refresh the table" - I would add to that list a date when the table was last refreshed |
0ad5bcc
to
de0cac9
Compare
I'm not sure what to make of the test failures, every single one of them passes for me locally 🤷 |
53abb14
to
06f5950
Compare
retest this please |
fdb2ecd
to
1626676
Compare
Trying to figure out what's wrong here... retest this please |
74085eb
to
8ab2a43
Compare
Just noting that snapshot groups are a baby version of this - a realised form of smart groups. |
8ab2a43
to
2e30fda
Compare
retest this please |
Yay! Tests pass! However this PR still feels like a draft because of limitations and usability issues. I've updated the description with a todo list. |
Great
As I'm assuming a Scheduled Job can be setup to make that call, it feels ok as a first proof-of-concept. Given the amount of data this exposes, and permissions it bypasses, perhaps there's an argument it shouldn't be too easy to use yet?!
That would be good.
Could there be a new date column in |
All outstanding issues have been addressed. Indexes, preview, refresh, scheduled job & last-refresh-date are all working now. Unit test added. |
@colemanw not so fast api\v4\SearchDisplay\EntityDisplayTest::testEntityDisplay /home/homer/buildkit/build/build-0/web/sites/all/modules/civicrm/ext/search_kit/tests/phpunit/api/v4/SearchDisplay/EntityDisplayTest.php:81 |
Ah the joys of SQL dialects and their subtle differences. In Canadian SQL it would be |
An entity display does not produce user-facing output, instead it writes to a SQL table which can then be queried from SearchKit, the API, or other SQL-based tools like Drupal Views. The new table is static; this includes a scheduled job to refresh it (disabled by default).
That looks really powerful. I could successfully create a 'DB Entity' from a search, and then I could build a search based on that entity and create a table, list and grid. However, trying to create a smart group produces |
ok let's merge it then! |
Overview
Note: Description is updated to reflect latest status of the PR. Discussion thread references earlier drafts.
Adds a new display type "entity" which does not produce user-facing output, instead it writes to a SQL table which can then be queried from SearchKit, the API, or other SQL-based tools like Drupal Views.
Technical Details
refresh
action and agetRefreshDate
action for checking the last refresh date