Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-01-29T09:44:22Zhttps://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/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/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/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/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/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/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/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/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/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/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/drupal/-/issues/81Drupal8: Large export results in logout2019-11-03T16:19:27ZJonGoldDrupal8: Large export results in logoutWhen you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces,...When you attempt a large export of CiviCRM data (~63K contacts, ~15 columns), Symfony kills the session. This is relatively recent behavior (didn't happen in April, for instance). Here are the watchdog logs:
Here are those stack traces, more readable:
```
Warning: session_start(): Failed to decode session object. Session has been destroyed in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 149 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#1 [internal function]: _drupal_error_handler(2, 'session_start()...', '/var/www/crm.ag...', 149, Array)
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php(149): session_start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#5 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#6 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#15 {main}.
```
```
RuntimeException: Failed to start the session in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 150 of /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php)
#0 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/Session/SessionManager.php(118): Drupal\Core\Session\SessionManager->startNow()
#2 /var/www/crm.agbu.org/vendor/symfony/http-foundation/Session/Session.php(57): Drupal\Core\Session\SessionManager->start()
#3 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpFoundation\Session\Session->start()
#4 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#5 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#6 /var/www/crm.agbu.org/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#8 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /var/www/crm.agbu.org/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /var/www/crm.agbu.org/web/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /var/www/crm.agbu.org/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#12 {main}.
```
The first issue is a warning that the session is too large, and so it destroys the session (which causes a logout). The second issue is of "error" severity saying the session can't be found.
Here's someone else having a similar issue in Symfony (not Drupal8): https://github.com/symfony/symfony/issues/26623tottentottenhttps://lab.civicrm.org/dev/core/-/issues/3387Captcha not working when registering multiple participants online from same p...2022-09-30T12:56:35ZMartinCaptcha not working when registering multiple participants online from same profile (Jira CRM-21824)I'm having this issue (on civi 5.14.1) and found it on Jira but not here... So I'm restarting it. :)
Original: https://issues.civicrm.org/jira/browse/CRM-21824
Copied description:
* When creating an event and allowing contacts to regi...I'm having this issue (on civi 5.14.1) and found it on Jira but not here... So I'm restarting it. :)
Original: https://issues.civicrm.org/jira/browse/CRM-21824
Copied description:
* When creating an event and allowing contacts to register multiple participants online.
* And where the profile for the registration has captcha enabled
* And where the additional participants are registered using the same profile as the initial contact.
* Online registration is failing with a message that the captcha hasn't been completed.
In earlier versions if multiple participants where booked via this method. The first participant record was shown the captcha and this held for subsequent booked participants. This bug was noticed after a client moved from 4.6 to 4.7 versions. Answer at the moment is to not allow multiple participants, or to create a new profile without captcha for recording additional participants.https://lab.civicrm.org/dev/user-interface/-/issues/1Remove "Backend" from the Access CiviCRM permission label2019-08-15T06:52:49ZmarshRemove "Backend" from the Access CiviCRM permission labelon admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access Civ...on admin>people/permissions the name of Access CiviCRM has changed to "Access CiviCRM backend and API".
This is confusing for two reasons:
- backend infers something behind Civi, not Civi itself
- there are many references to Access CiviCRM in the notes on the page.
Would it be more prudent to change the label to "Access CiviCRM (and API)", or am I just being pedantic?https://lab.civicrm.org/dev/core/-/issues/1129Duplicate records on CRM_Report_Form_Member_Detail2022-09-26T00:11:17ZandyburnsDuplicate records on CRM_Report_Form_Member_DetailOn CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4On CRM_Report_Form_Member_Detail, the rows get duplicated. They are not actual duplicates, it is the same contact ID and they do not have duplicate memberships.
![5b7f716e](/uploads/6ae639a21fd22a9b5fc47c1d1edf66be/5b7f716e.png)
On 5.13.4https://lab.civicrm.org/dev/backdrop/-/issues/49installing via composer2022-10-21T07:38:47Zbgminstalling via composer*Created by: tabroughton*
I'm trying to automate an installation of civicrm into backdrop and I'm using composer for all my other php libraries and frameworks. I see civicrm-core is available in [packagist](https://packagist.org/packag...*Created by: tabroughton*
I'm trying to automate an installation of civicrm into backdrop and I'm using composer for all my other php libraries and frameworks. I see civicrm-core is available in [packagist](https://packagist.org/packages/civicrm/civicrm-core) but no backdrop version.
What's the best way to do this please?https://lab.civicrm.org/dev/core/-/issues/1125Custom fieldsets participants added twice2023-02-15T15:13:29ZwdecraeneCustom fieldsets participants added twiceWhen editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of...When editing a participant, some custom fieldsets are added twice to the participant edit form. When saving, only the data in the second fieldset is saved (so users think nothing happened when they added the data in the first instance of the fieldset).
This only happens with fieldsets linked to a specific event type.
In templates/CRM/Event/Form/Participant.tpl:
```smarty
CRM.buildCustomData( '{$customDataType}', null, null );
{if $eventID}
CRM.buildCustomData( '{$customDataType}', {$eventID}, {$eventNameCustomDataTypeID} );
{/if}
{if $eventTypeID}
CRM.buildCustomData( '{$customDataType}', {$eventTypeID}, {$eventTypeCustomDataTypeID} );
{/if}
```
* First buildCustomData : adds all custom field sets, except those linked to a specific event id
* Second buildCustomData : adds all custom field sets linked to a event id
* Third buildCustomData : adds all custom field sets linked to a specific event type id
So the combination of the first and third one is the cause of fieldsets added twice.
Solution? Altering template, changing arguments, fixing getTree() in CRM/Core/BAO/CustomGroup.php, ... ?
See also
* https://issues.civicrm.org/jira/browse/CRM-10983
* https://issues.civicrm.org/jira/browse/CRM-20633https://lab.civicrm.org/dev/core/-/issues/1116Changing a civicase activity's label breaks the max_instances check2023-02-23T14:16:28ZDaveDChanging a civicase activity's label breaks the max_instances check1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the ma...1. Configure a case type so that some activity type (other than open case) has a max_instances set.
2. Create a case.
3. Change the activity type's label.
4. On manage case, create a second activity of that type.
5. You should get the max_instances warning but it doesn't.https://lab.civicrm.org/dev/drupal/-/issues/76Proposal: Don't migrate drush commands to D82020-06-19T16:21:14ZJonGoldProposal: Don't migrate drush commands to D8CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush c...CiviCRM drush commands are incompatible with modern versions of drush.
I investigated this, and each command will need to be rewritten for drush 9/D8. I've created a framework and ported a couple of my most used commands (e.g. `drush civicrm-sql-cli`, `drush civicrm-sql-dump`) but there's a compelling argument to simply not rewriting drush and instead making sure that `cv` has feature parity.
For those who DO think we should continue to maintain the drush commands, I have a branch here: https://github.com/MegaphoneJon/civicrm-drupal-8
Klaas has also submitted a PR to add `drush civicrm-api` to this branch.https://lab.civicrm.org/dev/financial/-/issues/64Authorize.net - support future dated transactions via contribution page2019-09-10T17:28:18ZlcdwebAuthorize.net - support future dated transactions via contribution pageProvide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net conf...Provide an option to allow contribution pages implementing Authorize.net to expose a field where the user can select a future date for the transaction. This would be patterned after the iATS future date implementation.
* add A.net config settings page where future date option can be enabled/disabled
* add config setting to select specific days of the month where the future date can be implemented. this is important for recurring payments, where the org may only want recurring payments to be triggered on specific days of the month
* expose a Contribution Transaction Date field to the contribution form (when option is enabled)
* modify processing to account for this field if active and used
Contrib page screenshot attached for reference.
![anet-futuredate](/uploads/94fefd56c909114e8758f367cbb6c1b2/anet-futuredate.png)
I'd like to see this included in core, and am looking for concept approval.lcdweblcdweb