Convert Campaign widgets to entityRef

[colemanw]

Overview

Cleans up the code and UI for selecting a campaign. Instead of a select list with a button to load past campaigns, now the entire list of campaigns is searchable and filterable. New campaigns can be created on-the-fly.

Before

Ugly message when there are no campaigns.
Button to load past campaigns.
No way to create a new campaign without leaving and reloading the page.

After

New widget can filter out past campaigns and create new ones on-the-fly, so no need for the ugly message or the "show past campaigns" button. The widget also displays the campaign type, status, and dates in the results.

[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).

[colemanw]

@JoeMurray I believe you were involved in creating the "Show past campaigns" button. Can you review this improvement?

[colemanw]

@civicrm-builder retest this please

[colemanw]

@civicrm-builder retest this please

[colemanw]

@civicrm-builder retest this please

[JoeMurray]

I'd like to review how this runs in browser, eg the Refine search. From what I can see this is an area where there were opportunities to make a nice usability improvement.

Pls remind me what the admin password is on the auto-build test sites? Thx.

[JoeMurray]

I think commit cbb17d3 would be better in its own MR.

[colemanw]

I think commit cbb17d3 would be better in its own MR.

Done. #13503

[JoeMurray]

I don't know the criteria/process for removing 'AJAX' functions from core. With regular functions in core, there is a fair bit of leeway given the main contract is the API layer. But I imagine developers have been treating anything in an 'AJAX.php' file as fair game for them use, like CRM/Campaign/Page/AJAX.php. If so, then removing functions may require some notice time for deprecation. In particular, I would guess there are extensions out there that allow new entities to be associated with Campaigns, so they might use this function allActiveCampaigns(). Comments @eileenmcnaughton ?

[colemanw]

@JoeMurray I appreciate your attitude of caution about removing the ajax callback, but in this case an api does exist to cover the function - any extension developer wishing to fetch past campaigns can simply use the Campaign api, which has existed for many years. In the (IMO very unlikely) event that someone out there has (a) managed to actually find this obscure function and (b) decided to ignore every piece of advice in our documentation which says avoid internal functions and use the api... I'd have to say they've been warned.

[JoeMurray]

@JoeMurray I appreciate your attitude of caution about removing the ajax callback, but in this case an api does exist to cover the function - any extension developer wishing to fetch past campaigns can simply use the Campaign api, which has existed for many years. In the (IMO very unlikely) event that someone out there has (a) managed to actually find this obscure function and (b) decided to ignore every piece of advice in our documentation which says avoid internal functions and use the api... I'd have to say they've been warned.

I'm betraying my ignorance around what functions in AJAX.php are considered 'callable' by extensions. I'll defer to you.

[JoeMurray]

This MR improves the UX. It replaces many lines of code with a small number of more elegant ones that provide a path for similar cleanup elsewhere.

I tested the campaign widget on Add Activity and Edit Activity and Add Contribution and all worked properly. I tested the filtering options and all worked nicely.

The create links for adding new contacts on the Address sharing widget were not properly filtered. As mentioned above I'd prefer to see that moved to a different PR.

If that is fixed or moved out of this MR then I'd say this is ready to merge.

[colemanw]

Thanks Joe. What problem did you run into with the shared address widget?

[JoeMurray]

My comment above is still pending, I think due to them being on a line removed by a force push from Coleman. Here they are repeated.

Removing CiviCRM: add contacts perm from all role, logging in as demo user (as opposed to admin user 1 which has all permissions), then editing a contact, I see

However, as expected, clicking on the New Individual, New Organization, and New Household links, an error is displayed:

Could you fix so that the create links are not displayed for users without the correct permissions? It might be appropriate to move this to a different MR.

[colemanw]

Thanks @JoeMurray - I just tested and found the problem is preexisting and not related to this PR. So I'll open up a new PR to solve that issue and merge this based on your review. Thanks!

[eileenmcnaughton]

@colemanw I've deployed this & I'm not loving it - I think it was totally broken when I first used it, but then I realised I could find my campaign

I think the issue is the fact there is no pre-population of a list so it seems like none exist - I'm pretty sure there is a param for that that you turn on & off in other entity references to make it feel a bit more like a select when you load it?

[colemanw]

@eileenmcnaughton yes we could enable that mode. However it would make the filters harder to find (they'd only appear if you get no search result).

[eileenmcnaughton]

@colemanw hmm - I guess what people will find more convenient will depend on how many campaigns they have. However, it would be tough to use for our org by anyone other than me - ie. I know what campaign I'm gonna search for but I think others wouldn't have a clue until they see a list.