Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-09-18T23:02:38Zhttps://lab.civicrm.org/dev/core/-/issues/2489Joins on related contacts failing (e.g. address of employer)2022-09-18T23:02:38ZMichael McAndrewJoins on related contacts failing (e.g. address of employer)I am creating a searchkit that displays data from three entities: two related contacts and an address.
e.g. a contact, their employer and the country of the employer HQ.
Or in this instance, a product (household), the manufacturer/supp...I am creating a searchkit that displays data from three entities: two related contacts and an address.
e.g. a contact, their employer and the country of the employer HQ.
Or in this instance, a product (household), the manufacturer/supplier of the product, and the country of the manufacturer/supplier (
API4 json:
```
{
"version": 4,
"select": [
"display_name",
"Contact_RelationshipCache_Contact_01.display_name",
"Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01.country_id:label",
"Contact_RelationshipCache_Contact_01.id",
"Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01.id"
],
"orderBy": [],
"where": [
[
"contact_type:name",
"=",
"Household"
]
],
"groupBy": [],
"join": [
[
"Contact AS Contact_RelationshipCache_Contact_01",
"INNER",
"RelationshipCache",
[
"id",
"=",
"Contact_RelationshipCache_Contact_01.far_contact_id"
],
[
"Contact_RelationshipCache_Contact_01.near_relation:name",
"IN",
[
"Manufactures",
"Supplies"
]
]
],
[
"Address AS Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01",
"LEFT",
[
"Contact_RelationshipCache_Contact_01.id",
"=",
"Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01.contact_id"
]
]
],
"having": [],
"debug": true,
"limit": 60,
"offset": 0
}
```
At first glance he API4 json seems fairly correct (to me)
But the generated SQL looks off
```
SELECT
`a`.`id` AS `id`,
`a`.`display_name` AS `display_name`,
`a`.`contact_sub_type` AS `contact_sub_type:label`,
`Contact_RelationshipCache_Contact_01`.`display_name` AS `Contact_RelationshipCache_Contact_01.display_name`,
`Contact_RelationshipCache_Contact_01`.`id` AS `Contact_RelationshipCache_Contact_01.id`,
`Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01`.`id` AS `Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01.id`
FROM
civicrm_contact a
INNER JOIN `civicrm_relationship_cache` `Contact_RelationshipCache_Contact_01_via_relationshipcache` ON `Contact_RelationshipCache_Contact_01_via_relationshipcache`.`far_contact_id` = `a`.`id`
INNER JOIN `civicrm_contact` `Contact_RelationshipCache_Contact_01` ON `Contact_RelationshipCache_Contact_01_via_relationshipcache`.`near_contact_id` = `Contact_RelationshipCache_Contact_01`.`id`
AND `Contact_RelationshipCache_Contact_01_via_relationshipcache`.`near_relation` IN ("manufactures", "supplies")
LEFT JOIN `civicrm_address` `Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01` ON `Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01`.`contact_id` = `a`.`id`
AND `Contact_RelationshipCache_Contact_01`.`id` = `Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01`.`contact_id`
WHERE
(`a`.`contact_type` = "Household")
AND (`a`.`is_deleted` = "0")
LIMIT
60 OFFSET 0
```
Removing the first part of the
```
LEFT JOIN `civicrm_address` clause
```
that is to say
```
`Contact_RelationshipCache_Contact_01_Contact_Address_contact_id_01`.`contact_id` = `a`.`id`
AND
```
seems to fix the query. Not sure why it was inserted in the first place :thinking:colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/2488api3 api4 OptionValue.create and OptionValue.update: Setting the default valu...2021-04-06T21:27:14Zmartin.wapi3 api4 OptionValue.create and OptionValue.update: Setting the default value (is_default=1) ignores domain IDOverview
----------------------------------------
It seems that when you call either `OptionValue.create` or `OptionValue.update` using either `api3` or `api4` and you set "is default" to "true" (`is_default = 1`), this ignores the `civi...Overview
----------------------------------------
It seems that when you call either `OptionValue.create` or `OptionValue.update` using either `api3` or `api4` and you set "is default" to "true" (`is_default = 1`), this ignores the `civicrm_option_value.domain_id` column even when multisite is enabled. It sets the `is_default` field value to `1` for the new or updated record, but forces `is_default` to `0` (zero) for all other records in the Option Group, regardless of `domain_id`.
I noticed this because I was trying to script a multisite deployment on WordPress using the `wp cv` and `cv.phar` CLI tools. CiviCRM wants each site (domain ID) in the multisite to have its own default "From Email Address" (DB `option_group_name = "from_email_address"`), and it complains via an alert message if that is not configured. The Civi admin UI allows you to set a separate default "From Email Address" for each domain ID. (SQL query shows multiple records with "civicrm_option_value.is_default = 1", one per domain ID.) But when you invoke `OptionValue.create` or `OptionValue.update` specifying `is_default = 1`, then the "last update wins." Only the last added or updated record will have `is_default = 1`.
Reproduction steps
----------------------------------------
1. Set up a multi-domain Civi installation with, say, three different sites. (I created mine on WordPress.)
1. Via the UI, navigate to the Civi dashboard for each site. You should see the prompt to set a default "From Email Address".
1. Using the UI, add a default email address for each site.
1. Inspect the `civicrm_option_value` table with a query like the following to verify there are multiple default values (one per domain ID). Also take note if the `civicrm_option_value.id` values for use in the subsequent API calls below.
```
select y.id, y.name, y.is_default, y.domain_id, y.label, y.option_group_id, x.name as option_group_name
from civicrm_option_value y
inner join civicrm_option_group x on x.id = y.option_group_id
where x.name='from_email_address'
```
5. At the command prompt, try any combination of or variations of the following API calls to add or update an option value record as the default.
6. After each of the API calls, re-inspect the `civicrm_option_value` table to verify that there is now only one `civicrm_option_value` record with `is_default = 1` for the Option Group 'from_email_address' corresponding to the most recent add/update, regardless of domain ID.
```
STDEMAIL="webmaster@a_great_nonprofit.org"
DOMAIN1=site1.agreatnonprofit.org
DOMAINID1=1
DOMAIN2=site2.agreatnonprofit.org
DOMAINID2=20
DOMAIN3=site3.agreatnonprofit.org
DOMAINID3=30
wp cv api OptionValue.create option_group_id=from_email_address label="$STDEMAIL" name="$STDEMAIL" is_default=1 --url=$DOMAIN1
wp cv api OptionValue.create option_group_id=from_email_address label="$STDEMAIL" name="$STDEMAIL" is_default=1 --url=$DOMAIN2
wp cv api OptionValue.create option_group_id=from_email_address label="$STDEMAIL" name="$STDEMAIL" is_default=1 domain_id=$DOMAINID3 --url=$DOMAIN3
wp cv api OptionValue.get sequential=1 limit=1 option_group_id="from_email_address" options='{"sort":"is_default DESC"}' domain_id=$DOMAINID1 --url=$DOMAIN1
# Using the output from the above, get the record ID from the civicrm_option_value table (RECORDID)
RECORDID1={record_id_from_above}
export SITEURL="$DOMAIN1"
cv api4 OptionValue.update +w "id = $RECORDID1" +w "domain_id = $DOMAINID1" +v is_default=true +v "label=\"$STDEMAIL\"" +v "name=\"$STDEMAIL\""
# for simplicity here assume that for DOMAIN2, the civicrm_option_value.id = 1020
export SITEURL="$DOMAIN2"
cv api4 OptionValue.update '{"where":[["id","=",1020],["domain_id","=",20]],"values":{"is_default":true,"label":"webmaster@a_great_nonprofit.org","name":"webmaster@a_great_nonprofit.org"}}'
```
Current behavior
----------------------------------------
Any `OptionValue.create` or `OptionValue.update` API call with either `api3` or `api4` that has `is_default = 1` will set `is_default = 1` for the target DB record, but will force all other `civicrm_option_value` records with the same `option_group_id` to `is_default = 0` **regardless of the domain ID**.
Expected behavior
----------------------------------------
`OptionValue.create` or `OptionValue.update` should:
1. Enforce one `is_default = 1` default record for each `option_group_id, domain_id` tuple.
1. Or: if some Option Groups should always ignore the domain ID, then the API should be smart enough to know which option group names (like 'from_email_address') should allow a default record for each domain ID and which ones should not.
1. Or: it should respect the domain ID when CiviCRM multisite is "enabled" and ignore it otherwise. However, in this last case, it seems that there should be only one domain ID `1`, so this perhaps reduces to #1 above.
Environment information
----------------------------------------
* __Browser:__ 89.0.4389.90
* __CiviCRM:__ 5.35.1
* __PHP:__ 7.2
* __CMS:__ WordPress 5.4.4
* __Database:__ MariaDB 10.3
* __Web Server:__ Apache 2.4
For command-line use of `cv` my `civicrm.settings.php` file inspects the `SITEURL` environment variable and sets the correct Civi domain ID, domain group ID, and domain organization ID.
Comments
----------------------------------------
It seems I keep crashing on the dangerous shoals of CiviCRM multisite/multi-domain! ;-) It would be helpful to have an up-to-date summary of the limitations, known issues, and potential gotchas of working with multisite.https://lab.civicrm.org/dev/core/-/issues/2487Fix recurring contribution defaults2021-04-08T21:11:19ZeileenFix recurring contribution defaultsThe contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly...The contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly because it would stop test failures like this one https://test.civicrm.org/job/CiviCRM-Core-PR/40065/testReport/ - but it's also a case of bringing the API into line with the UI.
2) the default for the contribution_status_id should be pending not Completed. As long as it is correctly created as pending then the status will be updated by the BAO (to In Progress or Completed as appropriate) when a contribution is created that is linked to it. Core code correctly creates recurrings with the status id of Pending passed in but the api incorrectly defaults to Pending. Discussion is here https://github.com/civicrm/civicrm-core/pull/19512
- fields
| field | UI default | Old DB default | new db default |
| ------ | --------- | ------------- | -------------- |
| create_date | current time |none - must be passed in (required field)| current time |
| modified_date | current time |none - must be passed in (required field)| current time |
| start_date | current time |none - must be passed in (required field)| current time |
| frequency_unit | 1 |none - must be passed in (required field)| 1 |
| contribution_status_id | Pending |Completed| Pending |
Regarding frequency unit - I could see a case for the existing - required with no default - except that it's 'partner' field HAS a default of 'month' - which seems more of a leap than giving this a convenience default - especially since 1 really is the most frequent - more so than 'month' I expect5.37.0https://lab.civicrm.org/dev/core/-/issues/2486Apiv4 entity parity2023-10-13T21:11:08ZeileenApiv4 entity parity## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civ...## Here are the entities in APIv3 & not v4
_In some cases by design - others we should maybe add..._
# Prioritised
- [ ] Attachment.php - `get` [has been added to support viewing attachments in SearchKit](https://github.com/civicrm/civicrm-core/pull/27379) but `create` is still missing
- [ ] Extension.php - various install, uninstall etc functions (support for some actions already implemented)
# Partially done - lets resolve
- [ ] MembershipLog.php https://github.com/civicrm/civicrm-core/pull/21106
# Standard crud - note that doing these involves checking all pseudoconstants are correctly defined
- [ ] SmsProvider.php
- [ ] Premium.php
- [ ] RecurringEntity.php
# Mailing related - in scope
- [ ] MailingAB.php
- [ ] MailingComponent.php
- [ ] MailingContact.php
- [ ] MailingEventResubscribe.php
- [ ] MailingRecipients.php
# From here on down we are out of scope for 'entity parity'
## Order related - needed when we get to afform payment forms - out of scope for entity parity
- [ ] Order.php
- [ ] Payment.php
## Varied utils - out of scope for 'entity parity' - ad hoc
- [ ] SystemLog.php
- [ ] User.php
- [ ] Logging.php
## Migration doubtful - to be done ad hoc if we decide to
- [ ] ReportTemplate.php
- [ ] ParticipantPayment.php - likely should not be brought over
- [ ] CxnApp.php
- [ ] Cxn.php
- [ ] Profile.php
## Do not migrate
- ~~ActivityType.php (by design)~~
- ~~CustomSearch.php (by design)~~
- ~~Constant.php (by design)~~
- ~~SurveyRespondant.php(by design)~~
- ~~MembershipPayment.php (by design - use Line Item)~~
## Done
- [x] ~~AclRole.php~~ ACLEntityRole https://github.com/civicrm/civicrm-core/pull/20474
- [x] Batch.php https://github.com/civicrm/civicrm-core/pull/19931
- [x] CaseContact.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] Case.php https://github.com/civicrm/civicrm-core/pull/19907
- [x] CaseType.php
- [x] ContributionProduct.php https://lab.civicrm.org/dev/core/-/issues/2683
- [x] Dedupe.php
- [x] EntityBatch.php https://lab.civicrm.org/dev/core/-/issues/2682
- [x] EntityFinancialAccount.php - https://github.com/civicrm/civicrm-core/pull/19927
- [x] EntityFinancialTrxn.php - https://github.com/civicrm/civicrm-core/pull/19932
- [x] ~~Exception.php~~ DedupeException.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] File.php (part of attachment) https://github.com/civicrm/civicrm-core/pull/21158
- [x] FinancialItem.php - https://github.com/civicrm/civicrm-core/pull/20433
- [x] Job.php (crud portion)
- [x] Job.php
- [x] JobLog.php
- [x] Mailing.php - there are a bunch of related entities - see further down)
- [x] MailingEventConfirm.php
- [x] MailingEventQueue.php
- [x] MailingEventSubscribe.php
- [x] MailingEventUnsubscribe.php
- [x] MailingGroup.php
- [x] MailingJob.php
- [x] Membership.php - see https://lab.civicrm.org/dev/core/-/issues/2634 https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipBlock.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] MembershipStatus.php https://github.com/civicrm/civicrm-core/pull/21106
- [x] ParticipantStatusType.php
- [x] PaymentToken.php
- [x] Pcp.php
- [x] PrintLabel.php https://github.com/civicrm/civicrm-core/pull/21500
- [x] Product.php - since 5.41
- [x] ReportInstance.php
- [x] ~~Rule.php~~ DedupeRule.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] ~~RuleGroup.php~~ DedupeRuleGroup.php https://github.com/civicrm/civicrm-core/pull/20466
- [x] Survey.php https://github.com/civicrm/civicrm-core/pull/21355
- [x] WordReplacement.php https://github.com/civicrm/civicrm-core/pull/20559https://lab.civicrm.org/dev/core/-/issues/2485Search-kit - allow functions in the GROUP BY clause2022-05-12T13:39:07ZeileenSearch-kit - allow functions in the GROUP BY clause@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR...@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR(receive_date)
https://www.techonthenet.com/mysql/functions/year.php5.51.0https://lab.civicrm.org/dev/core/-/issues/2484Create apiv4 payment api2023-07-13T08:07:37ZeileenCreate apiv4 payment apiIn order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table...In order to be able to search for payments we need to be able to search for payment rows (rows with is_payment = TRUE) in the financial_trxn table and for the entity bridge to be able to find it's way from there to the contribution table.
This gives us the ability to say find all contributions with a payment with a payment instrument of 'Check' or find the contribution where the payment's trxn value is y
The scope I would be looking for is
1) can use any of the fields in financial_trxn as a filter
2) can logically link to the contribution (probably through bridge entities)
3) forces 'is_payment' as a filter (only gets payments)
4) the create action calls Payment.create
5) the update & delete actions are blocked
This effectively gives us parity with the v3 api albeit with more options provided through the apiv4 layer itself.
Note that I think this is likely blocked on other feature requests which @mattwire will add notes onhttps://lab.civicrm.org/dev/core/-/issues/2483Passing an array activity_id to ActivityContact.create silently casts it to a...2023-07-12T05:03:23ZDaveDPassing an array activity_id to ActivityContact.create silently casts it to activity id 1What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicr...What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicrm-packages/blob/c127df846491ee13b2a4dce5816f3da8b1d98d9a/DB/DataObject.php#L1224-L1231
It's the same in api3 and 4.https://lab.civicrm.org/dev/core/-/issues/2482$civicrm_root with relative paths causes core extensions to fail to be found2023-07-14T05:03:22Zanemirovsky$civicrm_root with relative paths causes core extensions to fail to be foundOverview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/va...Overview
----------------------------------------
For some instances of CiviCRM, like with Drupal 8, CiviCRM is outside the web root. In that case, depending on how the $civicrm_root is generated/set, it can be set to something like "/var/www/sitename.org/web/../vendor/civicrm/civicrm-core". After a change made in https://github.com/civicrm/civicrm-core/commit/ba89bdbde1aa7f21badab003b89b2cb0052fd175, paths like this cause CiviCRM to fail to locate core extensions which causes a fatal error.
Reproduction steps
----------------------------------------
1. Change the $civicrm_root to a path that contains a '..'.
1. Attempt to load CiviCRM.
1. Get an error "CRM_Extension_Exception_MissingException: Unknown extension: org.civicrm.shoreditch in CRM_Extension_Container_Collection->getContainer() (line 150 of /var/www/sitename.org/vendor/civicrm/civicrm-core/CRM/Extension/Container/Collection.php).".
Expected behaviour
----------------------------------------
CiviCRM should either handle paths with '..' gracefully or add validation/documentation that prevents $civicrm_root from being set to a path with invalid parts. For now, we're wrapping our $civicrm_root in realpath() to resolve the reference to '..'.https://lab.civicrm.org/dev/core/-/issues/2481Discussion drop support for php 7.2 and mysql 5.62023-01-04T18:01:36ZeileenDiscussion drop support for php 7.2 and mysql 5.6We have been dropping support for EOL php & mysql on ESR releases because that gives sites the option of delaying for another 6 months for just $120. So far we are not aware of any sites opting for the ESR for that reason but we are crea...We have been dropping support for EOL php & mysql on ESR releases because that gives sites the option of delaying for another 6 months for just $120. So far we are not aware of any sites opting for the ESR for that reason but we are creating the option.
With 5.39 coming up we should consider whether we want to drop support for
php 7.2 (EOL Dec 2020)
mysql 5.6 (EOL Feb 2021)
Note that historically supporting older versions of mysql has been low effort although some features are not supported. However, it might be holding us back from using new features
Supporting older versions of php has historically been more problematic as it has been at the expense of supporting newer versions. In particular we often find packages don't support latest and EOL versions.
So dropping support for older php versions is more helpful than older mysql versions.
Last ESR we considered dropping support for php 7.1 and mysql 5.6. We did the former and not the latter. At the time the stats were:
mysql 5.6 : 805
php 7.1 : 658.
Maria DB 10.1 : 943
Currently they are
mysql 5.6 : 603
php 7.2 : 2846
Maria DB 10.1 : 526
Based on those numbers I think it's clearly too early for php 7.2 and I would be OK targetting both for the NEXT ESR (5.45)https://lab.civicrm.org/dev/core/-/issues/2480Group filtering in search kit2021-06-17T03:25:47ZeileenGroup filtering in search kitI'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups ...I'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups and you could search on them.
There was no `group_contact_cache` table. It was possible to see 'hard' groups on the groups tab but it
was not possible to see smart groups. People asked to be able to see smart groups. Lobo said no.
Around 4.2 there was a sponsored 'improvement' to revert Lobo's 'no'. The group contact cache was added so that it was possible to populate all the smart groups and find out what group a contact was in.
Also around 4.2 and pretty much as soon as the new feature dropped a setting was added to allow sites to turn off the ability to see smart groups on the group tab because it was killing their sites.
Since 4.2 people have struggled with smart group cache performance, and lots of patches have been merged to try to address it.
Also since 4.2 people have been frustrated that there are very few places where you can access the smart groups a contact belongs to - we have had requests to show this on exports and my contact dashboard. However we switched back to the 'no' approach on this because it kills medium+ sizes sites.
More recently it has become effectively possible to turn off the smart group caching again by setting the time out to 0 and turning off opportunistic cache clearing. This is the approach I use and cautiously recommend.
**Smart groups, groups and performance**
So we have 3 things
1) which groups has someone actively been added to
2) which are the contacts that THIS saved search / smart group finds
3) of all the many many searches saved on this site which groups would find a person
Because we UI-conflate groups & smart groups we also conflate 3 into 1 & 2. I think there is a use-case for 3 but for most sites it is not worth the performance hit. We can deliver 1 & 2 in a performant way by following our existing code practices - most notably the one that made reports work ie:
If there is a group filter in play then
1) resolve the group filter to a list of relevant smart groups
2) create a temporary table of all the contacts in those groups (potentially but not necessarily using the `group_contact_cache`)
3) Use the table as the base ie `SELECT * FROM my_temp_table INNER JOIN civicrm_contact .....`
**Should we bypass the group contact cache?**
Probably codewise it's easier to populate it first because we have code that does. However, I have pretty strong doubts that it is very often effectively pre-populated before a query on a particular group runs.
There is a cron to prepopulate smart groups - on some sites this might make sense to use. My recommendation remains 'don't unless you have tested on your site'
**Could we filter off the saved search directly**
Yeah this is an interesting idea - add in a saved search rather than a group. Could be powerful. Let's keep pondering
**How would it look**
`Contact::get()->setWhere('group_id', 'IN', [8,7,89]);`
Note for not in we wouldn't be able to do the Base table inner join trick & TBH we can get the tests & contract right before we do any sort of optimisation5.39.0https://lab.civicrm.org/dev/core/-/issues/2479Loss of translation when copying (cloning) entities (multilingual)2021-06-09T21:46:53ZsamuelsovLoss of translation when copying (cloning) entities (multilingual)In a multilingual installation, copying/cloning of entities (like events) always result in a loss of the non-primary language.
For example, cloning a translated event in a English/French installation will result in having all the french ...In a multilingual installation, copying/cloning of entities (like events) always result in a loss of the non-primary language.
For example, cloning a translated event in a English/French installation will result in having all the french fields getting the english value of the original field.
It is particularly annoying when there are a lot of fields to (re)translate, i.e. :
- profile
- events
Also, not really a cloning but adding a translated custom field to a profile gives the same result.5.39.0https://lab.civicrm.org/dev/core/-/issues/2478CiviCRM 5.35.1 - CiviCRM falls back to using domPDF despite having a valid pa...2021-03-30T10:07:20Zjustinfreeman (Agileware)CiviCRM 5.35.1 - CiviCRM falls back to using domPDF despite having a valid path and executable for wkhtmlpdfSince CiviCRM 5.35.1. CiviCRM falls back to using domPDF despite having a valid path and executable for wkhtmlpdf. Appears that this problem was introduced with this change, https://github.com/civicrm/civicrm-core/commit/6bbe0cf6c513c49f...Since CiviCRM 5.35.1. CiviCRM falls back to using domPDF despite having a valid path and executable for wkhtmlpdf. Appears that this problem was introduced with this change, https://github.com/civicrm/civicrm-core/commit/6bbe0cf6c513c49f89179aa153cabad3a2a059b7 / PR https://github.com/civicrm/civicrm-core/pull/19311
For CiviCRM sites hosted in an environment with an [open_basedir restriction](https://www.php.net/manual/en/ini.core.php#ini.open-basedir) enabled, CiviCRM will be incorrectly report that the wkhtmlpdf can't be found. Despite this Knp\Snappy\Pdf will execute wkhtmlpdf without any problems.
The recent change uses the false positive for the wkhtmlpdf path to then trigger the fallback to domPDF to be used.
Agileware Ref: CIVICRM-16905.36.0https://lab.civicrm.org/dev/core/-/issues/2477Add job to cleanup acl_cache table, add setting to disable opportunistic flus...2021-04-06T20:03:10ZeileenAdd job to cleanup acl_cache table, add setting to disable opportunistic flushingThis is the same approach we use for smart groups - ie instead of cleaning up the cache on every contact edit there is a setting that allows for it to be done in a cron (or never if the cron is not enabled)
I am separately looking into ...This is the same approach we use for smart groups - ie instead of cleaning up the cache on every contact edit there is a setting that allows for it to be done in a cron (or never if the cron is not enabled)
I am separately looking into cleaning up the caching but I think this can & should be done independent of cleanup (it can evolve appropriately with the cleanup)5.37.0https://lab.civicrm.org/dev/core/-/issues/2476Proposal move weird acl stuff to extension2023-07-21T05:03:18ZeileenProposal move weird acl stuff to extensionI've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new rep...I've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new replacement - role based - without ever removing the first 2
The different types are denoted by the value entity_table in civicrm_acl. I believe this is only ever equal to civicrm_acl_role
I think we could simplify the code by moving the support for the other 2 to a core extension which ideally we only enable on upgrade IF we get results from
```SELECT * FROM civicrm_acl WHERE entity_table != 'civicrm_acl_role'```
@seamuslee @DaveD I'd be interested to see if you come to the same conclusionhttps://lab.civicrm.org/dev/core/-/issues/2475'Also include manual recipients' for schedule reminders broken2023-07-23T05:03:23ZPradeep Nayakpradpnayak@gmail.com'Also include manual recipients' for schedule reminders brokenOverview
----------------------------------------
'Also include manual recipients' for schedule reminders gets email only once for a reminder. The issue was reported just after Civi upgrade but i was able to replicate the issue for 5.25....Overview
----------------------------------------
'Also include manual recipients' for schedule reminders gets email only once for a reminder. The issue was reported just after Civi upgrade but i was able to replicate the issue for 5.25. This feature used to work on 4.7 but not sure when it stopped.
Reproduction steps
----------------------------------------
1. Create a schedule reminder for Membership with 0 from join date
1. Choose Limit or Add Recipients = Also include >> Choose Recipient(s).
1. Select recipients
1. Save the reminder by filling other details.
1. Create a membership for contact A and run schedule job for reminder manually.
1. Create a membership for contact B and run schedule job for reminder manually.
Current behaviour
----------------------------------------
The manual recipients gets email only for Contact A.
Also the recipients gets email for the first time even though no membership is present i.e create a schedule reminder with manual recipient and execute the reminder job. The manual recipients will get email but there are no membership present in the system.
Expected behaviour
----------------------------------------
The manual recipients gets email only for Contact A, Contact B and every time the reminder sends email.
Manual recipients should only get email when reminder to contact is sent
Environment information
----------------------------------------
* __CiviCRM: 5.35.1__
* __PHP: 7.3__
* __CMS: ALL CMS__https://lab.civicrm.org/dev/drupal/-/issues/158Page not found after installing extension in Drupal 8 and Drupal 92021-03-26T09:27:08ZjaapjansmaPage not found after installing extension in Drupal 8 and Drupal 9After you install a new extension (for example data processor) in a Drupal 8 or Drupal 9 environment the pages of this extension could not be found.
A work around is to clear the Drupal caches afterwards.
**Related PR**: https://github...After you install a new extension (for example data processor) in a Drupal 8 or Drupal 9 environment the pages of this extension could not be found.
A work around is to clear the Drupal caches afterwards.
**Related PR**: https://github.com/civicrm/civicrm-core/pull/19888https://lab.civicrm.org/dev/backdrop/-/issues/63Source files location should not include "sites/all" for Backdrop2022-10-21T07:36:41ZbgmSource files location should not include "sites/all" for Backdrop*Created by: jenlampton*
I am trying to get Civi installed on Backdrop and just ran into the problem of the `cv` command looking for the civi module in `sites/all/modules` but in backdrop the contrib modules are located in `modules` unl...*Created by: jenlampton*
I am trying to get Civi installed on Backdrop and just ran into the problem of the `cv` command looking for the civi module in `sites/all/modules` but in backdrop the contrib modules are located in `modules` unless it is a multi-site installation. Is there a way for the backdrop version to add an additional location to the places the installer checks for civi?
(and should this request belong in the cv queue, or is this the correct loaction?)https://lab.civicrm.org/dev/core/-/issues/2474Provide onscreen error reporting when ALTER TABLE fails during upgrade2023-07-18T05:03:24ZStoobProvide onscreen error reporting when ALTER TABLE fails during upgradeHUMBLY SUGGEST providing onscreen warning when ALTER TABLE fails during upgrade
This code CRM/Upgrade/Incremental/php/FiveThirtyFour.php was failing because of invalid date format 0000-00-00 in my older install
> public static function u...HUMBLY SUGGEST providing onscreen warning when ALTER TABLE fails during upgrade
This code CRM/Upgrade/Incremental/php/FiveThirtyFour.php was failing because of invalid date format 0000-00-00 in my older install
> public static function updatePledgeTable(
SOLUTION:
Either set my.cnf or my.ini
`innodb_strict_mode = OFF`
or
`ALTER TABLE civicrm_pledge MODIFY start_date datetime NULL DEFAULT NULL, MODIFY create_date datetime NULL DEFAULT NULL;`https://lab.civicrm.org/dev/backdrop/-/issues/62Fatal MYSQL error on install: REFERENCES command denied to user2022-10-08T12:17:30ZbgmFatal MYSQL error on install: REFERENCES command denied to user*Created by: jenlampton*
I am trying to add CiviCRM to an existing Backdrop site.
I was able to download the module from the CiviCRM website, and enable via the modules page. Then I navigated to `civicrm/setup` and once I resolved t...*Created by: jenlampton*
I am trying to add CiviCRM to an existing Backdrop site.
I was able to download the module from the CiviCRM website, and enable via the modules page. Then I navigated to `civicrm/setup` and once I resolved the permissions issue with triggers, I attempted to load default content by ticking the box next to `Load sample data`.
As soon as I hit "Install CiviCRM" I was greeted with the fatal error:
```
Civi\Setup\Exception\SqlException: Cannot execute CREATE TABLE `civicrm_acl_cache` ( `id` int unsigned NOT NULL AUTO_INCREMENT COMMENT 'Unique table ID', `contact_id` int unsigned COMMENT 'Foreign Key to Contact', `acl_id` int unsigned NOT NULL COMMENT 'Foreign Key to ACL', `modified_date` timestamp NULL COMMENT 'When was this cache entry last modified' , PRIMARY KEY (`id`) , INDEX `index_contact_id`( contact_id ) , INDEX `index_acl_id`( acl_id ) , INDEX `index_modified_date`( modified_date ) , CONSTRAINT FK_civicrm_acl_cache_acl_id FOREIGN KEY (`acl_id`) REFERENCES `civicrm_acl`(`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC: REFERENCES command denied to user 'backdrop'@'localhost' for table 'civicrm_acl' in Civi\Setup\DbUtil::sourceSQL() (line 204 of backdrop/modules/contrib/civicrm/setup/src/Setup/DbUtil.php).
```
Now all pages under `/civicrm/` (includin `civicrm/setup`) show the page "CiviCRM Installed" with the message "CiviCRM has been successfully installed" but I don't think it has installed. If it had, I'd be able to see and or use civi in here somewhere, wouldn't I?https://lab.civicrm.org/dev/backdrop/-/issues/61Set up page missing (not built yet?)2022-10-08T12:17:29ZbgmSet up page missing (not built yet?)*Created by: jenlampton*
Hello, I'm doing my best to follow the instructions on https://docs.civicrm.org/installation/en/latest/backdrop/ for how to add CiviCRM to an existing Backdrop site. My problem occurs on step 2, clicking the lin...*Created by: jenlampton*
Hello, I'm doing my best to follow the instructions on https://docs.civicrm.org/installation/en/latest/backdrop/ for how to add CiviCRM to an existing Backdrop site. My problem occurs on step 2, clicking the link to set up CiviCRM. The path `civicrm/setup` throws a 404 on my backdrop site.
I dug into the code for that page, and found that there wasn't any. the function `civicrm_setup_page()` doesn't seem to return HTML under any conditions (in one case it returns an empty string, and in the other it simply calls `exit();`).
Does this mean that the installer UI for Backdrop has not been built yet?