Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-29T00:28:52Zhttps://lab.civicrm.org/dev/core/-/issues/4985Custom radio/checkbox fields - maximum options per line - alignment lost2024-03-29T00:28:52ZsamuelsovCustom radio/checkbox fields - maximum options per line - alignment lostRegression following on #1821.
This is what we used to have (html table so everything is aligned):
![screen1](/uploads/afc5f71950f200da120187746e43f222/screen1.png)
This is what we have now:
![screen2](/uploads/c202f5aa0fccf732d96090...Regression following on #1821.
This is what we used to have (html table so everything is aligned):
![screen1](/uploads/afc5f71950f200da120187746e43f222/screen1.png)
This is what we have now:
![screen2](/uploads/c202f5aa0fccf732d96090fd2d385138/screen2.png)
Currently, it's almost impossible to fix it using css.https://lab.civicrm.org/dev/core/-/issues/902KAM keyboard shortcuts2024-03-28T15:46:04ZJoeMurrayKAM keyboard shortcutsAlthough there had been extensive testing of the KAM extension keyboard shortcuts (https://lab.civicrm.org/dev/accessibility/issues/1#note_11279), I'm not sure how extensive it was of the integration into core. This is a list of items th...Although there had been extensive testing of the KAM extension keyboard shortcuts (https://lab.civicrm.org/dev/accessibility/issues/1#note_11279), I'm not sure how extensive it was of the integration into core. This is a list of items that are needed to make the menu accessible according to WCAG 2.0 AA, so far as I can determine from various sites that provide suggestions on implementations for compliant menus, mainklyt WAI tutorials.
* [ ] The menu should receive the tab focus first, before other page elements. Currently, one has to tab through other page elements before entering the menu. On wpmaster, it takes 4 tabs, on dmaster it takes 24 tabs in order to get to QuickSearch.
* [ ] When focus is in QuickSearch, tab incorrectly moves next to browser address line. It should move forward to the menu item represented by the CiviCRM icon (I don't know its name).
Previous notes from when tabbing worked in the menu:
* [ ] When on a menu item with submenu open, space and return as well as escape should close it. Not a priority, but behaviour seems to be non-standard.
* [ ] When on an open sub-submenu (eg Contributions > Accounting Batches with Open Batches with focus), using left arrow correctly moved focus to Accounting Batches, but it did not close the sub-submenu. Not a huge priority for usability.https://lab.civicrm.org/dev/core/-/issues/3807Download invoice button on contribution fails to attach it to activity on win...2024-03-28T00:43:35ZDaveDDownload invoice button on contribution fails to attach it to activity on windowsEverything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when i...Everything else works, but the attachment doesn't get attached to the activity.
In https://github.com/civicrm/civicrm-core/blob/2aaf9d423288b5acb322379eb135324f380faca4/CRM/Core/BAO/File.php#L117-L130, it uses DIRECTORY_SEPARATOR when it should just always use '/', and in the one place it does need to use DIRECTORY_SEPARATOR it only checks '/':
```php
$path = explode('/', $data); // <--- THIS IS WRONG
$filename = $path[count($path) - 1];
// rename this file to go into the secure directory
if ($entitySubtype) {
$directoryName = $config->customFileUploadDir . $entitySubtype . DIRECTORY_SEPARATOR . $entityID;
}
else {
$directoryName = $config->customFileUploadDir;
}
CRM_Utils_File::createDir($directoryName);
if (!rename($data, $directoryName . DIRECTORY_SEPARATOR . $filename)) {
```https://lab.civicrm.org/dev/core/-/issues/3809[ext:message_admin] It's not obvious there's a preview function, and even whe...2024-03-28T00:43:21ZDaveD[ext:message_admin] It's not obvious there's a preview function, and even when told you might have trouble finding itIt should be a button on the message template edit page, down with the other buttons, where preview buttons normally are.It should be a button on the message template edit page, down with the other buttons, where preview buttons normally are.https://lab.civicrm.org/dev/core/-/issues/3808[ext:message_admin] Available preview choices should be based on the site's c...2024-03-26T18:25:12ZDaveD[ext:message_admin] Available preview choices should be based on the site's configIt has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.It has fixed choices. And formatting like the comma/dot separators it uses may or may not make sense for the selected preview.https://lab.civicrm.org/dev/core/-/issues/5069standalone: permanent "session already active" errors2024-03-26T14:20:29ZRichstandalone: permanent "session already active" errorsEvery page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* sessi...Every page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* session_start(): Ignoring session_start() because a session is already active [8]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 580
I first encountered this while reviewing https://github.com/civicrm/civicrm-core/pull/29352 but after experiencing it once, I could not get it to repeat, so thought it was a random local thing. But now it's back.
I have some installs that don't have it, and others that do; I'm trying to figure out how to reproduce/what makes the difference.https://lab.civicrm.org/dev/core/-/issues/4994Standalone - issues with haveibeenpwned on password setting screen?2024-03-26T11:33:19ZufundoStandalone - issues with haveibeenpwned on password setting screen?RichRichhttps://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-25T20:55:29ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Ok, but it smells bad to have columns belonging to one component in another component's table :nose: (fixme for another day) |
| `<localize_context>` | ✅ keep | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | Historically this was inferred by `<type>` but a few fields explicitly declare `<crmType>` |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename/reorganize | `attributes` | `type` gets moved out (see `<html><type>` below), while `length` gets moved in as `maxlength` |
| `<html><type>` | ⚠️ move/rename | `input_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5057Make descriptions visible in drop down2024-03-22T18:22:38ZyashodhaMake descriptions visible in drop downAll the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be help...All the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be helpful to choose options for the user(if options do indeed explanation and are configured as such)https://lab.civicrm.org/dev/core/-/issues/3833PHP 8.2 Dynamic Properties are deprecated2024-03-22T12:22:59ZBradley TaylorPHP 8.2 Dynamic Properties are deprecatedSee https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
...See https://wiki.php.net/rfc/deprecate_dynamic_properties.
I see this as a big one, which could require a significant number of fixes for CiviCRM. The RFC has a good example showing what has changed:
```
class User {
public $name;
}
$user = new User;
// Assigns declared property User::$name.
$user->name = "foo";
// Oops, a typo:
$user->nane = "foo";
// PHP <= 8.1: Silently creates dynamic $user->nane property.
// PHP 8.2: Raises deprecation warning, still creates dynamic property.
// PHP 9.0: Throws Error exception.
```
There are many uses of dynamic properties in CiviCRM core which fall into multiple categories:
1. Known undeclared properties. For example `CRM_Activity_Form_Task_Batch` repeatedly references `$_fields` which should just be defined.
2. Dynamic properties. The main example of this is `CRM_Core_DAO`. PHP allows for this use-case by either extending `stdClass` or using the new ` #[AllowDynamicProperties]` attribute. Where possible we should prefer extending `stdClass` which is likely to have better long-term support (i.e. into the PHP 9.x series)
3. Typo's etc. Cases where the property is defined, but later referenced with a different name. These are easy; we just fix the typo (whilst ensuring we don't break any backwards compatiability for plugins using the wrong spelling)
I suggest CiviCRM developers should start to be made aware of this now, to avoid making the problem worse. Incrementally starting to fix the issue, a class or two at a time, seems like a good idea.
In many cases it's not clear why dynamic properties (or declared properties for that matter) are being used instead of a standard variable. This might be a good chance to start annotating properties as either:
- `@api`; designed to be used within hooks, on singletons etc by CiviCRM extensions
- `@internal`; not designed to be used by extensions, and liable to be removed without deprecation.https://lab.civicrm.org/dev/core/-/issues/3769Change the default font family to sans-serif in print.css2024-03-19T20:19:43ZwmortadaChange the default font family to sans-serif in print.cssThe font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible ...The font family is set as `DejaVu Sans` but the fallback is `serif` in `print.css`. Surely this should be `sans-serif`?
See https://github.com/civicrm/civicrm-core/blob/master/css/print.css#L23
```
#crm-container {
overflow: visible !important;
font-family: DejaVu Sans, serif;
margin: 0px 10px 0px 10px;
}
```https://lab.civicrm.org/dev/core/-/issues/5086Ability to export FormBuilder forms from the UI2024-03-18T15:35:22ZherbdoolAbility to export FormBuilder forms from the UIWe've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to...We've got an export link for SearchKit, but if a saved search is wrapped up in a FormBuilder form there's no easy way to also export those files. I can imagine a modal with the text from the forms files (`*.html`, `*.json`) and a link to copy it. Or even ability to save the files as a zip file.
And I suppose we'd need an import link as well to import on a different site (similar to SearchKit's link).https://lab.civicrm.org/dev/core/-/issues/5045CiviCRM 5.70.0 - CiviCRM 5.72.alpha1, Manage Groups page (not SearchKit) the...2024-03-18T15:30:58Zjustinfreeman (Agileware)CiviCRM 5.70.0 - CiviCRM 5.72.alpha1, Manage Groups page (not SearchKit) the "quick edit" feature for the Group Title will include the "Child of" details in the editable fieldCiviCRM 5.70.0 - CiviCRM 5.72.alpha1, Manage Groups page (not SearchKit) the "quick edit" feature for the Group Title will include the "Child of" details in the editable field.
- Instead of editing: "Advisory Board"
- The text edited i...CiviCRM 5.70.0 - CiviCRM 5.72.alpha1, Manage Groups page (not SearchKit) the "quick edit" feature for the Group Title will include the "Child of" details in the editable field.
- Instead of editing: "Advisory Board"
- The text edited is: "Advisory BoardChild of: Summer Program Volunteers"
As shown below in screenshot from CiviCRM 5.72.alpha1 - https://dmaster.demo.civicrm.org/civicrm/group?reset=1
![image](/uploads/56206568c0a4103b7fa27f30602156d0/image.png)
Agileware Ref: CIVICRM-2224https://lab.civicrm.org/dev/core/-/issues/5044CiviCRM 5.70.0, When doing a back-end event registration for an Event which u...2024-03-18T15:30:22Zjustinfreeman (Agileware)CiviCRM 5.70.0, When doing a back-end event registration for an Event which uses a Priceset, the event registration allows a $0 registration fee which does not record any line itemsWhen doing a back-end event registration for an Event which uses a Priceset, the event registration allows a $0 registration fee which does not record any line items. This causes Priceset related errors when generating the emails using t...When doing a back-end event registration for an Event which uses a Priceset, the event registration allows a $0 registration fee which does not record any line items. This causes Priceset related errors when generating the emails using the Message Template. Event registration will just “hang” and the following logged to the error log.
```
An error of type E_ERROR was caused in line 474 of the file civicrm/CRM/Financial/BAO/Order.php. Error message: Uncaught TypeError: CRM_Financial_BAO_Order::getPriceSetID(): Return value must be of type int, null returned in
CRM/Financial/BAO/Order.php:474
```
CiviCRM 5.70.0
Agileware Ref: CIVICRM-2220https://lab.civicrm.org/dev/core/-/issues/5020Provide support for the Peppol standard to send invoices from CiviCRM to othe...2024-03-18T15:29:58Zjustinfreeman (Agileware)Provide support for the Peppol standard to send invoices from CiviCRM to other organisationsThis is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol stand...This is just a placeholder to see if there is any interest in providing support for the Peppol standard. Did some searching and couldn't find any mentions about this in Lab.
Basically, the idea is to provide support for the Peppol standard to send invoices from CiviCRM to other organisations. See https://peppol.org/ and participating organisations will be listed here, https://directory.peppol.eu/publichttps://lab.civicrm.org/dev/core/-/issues/1631Wrong behaviour on event Payment Information visibility for unpayed events2024-03-15T18:16:32ZfrancescbassasWrong behaviour on event Payment Information visibility for unpayed eventsOverview
----------------------------------------
When you edit an unpayed event registration, Payment Information section is visible by default even if "Record payment?" is unchecked.
Reproduction steps
--------------------------------...Overview
----------------------------------------
When you edit an unpayed event registration, Payment Information section is visible by default even if "Record payment?" is unchecked.
Reproduction steps
----------------------------------------
**Payment Information should be hidden**
1. Register a contact to an event without record any payment
2. Edit registration
3. Note that `Payment Information` section is visible
4. Check `Record Payment?` field
5. Note everything is still the same
6. Uncheck `Record Payment?` field
7. Note `Payment Information` section is hidden
**You may think that you are recording the contribution but the contribution is not recorded**
1. Register a contact to an event without record any payment
2. Edit registration
3. Note that `Payment Information` section is visible (with event fee set on the Amount field)
4. Click to save (without changing anything)
5. Note contribution was not recorded
Current behaviour
----------------------------------------
`Payment Information` section is visible for unpayed event registration editing form
![2020-03-04_17-13](/uploads/daacd3a4ce44727a748e1f8b94194a45/2020-03-04_17-13.png)
Expected behaviour
----------------------------------------
`Payment Information` section should be hidden for unpayed event registration editing forms and should appear when `Record Payment?` is checked.
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.26.alpha1/5.20.3/5.13.4/_https://lab.civicrm.org/dev/core/-/issues/470Current employer dissapears when disabling expired relationships2024-03-15T18:12:06ZfrancescbassasCurrent employer dissapears when disabling expired relationshipsOriginal issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current emplo...Original issue: https://issues.civicrm.org/jira/browse/CRM-21851
Affected versions: at least from 5.0.0
---
How to reproduce:
1) Create a current relationship on individual A as *employee of* organization B and mark as *current employer*
2) Create a past relationship on individual A as *employee of* organization B without marking as current employer
At this point on summary tab of individual A appears organization B as his Employer.
3) Run *Disable expired relationships* cron job
At this point on summary tab there is no organization at Employer field although there is one active employee relationship and past relationship was disabled.5.17.0https://lab.civicrm.org/dev/core/-/issues/3738Feature request - APIv4 Get action, provide ability to define aliases for the...2024-03-15T14:56:37Zjustinfreeman (Agileware)Feature request - APIv4 Get action, provide ability to define aliases for the select fields so that external integrations with CiviCRM do not break when the field name changes OR a different field is selectedThis is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enab...This is a Feature request. It would be great if you could define an **alias** for each _select_ **field** when using a **APIv4 Get action**. This alias should then be used as the output in the results for the Get action.
This would enable external CiviCRM integrations to be more robust, by allowing the fields selected in the Get action to be **changed** and but continue to use the **same alias**, thus not changing the structure of the results, the external integration would continue to work.
The other benefit would be that very long CiviCRM field names could be reduced to something shorter or more logical. eg. Instead of "email.email" the alias could just be set to "email". Or instead of "email_greeting_id:label" the alias could just be "email_greeting".
![image](/uploads/2ccae5082e4f50f5fc924d8e6998ffaa/image.png)https://lab.civicrm.org/dev/core/-/issues/4858Contact id quicksearch broken2024-03-15T13:24:20ZAndy ClarkContact id quicksearch brokenContact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a...Contact id quicksearch has broken in 5.67.3, albeit occasionally. User cannot locate any contacts by id at all, and using Drupal 'masquerade I verified this to be the case. The fix was to run the 'Cleanup Caches' option. What may be a clue is that this system uses ACLs and although this user would have been restricted by ACLs she would have had access to the contacts she was searching for. As an administrator I could see the contacts when she couldn't which does seem to point to ACLs as the problem.https://lab.civicrm.org/dev/core/-/issues/5091crm.ajax.js uses synchronous XHR2024-03-15T02:24:51ZJonGoldcrm.ajax.js uses synchronous XHROverview
----------------------------------------
When editing a contribution loaded in a modal, if the server is configured to disallow synchronous XHR, the "Cancel" and "Save" buttons don't appear.
Example use-case
------------------...Overview
----------------------------------------
When editing a contribution loaded in a modal, if the server is configured to disallow synchronous XHR, the "Cancel" and "Save" buttons don't appear.
Example use-case
----------------------------------------
1. In your web server config, modify your Permissions-Policy or add one that disables synchronous XHR, e.g. for Apache:
```
Header always set Permissions-Policy "sync-xhr=()"
```
1. Click **Edit** next to a contribution (without opening in a new tab, so it appears in a modal).
Current behaviour
----------------------------------------
"Cancel" and "Save" buttons are missing.
Proposed behaviour
----------------------------------------
"Cancel" and "Save" buttons should appear.
Comments
----------------------------------------
The console error is:
```
[Violation] Permissions policy violation: Synchronous requests are disabled by permissions policy.
```
It faults `crm.ajax.js` line 329 (currently: `that.element.html(data.content);`).
Per the [XHR spec](https://xhr.spec.whatwg.org/#the-open()-method):
> Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user’s experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when the current global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" DOMException when it occurs.
This isn't urgent - most folks aren't blocking Synchronous XHR - but since this is the only issue I've seen in months of having this permissions policy, it seems like we can get atop things.