Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-10-21T07:38:27Zhttps://lab.civicrm.org/dev/backdrop/-/issues/54drush ci load_generated_data always true if flag present2022-10-21T07:38:27Zbgmdrush ci load_generated_data always true if flag present*Created by: tabroughton*
When reading the description for the civicrm-install drush command the flag load_generated_data is stated to default to FALSE - this suggests that setting the flag to TRUE will generate the data (and it does).
...*Created by: tabroughton*
When reading the description for the civicrm-install drush command the flag load_generated_data is stated to default to FALSE - this suggests that setting the flag to TRUE will generate the data (and it does).
However, setting any value against load_generated_data will also load the data, in fact just having the flag present when running the command will generate the data. This isn't terrible but it doesn't match the other flag settings which all accept a value. Also the description suggests setting the value to FALSE would not load the data but it does.
I suggest being able to set true or false explicitly (where false is default if not present) would be the better solution here.https://lab.civicrm.org/dev/core/-/issues/1191CiviCRM reaching MySQL join limit2023-11-26T16:41:52ZJGauntCiviCRM reaching MySQL join limitI've seen a similar error on a few websites where there is a lot of custom data which can throw up a few issues and it was mentioned I should write up an issue here to see whether it is a common issue in the community.
All current versi...I've seen a similar error on a few websites where there is a lot of custom data which can throw up a few issues and it was mentioned I should write up an issue here to see whether it is a common issue in the community.
All current versions of MySQL and MariaDB have a join limit of 61 and Civi needs to join a lot of tables together (dependant on how much custom data you have). This can cause problems when you have a site with a lot of custom data sets as this join limit is reached which prevents Civi from working as expected.
An example of this would be yesterday where I tried to load up a contact's activities but, because of the amount of custom data sets on the site, I was given an AJAX error and could not view the contact's activities.
After doing a bit of debugging, I found out the reason was because the join limit of 61 had been reached.
I managed to resolve the issue by disabling some unused custom data sets but I am wondering if this is quite a common issue with some bigger sites.
My thinking is that as time goes on, the database will naturally get bigger as more is added to it and the issue will come up more and more.
Looking forward to hearing some thoughts and suggestions on this!https://lab.civicrm.org/dev/core/-/issues/1195Links in PayPal Standard recurring contribution confirmation email don’t work2023-11-23T07:47:01ZBobSLinks in PayPal Standard recurring contribution confirmation email don’t workRef: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel futu...Ref: https://lab.civicrm.org/dev/core/issues/760
Contribution confirmation emails for recurring PayPal Standard contributions contain three links that are non-functional.
**Link 1: “This is a recurring contribution. You can cancel future contributions by visiting this web page.”**
* Two questions are shown which seem inappropriate for a front-end page:
1. Send cancellation request to PayPal Standard ?
2. Notify Contributor?
* On submit:
* If Send Cancellation = Yes:
* Green-background status message: "The recurring contribution could not be cancelled."
* No change to recurring status in Civi or PayPal.
* If Send Cancellation = No:
* Green-background status message: “The recurring contribution of 5.20, every 1 month has been cancelled.”
* Contact record shows recurring contribution is cancelled
* Merchant and donor PayPal accounts continue to show active recurring transaction.
**Link 2: “You can update billing details for this recurring contribution by visiting this web page.”**
* There are only Save and Cancel buttons, but no form fields.
* Submit: "There was some problem updating the billing details"
**Link 3: “You can update recurring contribution amount or change the number of installments for this recurring contribution by visiting this web page.”**
* Recurrence Period is indicated as "(every )" rather than ‘(every month)”.
* If not logged in:
* Popup: "Access is denied. Ensure that you are still logged in and have permission to access this feature."
* On submit: Blank screen.
* If logged in:
* On submit:
* Displays Find Contributions page with no error indicated.
* No change observed in either merchant or donor PayPal accounts. Both show an active recurring payment.
**Analysis**
(I’ll focus on link 2 as an example, and assume that none of these 3 links should appear as their functions are unsupported by PayPal (?) for PayPal Standard payments)
1. Sending of confirmation email is initiated by Paypal performing an IPN POST.
2. CRM_Contribute_BAO_Contribution->composeMessageArray calls CRM_Core_Payment_PayPalImpl->subscriptionURL to form the problematic URLs.
3. CRM_Core_Payment_PayPalImpl->subscriptionURL attempts to determine if the payment processor supports each operation by doing, for example “if (!$this->supports('updateSubscriptionBillingInfo'))” which in turn returns method_exists($this, supportsUpdateSubscriptionBillingInfo).
4. CRM_Core_Payment (parent class of CRM_Core_Payment_PayPalImpl) does indeed contain function supportsUpdateSubscriptionBillingInfo which returns “method_exists(CRM_Utils_System::getClassName($this), 'updateSubscriptionBillingInfo')”.
5. CRM_Core_Payment_PayPalImpl does include function updateSubscriptionBillingInfo, although it begins with “if ($this->isPayPalType($this::PAYPAL_PRO)) “ and therefore simply returns false for PayPal Standard or Express
6. Template "Contributions - Receipt (on-line)" includes the problematic URL section based on the existence of $updateSubscriptionBillingUrl (for example).
**Conclusion**
* Step 3 seems to be a problem as it tests only for the existence of supportsUpdateSubscriptionBillingInfo (found in the parent class) rather than calling that function to get a meaningful result.
* Step 4 seems to be a problem because while the function 'updateSubscriptionBillingInfo' does indeed exist, it does nothing if the payment processor is PayPal Standard.
Behavior confirmed in 5.13.4 and in master (5.18.alpha1).https://lab.civicrm.org/dev/core/-/issues/1197Participants counted even when marked as "0" on price set line item2023-06-18T00:47:30ZphilmorbruParticipants counted even when marked as "0" on price set line item[This issue was originally reported in Jira as [CRM-20784](https://issues.civicrm.org/jira/browse/CRM-20784). Bringing it here to make sure it doesn't get lost as it continues to be a bug in 5.13.5]
When creating a price set, you can se...[This issue was originally reported in Jira as [CRM-20784](https://issues.civicrm.org/jira/browse/CRM-20784). Bringing it here to make sure it doesn't get lost as it continues to be a bug in 5.13.5]
When creating a price set, you can set the number of participants who should be counted for that price option. In this use case, I was setting up a price option for a table (with a participant count of 8) and for a table guest (with a participant count of 0). This way, the person purchasing the table could choose whether or not to register the actual names and emails of the additional table guests without paying more or having them count toward the total number. When testing, the table price option worked as expected, counting 8 participants, but the table guest still counted as 1. If there's an option to set the participant count to 0, then it should not calculate accordingly in the Actual Participant Count.https://lab.civicrm.org/dev/joomla/-/issues/16[Joomla 4.0] Warnings when CiviCRM is uninstalled2022-08-12T05:14:12ZAndrew Thompson[Joomla 4.0] Warnings when CiviCRM is uninstalledTwo PHP warnings are displayed when uninstalling CiviCRM from Joomla 4.0 alpha 11:
```
Warning: require_once(CRM/Utils/String.php): failed to open stream: No such file or directory in /var/www/html/j4/administrator/components/com_civic...Two PHP warnings are displayed when uninstalling CiviCRM from Joomla 4.0 alpha 11:
```
Warning: require_once(CRM/Utils/String.php): failed to open stream: No such file or directory in /var/www/html/j4/administrator/components/com_civicrm/script.civicrm.php on line 226
```
```
Fatal error: require_once(): Failed opening required 'CRM/Utils/String.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/j4/administrator/components/com_civicrm/script.civicrm.php on line 226
```Joomla 4 Integrationhttps://lab.civicrm.org/dev/joomla/-/issues/21cron.php broken since Joomla 3.8 in some PHP environments2021-02-26T08:34:13ZAndrew Thompsoncron.php broken since Joomla 3.8 in some PHP environmentsThis issue was mentioned in https://issues.civicrm.org/jira/browse/CRM-21203 and the [associated PR](https://github.com/civicrm/civicrm-core/pull/11609), which eventually solved problems for cli.php. But there is a session issue that has...This issue was mentioned in https://issues.civicrm.org/jira/browse/CRM-21203 and the [associated PR](https://github.com/civicrm/civicrm-core/pull/11609), which eventually solved problems for cli.php. But there is a session issue that hasn't gone away for cron.php so I am reporting that here.
Depending on PHP error reporting settings (and PHP version possibly, certainly it happens on PHP 7+), this warning will be given:
```
Warning: ini_set(): A session is active. You cannot change the session module's ini settings at this time in /var/www/html/membership/libraries/joomla/session/handler/joomla.php on line 48
```
Which may also cause this one:
```
Warning: session_cache_limiter(): Cannot change cache limiter when headers already sent in /var/www/html/membership/libraries/joomla/session/handler/native.php on line 235
```
Followed by this error:
```
Error: Failed to start application: Failed to start the session because headers have already been sent by "/var/www/html/membership/libraries/joomla/session/handler/joomla.php" at line 48.
```
The cron.php problem started in Joomla 3.8 [due to a change that Joomla made](https://github.com/joomla/joomla-cms/commit/5b92dc69b39240debc69fb90c7f8d71f060631e8#diff-bf82c85e1f29a328e842c4a195392b10) to `JSessionHandlerJoomla::__construct()` in `libraries/joomla/session/handler/joomla.php`.
It could be fixed by Joomla, however I have given up on that. There was an abandoned [Joomla PR #15742](https://github.com/joomla/joomla-cms/pull/15742), superseded by [PR #21260](https://github.com/joomla/joomla-cms/pull/21260), which is also languishing. Anyway we might be better off fixing this on the CiviCRM side.
This is a similar (but separate) case to [https://github.com/civicrm/civicrm-core/pull/14074](https://github.com/civicrm/civicrm-core/pull/14074), where `extern/rest.php` called `session_start()` before bootstrapping the CMS - that issue referred to Drupal though I am sure that it applied to Joomla also (don't know about Wordpress). Removing session_start() was the solution for that REST session problem.https://lab.civicrm.org/dev/joomla/-/issues/23Frontend form field labels are not styled well on Joomla 32020-01-14T14:55:04ZAndrew ThompsonFrontend form field labels are not styled well on Joomla 3As shown in this screenshot, the field labels have an ugly grey background and white text applied to the `.label` CSS class, at least on the Joomla 3 default 'Protostar' site (frontend) template.
![image](/uploads/4e7a8e4a2f0d000f75a6ea8...As shown in this screenshot, the field labels have an ugly grey background and white text applied to the `.label` CSS class, at least on the Joomla 3 default 'Protostar' site (frontend) template.
![image](/uploads/4e7a8e4a2f0d000f75a6ea84d8046f42/image.png)
Of course this could be overridden by a savvy user with custom CSS but it does degrade the out-of-box experience for a new Joomla 3 user.https://lab.civicrm.org/dev/drupal/-/issues/88CRM/Utils/System/Drupal8.php autoload.php path issue 5.16.32020-04-22T14:54:19ZndavisCRM/Utils/System/Drupal8.php autoload.php path issue 5.16.3line 419.
Relies on cmsRootPath
Standard drupal installation cms path (cmsRoot) is now [drupal root]/web.
Drupal8.php now looks for autoload as **[cms.root]//autoload.php** (line 419)
Unless you symlink autoload.php from ../vendor/au...line 419.
Relies on cmsRootPath
Standard drupal installation cms path (cmsRoot) is now [drupal root]/web.
Drupal8.php now looks for autoload as **[cms.root]//autoload.php** (line 419)
Unless you symlink autoload.php from ../vendor/autoload.php this fails to find autoload.php.
Suggest an if block that first tries `require_once "autoload.php";` and if that fails (vendor directory is not in php's include_path) *then* look for it in a better place than cmsRoot. As well [cms.root] has a trailing slash so the forward slash in the `$autoloader = require_once $root."/autoload.php"` is unnecessary.
vendor is not supposed to be accessible in the web root, so for anyone who's vendor directory is not the web root, and is in a directory one directory level up (out of web root) Drupal8.php won't find autoload.php.
I'm not sure of the Drupal8.php's history, but changes related to the path to autoload.php between 5.15.1 and 5.16.3 and broke things.
If you change the [cms.root] so Drupal8.php can find autoload.php the rest of civi breaks. If I set this path properly in Drupal8.php everything works.https://lab.civicrm.org/dev/core/-/issues/3567CiviMail: Provide transparency about (non)recipient details2023-09-05T10:28:43ZtottenCiviMail: Provide transparency about (non)recipient detailsTwo stories which are not-uncommon:
## Story 1
Someone starts using CiviMail. They spend a bunch of time arranging for the list of contacts (e.g. migrating from a previous system) and then go to send a mailing. They start composing a m...Two stories which are not-uncommon:
## Story 1
Someone starts using CiviMail. They spend a bunch of time arranging for the list of contacts (e.g. migrating from a previous system) and then go to send a mailing. They start composing a message and realize that the number of recipients is way off. What's going on? They start searching Google, Stackexchange, etc trying to understand why. Eventually, they learn that there are a half-dozen rules about who gets included or excluded from a mailing. (*Does the contact have an email address? Are they deceased? Have they opted-out of the specific mailing list? Have they opted-out of email generally? Have they had bounces? Does an extension - like GDPR - add more constraints?*) But they haven't solved the issue yet: now they need to figure out which criteria are affecting them, to what extent, and how to adapt.
And of course people have this problem - the "New Mailing" UX only presents the affirmative list of active recipients. It doesn't give any hint or detail about the omitted recipients.
![Screen_Shot_2019-09-03_at_12.58.40_PM](/uploads/73d40846bf379562ed119a317163b4e9/Screen_Shot_2019-09-03_at_12.58.40_PM.png)
## Story 2
A new user composes an email blast and discovers this incredible drop-down button with a list of tokens. They start throwing in tokens like there's no tomorrow. The blast goes out, and recipients complain: "Why are you sending me these weird messages with skipped words?"
And, again, of course people have this problem - the "New Mailing" UX lets you choose tokens without knowing if your recipient-data is up to the job.
## Discussion
These two stories are thematically similar: in both cases, we have a long list of potential recipients, and we have obscure/hidden criteria which determines whether the mailing goes out successfully to the target audience.
In both cases, there needs to be more transparency - adding UI-elements/UX-mechanisms to communicate what's going on. For example, the data-table in the pop-up might be updated with more columns/icons/color-coding.
I've logged the issue because I think, at some point, there should be discussion around design/resourcing. I don't want to prejudge that by saying the UX mechanisms to resolve these two issues must or must-not be the same - they might be totally different, or they might be one data-table. Either way, I think it's good to have a record of the issue.
## Related Links
* https://chat.civicrm.org/civicrm/pl/nn5rjzwiz3fc78pgojmhubx89a
* https://civicrm.org/blog/simonparkervitiligosocietyorguk/solution-all-recipients-not-showing-up-for-sending-mass-email
* https://civicrm.stackexchange.com/questions/5086/civimail-does-not-send-to-a-whole-group
* https://civicrm.stackexchange.com/questions/6346/after-import-to-group-individuals-in-that-group-not-showing-up-as-recipients-to
* https://civicrm.stackexchange.com/questions/26320/contacts-visible-in-mailing-list-group-not-on-hold-or-otherwise-dnd-but-skippe
* https://civicrm.stackexchange.com/questions/18199/in-mailing-all-recipients-are-not-showing/18201#18201
* https://civicrm.org/extensions/zombie-checkhttps://lab.civicrm.org/dev/drupal/-/issues/86Group Role sync not mapping users but duplicating users2019-09-13T07:05:05ZacaselliGroup Role sync not mapping users but duplicating usersHi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new ...Hi,
The group role sync module doesn't seem to work properly anymore. When I create a new user and I log in for the first time, instead of mapping the Drupal user id with the civicrm user id, the module maps the drupal user id to a new user that has everything blank apart from the email.
I checked in the database, and in the table uf_match to confirm and here is (I think) what the module does.
When a user logs in, the checking of the existing user doesn't work anymore, so a new user is created with only the email field and that new user civicrm id is mapped with the drupal id in the uf_match table.
This is causing a lot of problems in our website. I updated to the latest version, 5.17.3 but that didn't fix it either. I noticed this error since version 5.11https://lab.civicrm.org/dev/core/-/issues/3648SMS limit is hardcoded at 460 but should be changeable somewhere2024-01-29T09:44:22ZjasonobrownSMS limit is hardcoded at 460 but should be changeable somewhereTwillio (and probably other sms providers) allows SMS messages up to 1600 characters, but Civi has the limit hardcoded at 460. I've verified that by simply going to CRM/SMS/Provider.php and changing MAX_SMS_CHAR from 460 to 1600 the sys...Twillio (and probably other sms providers) allows SMS messages up to 1600 characters, but Civi has the limit hardcoded at 460. I've verified that by simply going to CRM/SMS/Provider.php and changing MAX_SMS_CHAR from 460 to 1600 the system now accepts (and sends) messages up to 1600 characters. It seems logical that the character limit should able to be adjusted and stored somewhere rather than set as a static value in the code. We are currently using the larger limit, and would really like to see this implemented asap so that we can stop manually updating the code each time we update civi.https://lab.civicrm.org/dev/core/-/issues/1275Batch update for cases gives a warning and then fatal error if only one case ...2022-09-20T11:04:16ZDaveDBatch update for cases gives a warning and then fatal error if only one case is in the listI also see this on dmaster.demo, and I'm still trying to see the exact triggers to reproduce and when it started, but what seems to be a consistent one is:
1. First set up a profile that has a case field in it, e.g. a profile that just ...I also see this on dmaster.demo, and I'm still trying to see the exact triggers to reproduce and when it started, but what seems to be a consistent one is:
1. First set up a profile that has a case field in it, e.g. a profile that just has case status.
2. Do a find cases that results in only one search result.
3. Select it and choose update multiple cases from the actions dropdown.
4. You'll get a warning like `Notice: Undefined property: CRM_Core_DAO::$case_id in CRM_Core_Form_Task::preProcessCommon() (line 139 of /srv/buildkit/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Form/Task.php)`.
5. If you continue and select your profile, you then get a fatal error where it's obvious the problem is that it wasn't able to obtain the case id (the `IN ()` part):
```
[message] => DB Error: syntax error
[mode] => 16
[debug_info] =>
SELECT contact.id as contactId, civicrm_case.id as componentId, contact.sort_name as sort_name, email as email
FROM civicrm_case as civicrm_case
INNER JOIN civicrm_case_contact ccs ON (ccs.case_id = civicrm_case.id)
INNER JOIN civicrm_contact contact ON ( contact.id = ccs.contact_id ) LEFT JOIN civicrm_email email ON ( contact.id = email.contact_id AND email.is_primary = 1 )
WHERE civicrm_case.id IN ()
GROUP BY civicrm_case.id, contact.id
```https://lab.civicrm.org/dev/translation/-/issues/31civicrm_mailing_component name is limited to 64 charaters, missing label2020-05-18T00:29:46Zbgmcivicrm_mailing_component name is limited to 64 charaters, missing labelThe `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe me...The `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe message" can be over 64 characters, causing the CiviCRM installer to fail.https://lab.civicrm.org/dev/drupal/-/issues/92Drupal8 - Solarium/Solarium 5.13 breaks Civicrm2020-10-24T21:12:08ZRar9Drupal8 - Solarium/Solarium 5.13 breaks CivicrmIf Solarium/Solarium 5.13 is used all Drupal 8 breaks
I was forced to apply composer require symfony/event-dispatcher:"4.3.4 as 3.4.99"
But this gives
PHP Fatal error: Uncaught Error: Class 'Symfony\Component\EventDispatcher\Contai...If Solarium/Solarium 5.13 is used all Drupal 8 breaks
I was forced to apply composer require symfony/event-dispatcher:"4.3.4 as 3.4.99"
But this gives
PHP Fatal error: Uncaught Error: Class 'Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher' not found in /var/www/vhosts/XXX/vendor/civicrm/civicrm-core/Civi/Core/CiviEventDispatcher.php:18
![image](/uploads/cfcf9db6c5faf6acecd610b4b2933197/image.png)
If civicrm is disabled site works again.https://lab.civicrm.org/dev/core/-/issues/3587Unable to load the recipients group when sending mailing with Civimail2023-10-05T15:41:24ZmarzastUnable to load the recipients group when sending mailing with CivimailI am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed mess...I am running CiviCRM 5.17.4 on Wordpress 5.2.3. The problem I am facing is that I am unable to send mailing to mailing lists (defined as groups) via CiviMail.
When I try to enter the group in the Recipients box I get Loading Failed message and none of the available groups is loaded (see image below). The problem appears for existing and new mailings.
Interestingly when I re-use the existing mailing I can still send it to a previously used group (though I cannot change the recipient lists). The groups load normally in manage group page.
![aE8nz](/uploads/dca6a15c237cbb7612df433a31b769d5/aE8nz.png)
*Issue already reported on CiviCRM Stack Exchange: https://civicrm.stackexchange.com/questions/33070/unable-to-load-the-recipients-group-when-sending-mailing-with-civimail*https://lab.civicrm.org/dev/user-interface/-/issues/3Support Menu Addition - Bug Reporting2022-01-04T20:14:54ZrebeccatregennaSupport Menu Addition - Bug ReportingAdd menu option under 'Support' titled 'Report an issue' linking to existing 'View issues and report bugs'Add menu option under 'Support' titled 'Report an issue' linking to existing 'View issues and report bugs'https://lab.civicrm.org/dev/user-interface/-/issues/4Enhancement - Quick search contact lookup2019-10-07T13:26:00ZrebeccatregennaEnhancement - Quick search contact lookupAllow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.Allow quick search to be used with full names rather than by leading last name; e.g. allow users to search for Oliver Gibson.https://lab.civicrm.org/dev/user-interface/-/issues/7Ability to exclude activities that appear on the actions button on a contact ...2019-10-07T13:29:15ZHeatherOliverAbility to exclude activities that appear on the actions button on a contact recordAll activity types that are added to CiviCRM are included in the Actions button when you view a contact record. For sites with a lot of activities (particularly those which are used in connection with Drupal webforms andnot normally trig...All activity types that are added to CiviCRM are included in the Actions button when you view a contact record. For sites with a lot of activities (particularly those which are used in connection with Drupal webforms andnot normally triggered in CiviCRM directly) this becomes a bit frustrating to manage.
Adding / filtering activities in other places uses the look up function, meaning the the length of the list in those places isn't really an issue.
See two attached images as an example. This isn't even all the activities for this site.
![image-1](/uploads/9b605ca4b8c666484a20ffb6be744651/image-1.PNG)![image-2](/uploads/56b30fe891eeaa9bbab310c74328cfb5/image-2.PNG)https://lab.civicrm.org/dev/user-interface/-/issues/8Create New Donation Form Option with Better Design2022-11-08T22:36:19ZroshaniCreate New Donation Form Option with Better Design[Improvements_to_CiviCRM_Donation_Forms.docx](/uploads/13d08f094f6ecde376bf84304daaec6e/Improvements_to_CiviCRM_Donation_Forms.docx)
Improvements to CiviCRM Donation Forms
1. Convert Donation Amounts location and styling
- Change the d...[Improvements_to_CiviCRM_Donation_Forms.docx](/uploads/13d08f094f6ecde376bf84304daaec6e/Improvements_to_CiviCRM_Donation_Forms.docx)
Improvements to CiviCRM Donation Forms
1. Convert Donation Amounts location and styling
- Change the donation amount radio buttons from radio buttons to buttons with donation amounts
- Move the donation amounts below One-Time and Monthly buttons
https://ccrjustice.org/donate?track1=website&track2=wheader&track3=2016-DEC-16
Give a donation in the Amount of:
$100.00
$250.00
$500.00
$1,000.00
$5,000.00
Other Amount
2. One-Time & Monthly Donation Buttons
1. Add One-Time & Monthly Buttons above the donation amounts
Current CiviCRM Example:
Currently there is a checkbox for creating a recurring donation. Also note that donation amounts appear as radio buttons above the recurring options.
https://ccrjustice.org/donate?track1=website&track2=wheader&track3=2016-DEC-16
I want to join the CCR Justice Sustainers and contribute this amount every month
Monthly giving provides reliable funding which allows CCR to plan, leverage and allocate resources in a way that means more hope for our clients, more support for movements, more justice and accountability.
Examples:
https://secure.humanesociety.org/site/Donation2;jsessionid=00000000.app325b https://action.aclu.org/give/now
2. If someone selects Monthly, it will change the donation amounts shown.
3. Default will be One-Time donation button option.https://lab.civicrm.org/dev/financial/-/issues/74Order.create - registering multiple Participants (participantPayment records ...2020-03-04T23:10:14ZAndrei Mondocandreimondoc@gmail.comOrder.create - registering multiple Participants (participantPayment records not created properly)Creating an Order to register two (or more) participants creates two (or more) `ParticipantPayment` records, one for each participant line item, registering two participants via an Event page creates only one `ParticipantPayment` record ...Creating an Order to register two (or more) participants creates two (or more) `ParticipantPayment` records, one for each participant line item, registering two participants via an Event page creates only one `ParticipantPayment` record regardless of the number of participants registered.
Which is the correct one/what is expected behaviour?
### Steps to reproduce
Call Order.create with parameters similar to:
``` php
$params = [
'total_amount' => 100.00,
'financial_type_id' => 4,
'contribution_status_id' => 'Pending',
'payment_instrument_id' => 1,
'currency' => 'USD',
'source' => 'Multiple participants (Order.create)',
'contact_id' => 2,
'line_items' => [
1 => [
'line_item' => [
0 => [
'price_field_id' => 3,
'label' => 'Tickets',
'financial_type_id' => 4,
'price_field_value_id' => 3,
'qty' => 1,
'field_title' => '1 Ticket',
'unit_price' => 50.000000000,
'line_total' => 50,
'entity_table' => 'civicrm_participant',
],
],
'params' => [
'contact_id' => 2,
'event_id' => 1,
'role_id' => 1,
'source' => 'Multiple participants (Order.create)',
'price_set_id' => 7,
'fee_level' => '1 Ticket',
'fee_amount' => 50,
],
],
2 => [
'line_item' => [
0 => [
'price_field_id' => 3,
'label' => 'Tickets',
'financial_type_id' => 4,
'price_field_value_id' => 3,
'qty' => 1,
'field_title' => '1 Ticket',
'unit_price' => 50.000000000,
'line_total' => 50,
'entity_table' => 'civicrm_participant',
],
],
'params' => [
'contact_id' => 5,
'event_id' => 1,
'role_id' => 1,
'source' => 'Multiple participants (Order.create)',
'price_set_id' => 7,
'fee_level' => '1 Ticket',
'fee_amount' => 50,
],
],
],
];
$order = civicrm_api3('Order', 'create', $params);
```
This results in two ParticipantPayment records:
``` json
// civicrm_participant_payment
[
{
"id": 5,
"participant_id": 5,
"contribution_id": 18
},
{
"id": 6,
"participant_id": 6,
"contribution_id": 18
}
]
```
Registering two or more participants via an Event page, always creates one ParticipantPayment regardless of the number of participants registered.
``` json
// civicrm_participant_payment
{
"id": 7,
"participant_id": 7,
"contribution_id": 19
}
```