What is the correct way to delete a submission after calling an integration? #1135
-
|
Hello, The scenario I am looking at is that when an integration is called successfully we want to delete the submission. This is all working except for the fact that after the deletion Formie wants to go back to the submission but it no longer exists. In my integration after the payload has been delivered and all is successful, I call Where it goes wrong is when I am in the GUI doing the following:
Am I calling the deletion method wrong? |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 4 replies
-
|
Right, so if you're triggering the integration when editing the submission from the control panel, you're definitely going to get a 404 error when trying to load the edit page of the submission again - because it will be gone! Your delete code looks fine to me, and that should work correctly. What would you expect to have happen? To be redirected to the Submissions index after running your integration? If so, that would be tricky. There's no guarantee that the integration will be run immediately (it's run via the queue after all) and you'd need to wait for that to be run before the submission is deleted. But in your case, it must be running immediately. I'm hesitant to add handling in that controller to redirect back to the submission index if the submission can't be found, because that's strange behaviour for regular use-cases. If I try and visit a submission in the control panel and it keeps redirecting me back to the submissions index, that might seem like a error. |
Beta Was this translation helpful? Give feedback.
-
|
Hello @engram-design I understand your point of view regarding the redirect. Not redirecting to the list view is fine for me. As for Removing the |
Beta Was this translation helpful? Give feedback.
-
|
Are you able to send through the full stack trace of the error? Not quite sure where that error is coming from in the scheme of things. And if you can post an excerpt of your custom integration class showing where you delete the submission, just so I'm replicating your setup. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the full stack trace of the error: The excerpt from my custom integration: public function sendPayload(Submission $submission): bool
{
try {
$payload = [];
$response = $this->deliverPayload($submission, 'jobs/' . $formValues['id'], $payload, 'POST', 'multipart');
Greenhouse::log($submission->id . ' ' . json_encode($response));
// This line fails with the session error
Craft::$app->getElements()->deleteElement($submission, true);
} catch (Exception $exception) {
\perfectwebteam\greenhouse\Greenhouse::log($submission->id . ' ' . $exception->getTraceAsString());
Integration::error($this, $exception->getMessage(), true);
}
return true;
}What might be good to know is that this is a form with 2 File Upload fields and the form is set to delete the files when the submission is deleted. Let me know if this is enough. |
Beta Was this translation helpful? Give feedback.
-
|
Ah right, so yes that makes some sense. How are you running your queue? This seems to be the error output when the integration is run via the queue, which is having issues with the session-removal. |
Beta Was this translation helpful? Give feedback.
-
|
I have actually tried both, via the GUI and via CLI. From what I understand the following happens:
When I then visit the queue via the GUI, I see it failed with the session error. I also tried not to visit the GUI and run |
Beta Was this translation helpful? Give feedback.
-
|
So running the queue via the CLI shouldn't throw any session issues, because we have guards setup to determine if it's a console command. The queue by default will run so long as you have a page open in the control panel. Just wanted to check your I've also been trying both, but unable to replicate it. But I can see the lines in the trace causing the issue (just seemingly not an issue for me): Bottom-up, running |
Beta Was this translation helpful? Give feedback.
-
That I was not aware of. So I redid my test, only have the CLI open. Here is what I did:
This is my I have set this to As you said, this won't be a problem running it via CLI. Just somewhat problematic via the GUI because the payload has already been sent in that case and we do not want to send it again. |
Beta Was this translation helpful? Give feedback.
-
|
Fixed for the next release. To get this early, change your Then run |
Beta Was this translation helpful? Give feedback.
Fixed for the next release. To get this early, change your
verbb/formierequirement incomposer.jsonto:Then run
composer update.