CiviEvent - Error registering through advanced search task #19127
Conversation
…vanced Search task
|
(Standard links)
|
5852941 to
833a247
Compare
833a247 to
93a8525
Compare
|
I made the changes in the three files that had additions and/or deletions. I then added the new file. After testing by placing two participants selected from a search into an upcoming active event, both events were correctly added to the records of the two participants. However, there was an error that came up upon saving the participants to the event:
Otherwise, the patch did work and the database was updated accurately. |
|
Wow - this is a flakey bit of code - we all get different errors. Still you are up & running again now - @totten I'm inclined to merge & release this as confirmed-to-be-better (although this is the version that worked for me & not you & different to the 5.33 pr atm) |
Yeah, this one has had it tough at QA. For me, there are a few distinct issues which all produced a similar symptom. I think this helps explain the mixed signals we've been getting. Symptom: The registration-form is supposed to show a bunch of fields (e.g. pricing options, e.g. payment tracking, e.g. custom-fields) which depend on the specific event. These fields are displayed progressively (via AJAX) while you fill-out the form. If the AJAX call fails, then the fields don't show up. At first glance, you may not even notice this problem. (I didn't notice when first testing the same patch on 5.33...) The form still looks plausible. The error isn't displayed in real time. You can even submit the form, and it will create a Recap: The symptom is that fields are missing from UI because an AJAX call to Causes and Fixes: The symptom has had a few causes: (1) There's the "getFieldValue required" error which @timindaburgh pointed out. This seems to be a reliable problem. I've seen it locally on multiple workstations/builds and on the autobuild test site, and I believe it's what Eileen noticed in r-running another patch. The problem arises because this form uses a helper ( (2) (3) The AJAX request for |
… URLs When use the search-task to register event participants, the qfKey is mismatched, and the action is VIEW. It should be ADD, and the qfKey should be for CRM_Event_Form_Participant.
…ative) When preparing the event-registration form, `CRM_Event_Page_Tab::preProcess()` looks up the designated contact ID and calls `checkUserPermission()`. The error message is (effectively) reporting that the permission-check fails because there is no contact ID. And this is a legit thing to complain about -- if you're embedding the event-registration form as part of a search-task, then there is no *singular* contact ID. (There is a potentially very long list of contact IDs - which is probably stored/reported some other way.) The permission-check for this context seems like it ought to be different. I labeled the commit (tentative) because I'm not entirely certain that I understand the contract of this route/controller. It has multiple overlapping use-cases, and I'm not certain if I've tracked them all. However, this patch does seem to fix the "getFieldValue failed" problem when running as a search-task.
|
Did a final Merging this as near-term fix per MM discussion. Eileen's aiming to do a cleaner/separate route for this in |
port #19125