CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2021-05-31T15:47:08Zhttps://lab.civicrm.org/dev/core/-/issues/2369Fatal error reported when photo cannot be found2021-05-31T15:47:08Zmagnolia61Fatal error reported when photo cannot be foundI use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of cor...I use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of core scope (reported it [there](https://lab.civicrm.org/extensions/reporterror/-/issues/3#note_53134) also)
I have been experiencing this since quite a few versions of CiviCRM back. Currently running 5.34 (Drupal 7.78)
Could it be that the code for this in core is a bit too harsh?
```
[error]
$Fatal Error Details = array:3 [
"message" => "Photo does not exist"
"code" => null
"exception" => CRM_Core_Exception {#3616
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: "Photo does not exist"
#code: 0
#file: "/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php"
#line: 58
trace: {
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php:58 {
› else {
› throw new CRM_Core_Exception(ts('Photo does not exist'));
› }
}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:312 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:68 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/drupal/civicrm.module:458 { …}
/var/www/vhosts/xyz/web/includes/menu.inc:527 { …}
/var/www/vhosts/xyz/web/index.php:21 { …}
}
}
]
```5.39.0https://lab.civicrm.org/dev/core/-/issues/2366php 7.4 - get_magic_quotes_gpc() deprecated in IDS_Monitor2021-04-13T00:10:20ZDaveDphp 7.4 - get_magic_quotes_gpc() deprecated in IDS_Monitor`Deprecated function: Function get_magic_quotes_gpc() is deprecated in IDS_Monitor->_detect() (line 338 of ...\vendor\civicrm\civicrm-packages\IDS\Monitor.php).`
Also line 342.
Function will be removed in php 8.
Hmm. This package is v...`Deprecated function: Function get_magic_quotes_gpc() is deprecated in IDS_Monitor->_detect() (line 338 of ...\vendor\civicrm\civicrm-packages\IDS\Monitor.php).`
Also line 342.
Function will be removed in php 8.
Hmm. This package is very old.5.37.0https://lab.civicrm.org/dev/core/-/issues/2258Re-Thinking our Crypto implementation2023-07-09T05:03:24ZseamusleeRe-Thinking our Crypto implementation_Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted wit..._Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted within the database e.g. Payment Processor Passwords.
_Problems_:
1. Not easily able to determine what Crypto method has been used (Mcrypt or Base64 encoded only) to save the SMTP password.
2. Not easily to assess which extensions have had fields encrypted (e.g. know that Sparkpost has encrypted their API key but other than that unsure)
3. Relies on CIVICRM_SITE_KEY (which is maybe over-using that value).
4. Linked to Item 2, is there is no way for the API/DAO/Extensions to know what fields have been encrypted so to decrypt code appropriately.
_Potential ideas_:
1. Create a setting which stores the encryption class and use a factory / hooks to allow for extensions to customise which crypto library to use within CiviCRM
2. Have a hook / use some level of meta data to determine if a field is to be encrypted
_Discussion Questions_:
1. Should we completely break CRM_Utils_Crypt class as we re-work the encryption within the app
2. How should we handle switching between Crypto libraries?
3. Should extensions be able to use their own Crypto Library whilst leaving rest of the App to use a system specific Crypto?
4. Do we want to allow for civicrm.settings.php defines / environment variable overrides for encrypted fields / data points?https://lab.civicrm.org/dev/core/-/issues/2256create contact: subtype retained after removal2024-02-29T05:03:24Zlcdwebcreate contact: subtype retained after removalTo recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype i...To recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype is created.
Actual result: the student subtype is retained.
I suspect what's happening is that on form submission the subtype field is getting reset via the URL param.
But it poses a question, as I think there are two ways we could approach this:
1. fix the form per the above. on submission, ensure we process the form field value and don't allow the URL param to reset it.
2. freeze the subtype field. one could argue that if I'm choosing to create a New Student I should be locked into that path. we could check to see if a URL param for subtype was passed and then freeze that field. the downside is that it would prevent you from setting multiple subtypes for the contact.
Would like to get some opinions/thoughts from the community before I work on a patch.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2208Enforce default country setting globally2023-06-26T05:03:15ZandyburnsEnforce default country setting globallyIf you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used...If you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used in listings mode.
Noting @JonGold made an extension that solves this: https://civicrm.stackexchange.com/questions/20986/show-default-country-and-state-for-public-proximity-searchhttps://lab.civicrm.org/dev/core/-/issues/2207Allow default fields per profile2023-06-12T05:03:16ZandyburnsAllow default fields per profileFeature request: Allow profiles to set a default form field value at the form level.
One example is I'd like to set the default country to United States. Note that setting your default country under https://example.org/wp-admin/admin.p...Feature request: Allow profiles to set a default form field value at the form level.
One example is I'd like to set the default country to United States. Note that setting your default country under https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 does not default it in the profile listings.https://lab.civicrm.org/dev/core/-/issues/2202Confusing note regarding ACLs for events2023-06-03T05:03:28ZfkohrtConfusing note regarding ACLs for eventsOverview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event A...Overview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event ACLs, the 'View' operation allows access to the event information screen. "Edit" allows users to register for the event if online registration is enabled.
Please remember that Drupal's "register for events" permission overrides CiviCRM's control over event information access.
I find this wording highly confusing for several reasons.
Current behaviour
----------------------------------------
1. Reading `event information screen` I thought only page visits of `/civicrm/event/info` are affected, when in fact, this also concerns the events I see in the backend's event dashboard at `/civicrm/event`. I think I would have correctly guessed what the _View_ permission does without this note.
2. Reading `"Edit" allows users to register for the event if online registration is enabled.`...
1. I thought this has nothing to do with configuring events in the backend, when in fact, this is just exactly that. Again, I find this note more confusing than helpful.
2. I am additionally confused as a user of the [Webform CiviCRM Integration](https://www.drupal.org/project/webform_civicrm) because my participants never use CiviCRM's online registration feature. So I am asking myself “Does this cover my use case as well?” and “Who actually needs the permission to edit in my case?”
3. If I allow anonymous users to access all events on Drupal's permission page and also grant _Edit_ permissions via CiviCRM's ACLs, then those users granted edit rights __do not__ have the right to _View_ other events anymore. The UI does not inform me about this behaviour.
4. Reading `View` and `Edit` I wonder whether the latter includes the former. Would make sense, but I don't know from the UI.
Proposed behaviour
----------------------------------------
1. Maybe this should read `[...] allows access to the event's information.`
2. (see the suggestions below)
1. Maybe add a clause that the _Edit_ permission also allows configuring the event in the backend. But isn't this even more confusing then, because the _Edit_ permission allows event configuration __and__ event registration (two rights that most would think are different)?
2. Maybe add an explanation for those who register their participants through Drupal's Webform module.
3. Maybe add a clause that explains that once any of the _View_ or _Edit_ permissions is given through the ACLs, Drupal's CiviEvent permissions _view event info_ is overriden, even granted for anonymous users (at least that's how I understand it).
4. Maybe add a clause that _Edit_ includes the right to _View_ (if this is the case),
Comments
----------------------------------------
I am using CiviCRM 5.31 on Drupal 8https://lab.civicrm.org/dev/core/-/issues/2189Activity Type cleanup2023-06-15T05:03:16ZJonGoldActivity Type cleanupCurrently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed...Currently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed Invoice" for CiviContribute) don't have a `component_id` assigned.
It also seems that "Meeting" and "Phone Call" are set as `is_reserved`, but there aren't any references to those in the codebase such that disabling or deleting them should affect a Civi install.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2187Allow for the default number of search results to be configurable2021-09-07T10:20:35ZseamusleeAllow for the default number of search results to be configurableOverview
----------------------------------------
At the present moment the default number of results to be returned on a search is hard coded to 50 in `CRM/Utils/Pager.php` this should ideally be configurable using settings
Example use...Overview
----------------------------------------
At the present moment the default number of results to be returned on a search is hard coded to 50 in `CRM/Utils/Pager.php` this should ideally be configurable using settings
Example use-case
----------------------------------------
A site wants to show 100 contacts / memberships / grants etc on a screen at a time rather than 50
Current behaviour
----------------------------------------
Hard coded default value of 50
Proposed behaviour
----------------------------------------
Create a setting to handle the default value and set it on various search forms.5.39.0https://lab.civicrm.org/dev/core/-/issues/2161Proposal - encourage use of PSR-3 log placeholders when logging variable valu...2021-04-26T13:10:50ZDaveDProposal - encourage use of PSR-3 log placeholders when logging variable values with Civi::log()Reference: Link to docs about [PSR-3 placeholders](https://github.com/php-fig/fig-standards/blob/c0e0f9982410185fa3123913457414b6d4a3f5cd/accepted/PSR-3-logger-interface.md#12-message)
Currently Civi::log() is implemented by CRM_Core_Er...Reference: Link to docs about [PSR-3 placeholders](https://github.com/php-fig/fig-standards/blob/c0e0f9982410185fa3123913457414b6d4a3f5cd/accepted/PSR-3-logger-interface.md#12-message)
Currently Civi::log() is implemented by CRM_Core_Error_Log which is a minimal implementation of PSR-3 logging. Currently to represent non-string variable values in log messages you either need to flatten them to a string first, or, you can pass them in the $context parameter, but that whole array just gets print_r'd and any intended use of placeholders in the actual message string is ignored and the placeholder word is output literally. It's useful, just doesn't encourage the use of placeholders, which are desired so that other log implementations can reformat the values as they see fit. It's desirable for string variable values too - implementations can choose to just insert inline into the output in place of the placeholder, or not. And if it wants it could choose to do that just for strings, and only reformat non-string objects separately.
There aren't that many calls to Civi::log yet in core, so it might not be a huge task. Or at least going forward encourage the use of placeholders for variables, and clean up existing usage as it comes up.
By placeholders I mean something like:
`Civi::log()->error('Hello {name}, how are you today?', ['name' => $username]);`
instead of
`Civi::log()->error("Hello $username, how are you today?");`
Also think about how any core implementation affects drupal watchdog, which also is slightly different in drupal 7 vs 8. See also https://github.com/civicrm/civicrm-core/pull/18864#issuecomment-722199365
Related to that, most other languages' logging frameworks have a queue of log listeners, so that you can log to multiple targets at once. I'm not sure if it's just because this is all a retrofit to existing civi code or if I just haven't figured out how to do it, but it seems like you can only have one log listener at a time? The drupal watchdog part is hardcoded in debug_log_message().https://lab.civicrm.org/dev/core/-/issues/2159Proposal replace PEAR mailer classes in core extension2023-06-12T05:03:15ZeileenProposal replace PEAR mailer classes in core extensionI'm proposing that we add a new core extension that swaps out the existing Pear Mailer classes with a more modern and better supported library.
Per the above comment the reason is largely that I think PEAR mail is not well supported or ...I'm proposing that we add a new core extension that swaps out the existing Pear Mailer classes with a more modern and better supported library.
Per the above comment the reason is largely that I think PEAR mail is not well supported or future proofed - but here are some other advantages of modern libraries - these apply to PhpMailer but may equally apply to others
1) SMTP failover - phpmailer (& others) allow you to specify more than 1 smtp server and will use a different one if the first is down
2) SMTP auth over LOGIN, PLAIN, CRAM-MD5, XOAUTH2.
3) Multilanguage support for error messages.
4) Better developer docs
5) More widely used used - ie by WP, Joomla and Drupal.
**Contenders**
[PhpMailer](https://github.com/PHPMailer/PHPMailer)
[SwiftMailer](https://swiftmailer.symfony.com/)
[Zeta-components](http://zetacomponents.org/documentation/trunk/Mail/tutorial.html)
[Omnimail](https://github.com/omnimail/omnimail)
I've mostly focussed on PhpMailer as it seems to be the most prevalent without any obvious downsides but there isn't that much in it. Regardless, I think agreeing a package & that we should do this is the hardest part of this task.
https://php.libhunt.com/compare-phpmailer-vs-swiftmailer
https://alexwebdevelop.com/phpmailer-tutorial/
Google trends https://trends.google.com/trends/explore?date=all&q=phpmailer,swiftmailer
I'm not sold on the Omnimail library as better than just PhpMailer - it adds a few more variants - but it wraps them (which is good) but such that some options are not available - eg https://github.com/shahariaazam/smtp-mailer/pull/1
The Omnimail maintainer has been good at merging PRs but it's not that active - so if we went that way it would be because we feel it's better than writing a wrapper ourselves.
**Implementation**
The process for swapping out a mailer class is pretty simple - ie
```
/**
* Implements hook_civicrm_container().
*/
function omnimail_civicrm_container(\Symfony\Component\DependencyInjection\ContainerBuilder $container) {
$container->setDefinition('pear_mail', new Definition('Civi\Omnimail'))
->setFactory('Civi\Omnimail\MailFactory::getFactoryMailer')->setPublic(TRUE);
}
```
The challenge is that the signature is a bit Pear-shaped (hah) - so we need a class that does the mapping. Note that for the first one we can assume an array in our implementation.
```
* @param mixed $recipients Either a comma-seperated list of recipients
* (RFC822 compliant), or an array of recipients,
* each RFC822 valid. This may contain recipients not
* specified in the headers, for Bcc:, resending
* messages, etc.
*
* @param array $headers The array of headers to send with the mail, in an
* associative array, where the array key is the
* header name (ie, 'Subject'), and the array value
* is the header value (ie, 'test'). The header
* produced from those values would be 'Subject:
* test'.
*
* @param string $body The full text of the message body, including any
* Mime parts, etc.
*
* @return mixed Returns true on success, or a PEAR_Error
* containing a descriptive error message on
* failure.
```
**Preliminary work**
We want to fix it to throw an exception rather than return a PEAR_Error on fail as the latter if VERY Pear-shaped. We can just catch any exception.https://lab.civicrm.org/dev/core/-/issues/2158Proposal - remove detail about updating related components when editing a con...2020-11-12T20:48:25ZeileenProposal - remove detail about updating related components when editing a contribution statusI'd like to propose removing the chunk of code that sets a message about related entities being updated when a Contribution Status is edited on the contribution page.
The reason is this code is somewhat toxic in itself but deeply couple...I'd like to propose removing the chunk of code that sets a message about related entities being updated when a Contribution Status is edited on the contribution page.
The reason is this code is somewhat toxic in itself but deeply coupled with the highly toxic 'transitionComponents' function and does not cope well with the scenario where another function (the hook in the cancelcontributioncancel actions or another extension) intervenes and the status is updated in some different way.
We could load the related entities on the form & be more sophisticated about creating a message - but my feeling is that we wouldn't lose much if we just removed it (it's a back-office form & I suspect users just check other tabs on the contact rather than reading the detail of the message.) If the form did a little less I believe it could be more robust about it
```
// get the status message for user.
foreach ($updatedComponents as $componentName => $updatedStatusId) {
if ($componentName == 'CiviMember') {
$updatedStatusName = CRM_Utils_Array::value($updatedStatusId,
CRM_Member_PseudoConstant::membershipStatus()
);
$statusNameMsgPart = 'updated';
switch ($updatedStatusName) {
case 'Cancelled':
case 'Expired':
$statusNameMsgPart = $updatedStatusName;
break;
}
$statusMsg .= "<br />" . ts("Membership for %1 has been %2.", [
1 => $userDisplayName,
2 => $statusNameMsgPart,
]);
}
if ($componentName == 'CiviEvent') {
$updatedStatusName = CRM_Utils_Array::value($updatedStatusId,
CRM_Event_PseudoConstant::participantStatus()
);
if ($updatedStatusName == 'Cancelled') {
$statusMsg .= "<br />" . ts("Event Registration for %1 has been Cancelled.", [1 => $userDisplayName]);
}
elseif ($updatedStatusName == 'Registered') {
$statusMsg .= "<br />" . ts("Event Registration for %1 has been updated.", [1 => $userDisplayName]);
}
}
if ($componentName == 'CiviPledge') {
$updatedStatusName = CRM_Utils_Array::value($updatedStatusId,
CRM_Contribute_PseudoConstant::contributionStatus(NULL, 'name')
);
if ($updatedStatusName == 'Cancelled') {
$statusMsg .= "<br />" . ts("Pledge Payment for %1 has been Cancelled.", [1 => $userDisplayName]);
}
elseif ($updatedStatusName == 'Failed') {
$statusMsg .= "<br />" . ts("Pledge Payment for %1 has been Failed.", [1 => $userDisplayName]);
}
elseif ($updatedStatusName == 'Completed') {
$statusMsg .= "<br />" . ts("Pledge Payment for %1 has been updated.", [1 => $userDisplayName]);
}
}
}
```5.33.0https://lab.civicrm.org/dev/core/-/issues/2155Remove 'onlinePendingContribution' payment support from membership edit form2020-11-16T20:05:33ZeileenRemove 'onlinePendingContribution' payment support from membership edit formI want to proposed removing support for 'onlinePendingContribution' from the Membership Edit form.
**What is onlinePendingContribution support you ask?**
It's this box on the membership edit form
![Screen_Shot_2020-10-31_at_6.30.02_PM]...I want to proposed removing support for 'onlinePendingContribution' from the Membership Edit form.
**What is onlinePendingContribution support you ask?**
It's this box on the membership edit form
![Screen_Shot_2020-10-31_at_6.30.02_PM](/uploads/10211382f41b9d0fe92362f620e68d6e/Screen_Shot_2020-10-31_at_6.30.02_PM.png)
**Hey but I've never seen that box!**
Well you only see if if someone has created a pending pay later membership through an online form which you later complete through the membership edit form
**And it allows you to send a customised receipt?**
No, it says you can, you can't
**How else would someone complete that contribution?**
Well - they could do it the same way they would for a pending contribution created in any other way - use the link a moment further down the page
![Screen_Shot_2020-10-31_at_6.27.20_PM](/uploads/3e29866a816528a9265a26a852aa73de/Screen_Shot_2020-10-31_at_6.27.20_PM.png)
**And why do you want to remove it**
There is considerable code complexity needed to support it - about 85 lines of code. Oh, and it's broken in master
**But how do we know no-one is using it**
Well I tested on 5.21 & it's broken there too so my guess is is has broken for a long time....5.33.0https://lab.civicrm.org/dev/core/-/issues/2123Multivalue contact reference field2022-07-26T10:10:17ZMichael McAndrewMultivalue contact reference fieldThe current contact reference field only allows a single contact reference.
A contact reference field that allows multiple contacts would be really useful for some use cases, e.g. https://civicrm.stackexchange.com/questions/30405/custom...The current contact reference field only allows a single contact reference.
A contact reference field that allows multiple contacts would be really useful for some use cases, e.g. https://civicrm.stackexchange.com/questions/30405/custom-field-multiple-contact-references
What would it take to add an option to the Contact Reference field type to allow it to contain multiple contact references?
Similar 'Multi-select' functionality is exposed for the following field types:
- Alphanumeric > Select
- Country
- Integer > Select
- Alphanumeric > Checkbox is inherently multi-select.
IIRC, in each of these cases, references to multiple contacts are stored in the database in a single field with the null character used to separate the various multiple options. Certainly that is the case for the Country field when I looked just now.
Although this approach means that we can't do any referential integrity checking for these fields, it does make the database architecture more straight forward (less joins, etc.). And the plumbing already exists to allow queries along the lines of 'Show me all contacts where this value is one of the multi-values' in advanced search and (I think I am right in saying) api3 and 4.
My instinct is that it would be a good idea to follow this precedent for multi-value contact reference fields.
Some alternatives:
- The approach used for Activity target contacts. Although this is more conventional approach it seems so outside of the approach that we can taken to custom data so far that I am not sure that we could actually implement it
- Use multiple record custom data sets. These can only be added to contacts, and one has to define this at the custom data _set_ level which would restrict its usefulness.
At this stage I am looking for thoughts on feasibility, gotchas, links to any related / relevant / previous / discussion, wondering if it has been tried before, etc.
Thanks for your input :)https://lab.civicrm.org/dev/core/-/issues/2116Extensionise core components2023-10-15T05:11:44ZeileenExtensionise core components@mattwire I've opened this to track your interest in moving civimember to a core extension. In general I agree that it's a long term goal to structure our code this way - it would move us to better interactions (hooks rather than hacked ...@mattwire I've opened this to track your interest in moving civimember to a core extension. In general I agree that it's a long term goal to structure our code this way - it would move us to better interactions (hooks rather than hacked in code).
I don't think anyone should have the expectation of any functionality change in this process - but moving to more standardised interactions should have spin off benefits in allowing us to simplify code.
We currently have a process - ie create the extension as a hidden extension & start moving functionality over until it can stand alone - at which point we unhide it. We have 2 in progress
- event cart
- financial acls
The latter is not blocked on anything but is going to take time. The former will also take time but is also has a specific blockage in that we don't have a process to install extensions on new install that also does the DB layer stuff. If might be possible to make the extension fully optional & by pass that (ie not install it on new installs) but the install issue would be a blocker to doing similar for other components - eg. civigrant.
My personal preferred approach would be to keep chipping away at the 2 in progress ones so that they can be enabled on demand on install rather than always and then around Feb or March get a block of @totten time blocked out to address the install issue properly.
If we were to do a full core component I'd rather start with civigrant as the most doable and learn from that.https://lab.civicrm.org/dev/core/-/issues/2115Move financialACLs to a core extension2023-08-30T05:03:25ZeileenMove financialACLs to a core extensionThis work has already started with the code being moved from LineItem api to a pre hook in the hidden ext/financialacls extension.
The definition of done is:
1) we find all places that refer to isACLFinancialTypeStatus & find a way to m...This work has already started with the code being moved from LineItem api to a pre hook in the hidden ext/financialacls extension.
The definition of done is:
1) we find all places that refer to isACLFinancialTypeStatus & find a way to move them over
2) at that point it should be possible to unhide the extension and allow people to enable it only if they want it
3) we would reconcile it with the extension outside of core & consolidate
@monish.deb @JoeMurray @seamuslee this is really just creating a GL for what we have already discussed. Since it's membership-theme-month I'm gonna take a look at the bits of this as relate to membershiphttps://lab.civicrm.org/dev/core/-/issues/2092Dedupe SUBSTR scalability problems2023-05-13T05:03:22ZJoeMurrayDedupe SUBSTR scalability problemsOverview
----------------------------------------
_When length of field is used in dedupe rules, rules tend not to work even on medium size sites._
Reproduction steps
----------------------------------------
1. On a site with 70k contac...Overview
----------------------------------------
_When length of field is used in dedupe rules, rules tend not to work even on medium size sites._
Reproduction steps
----------------------------------------
1. On a site with 70k contacts, a dudupe rule was defined that included first name (length 1), last name, email, phone, postal code.
1. Check for dedupes times out after 20m. On different runs it also took down MySQL with out of memory, and caused restarts of php-fpm.
1. Changing rule to first name, last name, email, phone, postal code yields 18.5k potential duplicate pairs in 3 minutes.
1. FWIW, using the deduper extension from Eileen didn't help with batch limit of 1000, but did improve things with search limit of 1000.
Current behaviour
----------------------------------------
Timeouts, mysql restarts, php restarts when using length restrictions on fields.
Expected behaviour
----------------------------------------
No timeouts or process restarts on medium sized databases even when using length restrictions on fields.
Implementation Alternative
----------------------------------------
The problem seems to stem from subquery join on substring function, which is well known to be not optimizable by MySQL: ON (SUBSTR(t1.first_name, 1, 1) = SUBSTR(t2.first_name, 1, 1)). Instead of this approach, one can imagine using Temporary tables that include SUBSTR(t.first_name, 1, 1) as a field that has index, and then the join would be optimized. While we use temp tables in reports, they do have the potential of causing their own issues, but I believe they are much reduced from the current situation here.
We don't currently have funding to work on this. Nonetheless, I thought it would be useful to report the problem and ask if there is approval for the concept of using temp tables with indexed fields for dedupe search criteria based on substrings?
I've labelled this as both improvement and bug since it seems to straddle the divide.https://lab.civicrm.org/dev/core/-/issues/2044Proposal apiv4 - revisit required parameters on location entities2020-10-02T01:41:10ZeileenProposal apiv4 - revisit required parameters on location entitiesI propose we adjust the location api required fields inn v4api
- Address - don't require contact_id, make location_type_id required in xml
- Email - don't require contact_id, make location_type_id required in xml
- Phone - don't require...I propose we adjust the location api required fields inn v4api
- Address - don't require contact_id, make location_type_id required in xml
- Email - don't require contact_id, make location_type_id required in xml
- Phone - don't require contact_id, make location_type_id required in xml
For all these entities we have a valid use case for no contact_id in the context of location blocks for addresses. I wanted to cleanup the code in ManageLocation around addresses https://github.com/civicrm/civicrm-core/pull/18488 & found I can't use Address::save to do in a better way due to the above
@colemanw how far did you go down this path?5.31.0https://lab.civicrm.org/dev/core/-/issues/1995Profile and other forms user-friendly urls/aliases2023-04-25T05:03:24ZW01FProfile and other forms user-friendly urls/aliasesCurrently when you use a profile form (or contribute form, etc.) the path resembles something like:
/civicrm/profile/create?gid=15&reset=1
This is not very user-friendly or good for SEO, and there doesn't seem to be a way to fix this. F...Currently when you use a profile form (or contribute form, etc.) the path resembles something like:
/civicrm/profile/create?gid=15&reset=1
This is not very user-friendly or good for SEO, and there doesn't seem to be a way to fix this. For example, in a Drupal integration, attempting to set an alias for the path to something like "/register/blogger" will result in an access denied notice.
There are several reasons why a built-in path alias for profiles, contribute forms, etc. would be a good idea and I think it would be fairly simple to implement in the CiviCRM advanced settings for those forms.https://lab.civicrm.org/dev/core/-/issues/1992Proposal to remove the duplication of buttons that CiviCRM displays on Contri...2020-09-17T09:47:23Zjustinfreeman (Agileware)Proposal to remove the duplication of buttons that CiviCRM displays on Contribution and Event pages, often appearing both at the top and bottom of the page.Proposal to remove the duplication of buttons that CiviCRM displays on Contribution and Event pages, often appearing both at the top and bottom of the page. Many users think this is a bug and ask for the duplicate button(s) to be removed.Proposal to remove the duplication of buttons that CiviCRM displays on Contribution and Event pages, often appearing both at the top and bottom of the page. Many users think this is a bug and ask for the duplicate button(s) to be removed.