Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
F
Feature request
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Community
  • Feature request
  • Issues
  • #19

Closed
Open
Created Jun 12, 2019 by totten@tottenOwner

General convergence in the searching space (needs:planning)

There are multiple frameworks dealing with the search space:

  • Contact Query BAO / Advanced Search / Search Builder
    • Note: Profile is used as a storage model for the selection of fields from Contact BAO Query
    • Note: Smart Groups use a Contact Query BAO criteria as a storage model for the search
  • Custom Search
    • Note: Custom Search extends the frontend/controller system from Advanced Search but it completely replaces the underlying search-mechanism. This gives access to some functionality (like Smart Groups) but not other (like customizing columns via Profile).
  • Other QuickForm/Selector Searches (Find Activities; Find Contributions)
  • Export
    • Note: Import/Export Mappings are used as a storage model for the selection of fields from Export. These are similar to Profile, except they include support for traversing relations.
  • CiviReport
  • APIv3/ APIv4 / API Explorer
  • SQL Tasks

To some extent, there are distinctive features in each of these areas. However, I find it questionable that these distinctive features are enough to merit the separate subsystems. Example:

  • The traditional Export subsystem is built on the Query BAO and other QuickForm Selectors. But it's not used for reports.
  • The report subsystem doesn't integrate the standard contact tasks. Arguably, this is because many reports deal with different record-types. However, one could reasonably expose search tasks in a reported -- provided you match on the type of the record in each row.
  • One can figure out how to run a quirky search using either CiviReport or the API. But if one wants to use that same search to define a smart-group, it wouldn't work.
  • If you're reading the civicrm_saved_search behind a Smart Group, it's difficult to find documentation/explanations for the semantics of those fields.
  • There are code-generators for some things (like API entities and API actions and Reports) but not others (like Search Tasks)

A couple example opinions:

  • I like APIvX.get as a layer for defining query-backend. The main gap in using it as the backend for all the above subsystems is the lack of aggregate/group functionality.
  • A search-task is basically an APIvX action plus (1) a bespoke form for tweaking the inputs of the action and (2) a declaration/registration of when to display the search-task.

It's not clear that a total convergence is sensible, and this one Gitlab issue shouldn't be responsible for every detail, but it makes sense to have some space to record general/broad discussion about the convergence of these subsystems.

Edited Jul 19, 2019 by totten
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None