Problems with search form behavior inside a dialog

[GinkgoFJG]

I'm using CRM.loadForm to load a custom search into a dialog. Ultimately, what I'm trying to do is:

• Load the search form
• Allow the user to run a search
• Allow the user to select some number of contacts from the result set, and choose a custom task from the actions menu
• Listen for my custom task in hook_civicrm_postProcess and add some stuff to $form->ajaxResponse
• Listen for CRM.loadForm's crmFormSuccess event and do stuff with $form->ajaxResponse

This has been a little more challenging than I expected. I'm stuck on #2.

Loading the search form was no problem. When I submit it, however, the dialog closes. (This is also the case with the core "Find Contacts" search, which is not a custom search.) I tried adding

Code: [Select]

autoClose: false to the CRM.loadForm parameters, but this had no effect.

By inspecting the params on the callback to the crmFormSuccess event, I learned that the button name for the search forms is "refresh." So I tried again, this time passing

Code: [Select]

refreshAction: ['refresh'] to CRM.loadForm. This doesn't work either; the userContext in the AJAX response is wrong (I get "/civicrm/event/manage?reset=1" regardless of where I open the dialog). The dialog stays open, but the content is unexpected. "Okay," I say to myself, "this doesn't feel right, but let's set the userContext manually. And let's keep things simple by using Find Contacts instead of a custom search." So I listen on hook_civicrm_postProcess, and when the conditions are right, I do:

Code: [Select]

$qfKey = CRM_Utils_Array::value('qfKey', $form->_submitValues);
$form->ajaxResponse['userContext'] = '/civicrm/contact/search?_qf_Custom_display=true&qfKey=' . $qfKey;

Good news: when I submit the form, the dialog refreshes and the search results are displayed. I can search multiple times, and the dialog stays open. There seems to be a minor JS issue; I can select an action in the task list without first hitting a "Select Records" radio button.

Bad news: the behavior is different for custom searches. To rule out issues with my custom form as the root of the problem, I tested with a core custom form; I arbitrarily picked Zip Code Range. As a result, my hook_civicrm_postProcess code now looks like this:

Code: [Select]

$qfKey = CRM_Utils_Array::value('qfKey', $form->_submitValues);
$form->ajaxResponse['userContext'] = '/civicrm/contact/search/custom?_qf_Custom_display=true&csid=10&qfKey=' . $qfKey;

The first time I submit the custom form, it is refreshed with search results. After that, I can't submit the form again. If I change the search criteria and hit submit, the CiviCRM spinner appears for a hot second, but the search criteria are returned to their original state and the search results are not refreshed. Moreover, crmFormSuccess isn't raised again, hook_civicrm_postProcess doesn't fire, and Civi's error logs are clean. The custom form is afflicted by the same JS issue as the "Find Contacts" search; I can select an action in the task list without hitting a "Select Records" radio button.

Any idea what's going on with the custom searches? Or why putting a search in a dialog doesn't Just Work^TM?

Thanks!

[Coleman Watts]

The main reason I can think of that you can't put search in a dialog is because the search results page is hard-coded to not work in a dialog. Search is a full-screen-only sorta thing because it's the launchpad for a bunch of dialogs. It requires certain scripts which it loads into the document header specifically to prevent them from getting passed through snippets.

If you're not put off by all that and want to keep pursuing this I'd be happy to have a more in-depth discussion about it and see what we can come up with.

[GinkgoFJG]

[facepalm]I took the custom search approach because it seemed most expeditious and because I didn't want to reinvent any already-existing wheels.[/facepalm] I've already started down a rabbit hole of custom-search related issues, but if it's a deep hole (and it seems from your post that it is) I'm not interested in continuing to dig.

Would you agree that client-side MVC would be a more fruitful approach? It seems a little wasteful to rebuild a form that already exists, but I am jumping through more hoops than I expected to be. In some ways a client-side approach is a more straightforward.

[Coleman Watts]

The new popup stuff in 4.5 works to embed *most* forms in a popup. You've found one that doesn't :/
Other big exceptions are the contact summary screen, and the reports interface (although report results minus the rest of the interface can be embedded in a popup).

Can you say a little more about the context? What kind of search params are you needing? If they are all supported by advaced search (which uses the same query buider as the Contact API) then the whole thing could be done clientside via api calls.

[GinkgoFJG]

Everything I need is supported by advanced search. I guess I'll change course and handle this clientside. The context is that I'm trying to give CiviVolunteer users a way to populate needs by searching contacts based on custom fields (e.g., I need volunteers with a skill level of X or better in skill Y). Thanks.