Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calls (like TwingleDonation.cancel) fails if contribution is not found #30

Open
bjendres opened this issue Jun 16, 2020 · 6 comments
Open
Labels
enhancement New feature or request

Comments

@bjendres
Copy link
Member

If the contribution with the given Twingle-ID is not found, the API returns an error. That might sound like the proper response, but this behaviour causes Twingle to submit the same request over and over.

There might be a point in flagging this issue to a user (e.g. by E-Mail) and returning an "ok" in the API.

@bjendres bjendres added the enhancement New feature or request label Jun 16, 2020
@jensschuppe
Copy link
Collaborator

jensschuppe commented Jun 16, 2020

To me that seems to be an error-management issue for Twingle, not necessarily for the CiviCRM API, since how to handle that will highly depend on what your workflows are: activities, e-mails, ignore, ...

Also, reporting by e-mail does not stop Twingle to re-send it again and again. Twingle users should really be checking those error messages regularly. Maybe this could be outlined in the API docs.

@bjendres
Copy link
Member Author

To me that seems to be an error-management issue for Twingle, not necessarily for the CiviCRM API, since how to handle that will highly depend on what your workflows are: activities, e-mails, ignore, ...

I agree, but that's the way is currently implemented: if there is an error: re-submit with the next batch.

Also, reporting by e-mail does not stop Twingle to re-send it again and again.

Yes ist does, if you don't return an error any more.

@jensschuppe
Copy link
Collaborator

Also, reporting by e-mail does not stop Twingle to re-send it again and again.

Yes ist does, if you don't return an error any more.

Agreed. What happens in CiviCRM should be configurable then, because not throwing an error will make it vanish from CiviCRM logs as well. I see the following options:

  • Ignore
  • Log to the CiviCRM log
  • Schedule an activity
  • Send an e-mail
  • maybe plug into other systems (trigger a CiviRules event, execute an action-provider action, etc.), maybe provide a hook.

@jensschuppe jensschuppe added this to the 1.3 milestone Jun 26, 2020
@bjendres
Copy link
Member Author

bjendres commented Jun 29, 2020

Will be released with 1.2

Sorry, my bad, 1.3

@bjendres bjendres reopened this Jun 29, 2020
@webworka
Copy link

For Information from the twingle side: We released last week an update on the interface that we ignore this error on our side.

Normally the handling is that if an error is given back vom CiviCRM we will send this request again. In this case, this makes no sense.
I also found another error which we now also ignore: "SEPA Mandate xxxx already terminated". From the twingle point of view this is the same type of error, that should not cause the interface to stop.

@jensschuppe
Copy link
Collaborator

@webworka Thanks for reporting back here, too!

I think it would be reasonable, though, to clarify the error messages as a first step, because ignoring errors is not a good thing in general, and those come from the CiviCRM core API and are not necessarily bound to only those two events. Ultimately, we should not issue errors back to you (Twingle) in that case at all, but handle such inconsistencies within CiviCRM.

We will be implementing the e-mail thing as a second step, so that admins can be notified and Twingle does not need to care about that anymore.

@jensschuppe jensschuppe removed this from the 1.3 milestone May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants