Core/dev#692 : Use url search arguments in Activity Search forms [sub-PR of #13651]

[monishdeb]

Overview

This is a sub-PR of #13651. This PR extends the fix and make all possible activity search filters to be used as a url arguments on forced search using 'Find Activity' or 'Advance Search'

Before

Search arguments didn't work

After

Behavior on advanced search and 'Find Activity' search form:

Comments

ping @eileenmcnaughton @colemanw @lcdservices

[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]

Can we please use the same approach on the activity form as in the grant search form which was the one where we experimented going down this track & also converting search date ranges

Note this takes 'strings' from urls - which means minimum validation so we will probably need to review from a security pov

[eileenmcnaughton]

this is an unrelated cleanup? we could get this change merged I guess

[eileenmcnaughton]

No, we should convert any date fields to datepicker first - e.g copy what was done on grant search. We don't want to build handling for the old format

[monishdeb]

@eileenmcnaughton can we discuss this patch? About what would be the best approach to include special fields, unlucky ones which didn't find its place in Activity.getFields API result

[eileenmcnaughton]

@monishdeb OK - my mine review focus at the moment is to get the Payment.create code consolidated so I'm not digging too deep into this as yet.

But, my goal would be to break this down & pick off the ones we can convert to using the existing methodology first & then look out how to handle some others. I'm imagining that those that can't be retrieved by getfields would be merged into those that CAN be retrieved by getfields within a line or 2 of that getfields call

There is a lot in this PR - the first file touched is the Activtiy_BAO_Query so we would want any changes to that file to be in it's own PR with a unit test. I wonder why we aren't sharing handing for tags with the main tags where clause - feels like repetition

[eileenmcnaughton]

This is pretty stale so I'm closing. I would note that the way we have been making fields url accessible is by adding them to the metadata - ie the 5 fields added to the form like this

  /**
   * Get the metadata for fields to be included on the activity search form.
   *
   * @todo ideally this would be a trait included on the activity search & advanced search
   * rather than a static function.
   */
  public static function getSearchFieldMetadata() {
    $fields = ['activity_type_id', 'activity_date_time', 'priority_id', 'activity_location'];
    $metadata = civicrm_api3('Activity', 'getfields', [])['values'];
    $metadata = array_intersect_key($metadata, array_flip($fields));
    $metadata['activity_text'] = [
      'title' => ts('Activity Text'),
      'type' => CRM_Utils_Type::T_STRING,
      'is_pseudofield' => TRUE,
    ];
    return $metadata;
  }

Are url accessible.

I took a quick look at adding tags - this would be the general approach - but it's not working yet

#14901