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

Add TwingleShop setting for defining the contribution type of "additional donation" #102

Open
MarcMichalsky opened this issue Sep 18, 2024 · 0 comments

Comments

@MarcMichalsky
Copy link
Contributor

I was just made aware by our fundraisers that there is an option in the TwingleMANAGER to define another product for "additional donation" at the very bottom of the page for the donation shop products.

Bildschirmfoto vom 2024-09-18 17-15-54

Unfortunately, Twingle does not return this product together with the other products from the project API under the endpoint products. However, the "additional donation" is listed in the products array in the call to the CiviCRM TwingleAPI. And unfortunately, it is named like the option set in the TwingleMANAGER.

"products": [
    {
      "name": "Saatgut \"Frieden wachsen lassen\"",
      "internal_id": "",
      "count": 1,
      "price": 0,
      "total_value": 0
    },
    {
      "name": "Zusatzspende",
      "internal_id": null,
      "count": 1,
      "price": 5,
      "total_value": 5
    }
]

It is annoying that the "additional donation" does not behave like the "top-up donation", which is also available. The latter is not listed in the products array when it is sent to CiviCRM, but only appears as the difference between the "amount" of the donation and the total of the individual products. As a result, it can be easily determined and created as a line item with a donation type that can be selected in the TwingleAPI profile settings.

Since the name of the "additional donation" can be freely chosen, a corresponding option in the TwingleAPI profile would have to be a text field in which you would enter the same name that you chose in the TwingleMANAGER. I find this somewhat clumsy. The alternative seems to be to rely on the “internal_id” always being transmitted as null in contrast to the other products, but should we rely on that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant