CiviEvent - Error registering participants via search task #19125
Conversation
|
(Standard links)
|
CRM/Event/Form/FormBlock.php
Outdated
| @@ -0,0 +1 @@ | |||
| <?php | |||
There was a problem hiding this comment.
@eileenmcnaughton why is this needed?
There was a problem hiding this comment.
arg - the extra files would be part of the bigger fix - but the 2 small changes you might like to pull into your PR & I'll close this
totten
changed the title
eileenmcnaughton
force-pushed
the
ev533
branch
2 times, most recently
from
71bb192 to
63b91d5
Compare
totten
changed the title
eileenmcnaughton
force-pushed
the
ev533
branch
from
63b91d5 to
91487ea
Compare
|
OK, when I But... I fill out the form like so:
The first time, it submitted but displayed this error:
Which was weird. I figure maybe a fluke or some other hackery on my local, so I tried again. Again, it creates the registration (yay) but produces an error:
The second error seems to be more stable - i.e. it showed up again on the 3rd and 4th tries. |
eileenmcnaughton
force-pushed
the
ev533
branch
from
91487ea to
1db1f8e
Compare
… 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.
|
There's more discussion/debugging in Mattermost log. @eileenmcnaughton I've pushed up a change which (1) ensures the However, I don't think we can get further review+backport tonight. (We'll punt backport to 5.32.2.) |
CRM/Event/Page/Tab.php
Outdated
| @@ -90,7 +90,7 @@ public function edit() { | |||
| $controller = new CRM_Core_Controller_Simple( | |||
| 'CRM_Event_Form_Participant', | |||
| 'Create Participation', | |||
| $this->_action, FALSE, FALSE, TRUE | |||
There was a problem hiding this comment.
The removal of this TRUE has caused the 500 console error that I added it to avoid to come back. The other symptom is the fees not loading.
There was a problem hiding this comment.
That's weird. I was seeing the opposite - even with ignoreKey=TRUE here (PR-branch without df80fba), the AJAX call replied 500 and the fees subform didn't render. With df80fba (with a valid key -- and with ignoreKey=FALSE), the AJAX call and the subform worked.
I wonder if there might be some subtle difference in the pageflows or use-cases that we're trying?
There was a problem hiding this comment.
@totten maybe - I have a good idea of a better fix - but we need to get 'something' out - to be honest I can't understand how the key would be rejected if ignoreKey is false
I am doing a basic search & then selecting some contacts & choosing register participants
I did test that on the pr test site & it failed
There was a problem hiding this comment.
FWIW, my procedure is very similar, ie
- Open advanced search
- Search for all contacts (no criteria)
- Check the first "Individual" in the demo data ("Adams, Heidi")
- In the task list, choose to register
- For the event, choose any of the three demo events (eg "Rain-forest Cup")
@eileenmcnaughton I can reproduce the error that appears on the test site. (Incidentally, I'm doing this on a different workstaiton/build.) Notably, in both test site and local, the 500 error is not related to qfKey. It's about "getFieldValue failed" (which curiously arose before but had seemed transitory). Here's a backtrace.
The thing is... to my reading, it's basically saying that the event-registration form's preProcess() is applying a mismatched security check. (It's trying to use a contactId and CRM_Contact_Page_View::checkUserPermission() -- but in the context of a search-task, it doesn't make sense to use a singular contactId for assessing permissions on a bulk action.)
I've pushed up another patch which fixes this symptom for me, but it definitely needs some more eyes to see if it's faithful to contract/permissioning of this route/controller.
There was a problem hiding this comment.
@totten given that
- the person who has reported this has applied the patch in the 5.32 branch & says it is working and
- we are pretty clear none of this is the final fix
I'm inclined to merge what that person merged & work on the right fix in master
There was a problem hiding this comment.
The report on 5.32 PR actually pointed to the same problem raised here (just a diff part of the manifestation -- the HTTP 500 error you noted above is the same "getFieldValue required" error he observed) - I think they just didn't realize that the screen was misbehaving (because it's a misbehavior of omission; because the immediate error-message is hidden in AJAX console; and the UI-level error message is delayed). So the revision they tested wasn't working.
Added some more comments over there to try to distinguish 3 issues floating around here.
To my testing, the current revision of this branch addresses all 3.
…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 |
Overview
This aims to fix smarty fatal error on using a search-task to register contacts for an event. Steps to reproduce:
Before
Form does not display. There's a Smarty error.
After
Form displays. No error.
Comment
This is an expansion on the prior draft #19118. It is working for me but I think warrants a better fix in master (separate the forms)