Skip to content
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 - Allow SearchSegments to be packaged as .mgd.php #23578

Merged
merged 1 commit into from
May 26, 2022

Conversation

colemanw
Copy link
Member

Overview

This allows SearchSegments to be packaged and distributed in extensions, along with Saved Searches and Search Displays.

Comments

This would allow, e.g. a SearchKit-based Case Dashboard to be packaged.

@civibot
Copy link

civibot bot commented May 25, 2022

(Standard links)

@civibot civibot bot added the master label May 25, 2022
@aydun
Copy link
Contributor

aydun commented May 25, 2022

Tested - works!

Could SavedSearch.export also include segments used in the search?

As search kit usage grows, there could be lots of segments. It would be useful to have some sort of grouping or owner of these, possibly like OptionGroup/OptionValue. Relatedly, it would be convenient to allow the API export function to take more than one id, - or a group id.

@aydun
Copy link
Contributor

aydun commented May 25, 2022

The SearchSegment.export produces names like 'SearchSegment_Status_Ongoing' whereas the SavedSearch.export references 'SUM(segment_Status_Ongoing:label)' It would be helpful to have consistent naming.

@colemanw colemanw merged commit b5d09e9 into civicrm:master May 26, 2022
@colemanw colemanw deleted the managedSearchSegment branch May 26, 2022 01:08
@colemanw
Copy link
Member Author

Could SavedSearch.export also include segments used in the search?

That would be nice. Tricky but nice.

It would be useful to have some sort of grouping or owner of these, possibly like OptionGroup/OptionValue.

I'm not sure how common the trick from https://lab.civicrm.org/dev/core/-/issues/3477 is going to be. Generally speaking, a data segment is kind of both. It's an option group with a bunch of option values, and I think most of the time a single segment with multiple options will do the job. I'd guess it's pretty rare to have to create a bunch of search segments that all belong together.

The SearchSegment.export produces names like 'SearchSegment_Status_Ongoing' whereas the SavedSearch.export references 'SUM(segment_Status_Ongoing:label)' It would be helpful to have consistent naming.

That's just the name of the Managed record. The name of the segment itself is consistent. Managed names are their own beast, and generally don't match the 'name' of the record itself.

@aydun
Copy link
Contributor

aydun commented May 26, 2022

Ok, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants