Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-11-10T07:07:58Zhttps://lab.civicrm.org/dev/core/-/issues/3966Contact ID, External ID and CRM User ID should only be shown once on the cont...2022-11-10T07:07:58ZlarsssandergreenContact ID, External ID and CRM User ID should only be shown once on the contact pageCurrently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm...Currently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm/civicrm-core/pull/24883) will add CRM User ID to the footer as well.
![image](/uploads/4aa3cf01bb4ed418a9c8aaae4ee30dd5/image.png)
I think we should not be duplicating this data on the Contact page. Either it should be shown in a block or it should be shown in the footer, but not both by default as that just wastes space and contributes to an overly busy UI that discourages adoption of CiviCRM.
I think it makes sense to separate the Tags block from the IDs and Contact Type block, as these are very different pieces of data and some may want to see one and not the other.
Some options:
1) Show Contact ID, CRM User ID, External ID and Contact Type in the footer. Remove the Summary tab block with these items, leaving just the Tags block. Or, if we want to give people the option to show the IDs and Contact Type as a block, keep it available, but not visible by default (like the Open ID block, which still exists, but isn't shown by default on new installs). The downside of showing this data in the footer is it is not configurable like the blocks are. The advantage is that the footer is less prominent than a block, which fits with the lower importance of this data, and the footer is visible on all Contact tabs, not just the Summary.
2) Remove all of these items from the footer and only show them in a block.
3) Make the footer only visible to those with Administer CiviCRM permission (as a convenience for admins) and also show the IDs in a block for everyone.
4) Keep everything as is, there are good reasons to duplicate this information.https://lab.civicrm.org/dev/core/-/issues/3964Activity import: source_record_id field not importable2022-12-12T16:43:41ZSandor SemseyActivity import: source_record_id field not importableOverview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to th...Overview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to the relevant DAO, `source_record_id` can be mapped and imported successfully.
I haven't found any references except for this unresolved StackExchange question (https://civicrm.stackexchange.com/questions/33639/importing-signatures-into-petition) and a related issue (https://lab.civicrm.org/dev/core/-/issues/1380) where the OP wants to import petition signatures into Civi.
I checked the oldest available version of Civi on GitHub and this field wasn't marked as importable even then. So this seems quite historical.
I wonder, is there any reasons why this field can't be imported?
Example use-case
---
Importing petition signatures from other systems to CiviCRM.
Current behaviour
---
Not possible to import `source_record_id` for activities.
Proposed behaviour
---
Possible to import `source_record_id` for activities.
Comments
---
I'm happy to open a PR if it gets approved.https://lab.civicrm.org/dev/core/-/issues/3961Proposal: Create stub extensions for civicrm core + all components2023-07-13T10:41:05ZcolemanwProposal: Create stub extensions for civicrm core + all components*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so i...*Edited to reflect the current state of things, some comments reply to an earlier revision*
**Motivation 1:**
Require SearchKit in core. This has been [solved in a different way](https://github.com/civicrm/civicrm-core/pull/24739) so is no longer relevant to this issue.
**Motivation 2**
We are starting to package SearchKit displays as replacements for Smarty/DataTables in the UI. This has worked out great for CiviGrant: now that it's an extension we can easily package Afforms, SavedSearches and other managed entities with it. But other components are not extensions and so have no mechanism for including their own managed entities, afforms, etc. Components are less modular and more monolithic than extensions.
**Motivation 3**
Currently an extension has no way to require a component, e.g. an extension cannot declare a dependency on CiviEvent.
**Motivation 4**
Extensions and Components are similar but not the same, and this is confusing to new users and new developers. In most respects Extensions are better than Components, and it would be great to "some day" have all components simply be extensions.
**Proposal**
Given the experience of converting CiviGrant to an extension was a "harder than expected" undertaking, I think converting all other components to extensions at once is not a realistic goal. It would need to be a slow, iterative process, and I propose this as the first iteration:
1. Create a small stub extension for each component (CiviEvent, CiviContribute, etc).
2. Use hooks to sync between the `civicrm_extension` table and the `civicrm_component` table, so that enabling the "CiviEvent" extension also enables the "CiviEvent" component, and vice-versa.
3. Get rid of the "Manage Components" screen. Admins can enable/disable components via the "Manage Extensions" screen.https://lab.civicrm.org/dev/core/-/issues/3959Event Scheduled Reminder Behavior2022-11-10T07:20:20ZLKuttnerEvent Scheduled Reminder BehaviorI am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at...I am wondering if this behavior has been changed-- I did not see any online mention of a change with Scheduled Reminders.
Scenario: A schedule event reminder was set for 24 hours before the event start time 4:00 PM Tuesday.
On Monday at 4:00 PM, 24 Hours before the event, the reminder is successfully sent to registered attendees.
On Tuesday, the day of the event, additional contacts register.
Expected behavior: The scheduled reminder that was sent on the previous day is NOT sent to new registrants.
Experienced behavior: The reminder scheduled for the previous day is sent ten minutes after a new contact registered.
I do not find any explanation for the later sent reminder emails.
This is with CiviCRM 5.45.7 on Drupal 7 with PHP 7.3.29https://lab.civicrm.org/dev/financial/-/issues/211Sending receipt auto when editing a payment (editing financial trx payment)2023-01-18T20:26:40Zlevi.kSending receipt auto when editing a payment (editing financial trx payment)@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial...@JoeMurray
Steps to reproduce
1. Add a contribution
2. Edit the payment (the edit needs to be of the sort that will create a minus and plus transaction) like changing a payment method
(This does not happen when editing the financial type on the contribution eventhough it effects a plus and minus transaction (when the account is different))
3. The system will then send a unwanted email receipt (think its using the payment receipt (not contribution receipt)
Drupal 7
civicrm 5.53.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/3958PHP 8.2 deprecations2024-01-11T18:55:35ZseamusleePHP 8.2 deprecationsThis is to be a catch all issue for working on PHP8.2 issues
@bradleyt had already created the following issues for some specific PHP8.2 issues
* [Dynamic Properties are Deprecated](https://lab.civicrm.org/dev/core/-/issues/3833)
* [De...This is to be a catch all issue for working on PHP8.2 issues
@bradleyt had already created the following issues for some specific PHP8.2 issues
* [Dynamic Properties are Deprecated](https://lab.civicrm.org/dev/core/-/issues/3833)
* [Deprecated ${} string interpolation](https://lab.civicrm.org/dev/core/-/issues/3831)
* [utf8_encode and utf8_decode functions deprecated](https://lab.civicrm.org/dev/core/-/issues/3832)
There are probably others out there but adding this to help us navigate to the various sub issueshttps://lab.civicrm.org/dev/core/-/issues/3955Add show spaces remaining setting for price set fields2023-05-30T22:23:49ZlarsssandergreenAdd show spaces remaining setting for price set fieldsWith multiple participant registrations and price set options with registration limits, the fact that registrants can't see how many spaces are remaining in a specific option can cause a lot of frustration. What happens is Bob wants to r...With multiple participant registrations and price set options with registration limits, the fact that registrants can't see how many spaces are remaining in a specific option can cause a lot of frustration. What happens is Bob wants to register his family of four for a workshop that only has space remaining for three people. He fills out his details, selects the workshop, fills out his 2nd and 3rd family members' details and selects the workshop for them and only when he arrives on the 4th family members' registration page does he find out there aren't actually enough spaces in the workshop for his family. So he goes back to the start, changes the workshop to another one for each family member one by one, only to find out that the substitute workshop only has space for two... Cue frustration and annoyed emails or, even worse, Bob gives up and doesn't register at all.
To prevent this issue, I propose to add an option to price fields called "Show spaces remaining", which would only be shown when the price set is used for event registration. When this is enabled, each price option will include "(N left)" at the end of the option label, where the (Sold out) text would go, e.g. Identifying pinecones - $ 5.00 (4 left). Of course, this won't be shown for sold out options or options with no limit.
On the backend only, this will also be shown for oversubscribed options (N over limit), replacing (Sold out).
With the recent work I've done to simplify the process of building the [price set option labels](https://github.com/civicrm/civicrm-core/pull/24639), this will be much more easily accomplished.https://lab.civicrm.org/dev/wordpress/-/issues/133WPML URL Integration for CiviCRM2024-02-19T18:33:21ZshaneonabikeWPML URL Integration for CiviCRM## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or oth...## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or other page.
This isn't ideal and confusing for most users as they attempt to navigate to the translated CiviCRM page.
There is already integration for Polylang, but not integration presently for WPML.
WPML handles URLs in three different ways:
+ Attaching a language parameter to the end of the url ```lang=xyz```
+ Attaching a language in the path of the url ```https://test.dev/fr/civicrm/event/info/?reset=1&id=1```
+ Allowing for different domains for each language ```https://fr.test.dev/civicrm/event/info/?reset=1&id=1```
## Before
Viewing the page ```https://test.dev/civicrm/event/info/?reset=1&id=1```, and clicking on the WPML language link will take you to ```https://test.dev/civicrm/```
## After
The new code (I will attach the PR to this ticket shortly) will provide the proper integration for the defined scenarios above.
## Testing
I have tested this in the following scenarios, but maybe others want to test a bit larger?
+ Multiple domains while viewing (Events page)
+ Language placed in the URL (Events page)
+ Language within the proper path
+ Multisite installation with one site using WPML and CiviCRM Events
I don't believe that the path construction is any different for Contribution and other CiviCRM public pages, but I could be wrong.https://lab.civicrm.org/dev/core/-/issues/3948Oauth authentication against MS Exchange IMAP fails since basic authenticatio...2023-03-11T13:16:37ZspalmstromOauth authentication against MS Exchange IMAP fails since basic authentication blockedOverview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction ...Overview
----------------------------------------
----------------------------------------
Bounce processing using Oauth to authenticate against MS Exchange fails since Microsoft blocked basic authentication against IMAP.
Reproduction steps
----------------------------------------
1. Set up an Azure AD application to allow CiviCRM to check bounce processing against MS Exchange
1. Configure Oauth to use it.
1. Create a Mail account for bounce processing.
1. Save and Test fails.
Current behaviour
----------------------------------------
```
An error occured while sending or receiving mail. The IMAP server did not accept the username and/or password: A0001 NO LOGIN failed.. (See log for more details.)
```
Expected behaviour
----------------------------------------
Success.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _MS Edge_ but probably irrelevant.
* __CiviCRM:__ _5.54.0_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.4__ but probably irrelevant.
* __CMS:__ _Drupal 9.4.8_ but probably not relevant
* __Database:__ _MySQL 8.31_ but probably not relevant
* __Web Server:__ _IIS 10_ but probably not relevant.
Comments
----------------------------------------
Oauth scopes:
```
https://outlook.office.com/IMAP.AccessAsUser.All
https://outlook.office.com/POP.AccessAsUser.All
https://outlook.office.com/SMTP.Send
https://outlook.office.com/User.Read
```
Azure AD App permissions:
```
Microsoft Graph (12)
email Delegated
IMAP.AccessAsUser.All Delegated
Mail.Read Application
Mail.ReadBasi Application
Mail.ReadBasic.All Application
Mail.ReadWrite Application
Mail.Send Application
offline_access Delegated
openid Delegated
POP.AccessAsUser.All Delegated
SMTP.Send Delegated
User.Read Delegated
```
My suspicion is that the extension _never_ worked properly but instead the mail account was using basic authentication so it wasn't an issue. So, when basic authentication was disabled, the application stopped working. Has anyone else seen this issue?https://lab.civicrm.org/dev/core/-/issues/3947FormBuilder: Dropdown does not search exact participant role2022-10-27T16:12:37ZfastermannSGBFormBuilder: Dropdown does not search exact participant roleI built a form using SearchKit and FormBuilder (5.54.0) for a list of participants of an event. Columns are First Name, Last Name, Status, Role and some other.
We have several roles, one is "Mitarbeiter/in" (meaning staff). It has the ID...I built a form using SearchKit and FormBuilder (5.54.0) for a list of participants of an event. Columns are First Name, Last Name, Status, Role and some other.
We have several roles, one is "Mitarbeiter/in" (meaning staff). It has the ID 6. And one is "Ehrengast" (meaning honored guest) with the ID 16.
When I select "Mitarbeiter/in" from the drop down, the results present both - staff and honored guests.
The same problem occurs when I select a role with the ID 3 - it shows participants with ID 3 and 13. And when I select the role with ID 1, it shows also 11, 12, 13, 14 ...
It seems, searchkit is not searching for exact matches but for equals or something like that. Sounds strange, I know...
![Screenshot_2022-10-27](/uploads/1fa2a8661f3f566eac3972a9320fc73b/Screenshot_2022-10-27.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3946Improve default email greeting template2022-11-02T00:38:44ZeileenImprove default email greeting templateThe default greeting template that ships with Core is `Dear {contact.first_name}`
For contacts with no first name it looks like this
![image](/uploads/5484e666daa2e9eabb452b7dfb139704/image.png)
I propose changing it to `Dear {if '{...The default greeting template that ships with Core is `Dear {contact.first_name}`
For contacts with no first name it looks like this
![image](/uploads/5484e666daa2e9eabb452b7dfb139704/image.png)
I propose changing it to `Dear {if '{contact.first_name}'}{contact.first_name}{else}Supporter{/if}`
Which winds up like
![image](/uploads/35017aef6768ebc972b66b003e92bf0c/image.png)
Notes
- this is an English only change - but presumably non-English sites will see no change since there is either a customised version they are getting already or they are already getting the inappropriate 'Dear' & hence not using it
- the choice of word 'Supporter' - could be argued (Donor, Friend etc) - but I think if there is 'something' there then it will allow people to pick their own
- in workflow messages we currently use the field in this way
` {assign var="greeting" value="{contact.email_greeting_display}"}{if $greeting}<p>{$greeting},</p>{/if}` - would would result in the offensive 'Dear,'
- We already parse the greetings through Smarty so no change required there & because we use the `parseOneOffStringThroughSmarty` function smarty runs with higher security https://github.com/civicrm/civicrm-core/blob/95649f7c98ae3c384553f9958ebaf9caa03eb4a6/CRM/Core/Smarty.php#L183-L187
![image](/uploads/0d725992033a68ec25728e0e7e1e8814/image.png)
- The outstanding question is the impact on performance - which is what I will be testing next...https://lab.civicrm.org/dev/core/-/issues/3945SearchKit - make reordering columns easier2022-10-26T18:51:05ZsamuelsovSearchKit - make reordering columns easierIn SearchKit, more and more options are made available for fields. This is a good thing but it becomes more difficult to reorder the fields using drag & drop if the fields definition takes most of the screen :
(totally fake example but ...In SearchKit, more and more options are made available for fields. This is a good thing but it becomes more difficult to reorder the fields using drag & drop if the fields definition takes most of the screen :
(totally fake example but I have some real examples that takes a lot of space)
![Screenshot_2022-10-26_at_09-37-38_Contacts_CRM_de_la_Coop_SymbioTIC](/uploads/7a66a72c0fab195450bd0dd04940331c/Screenshot_2022-10-26_at_09-37-38_Contacts_CRM_de_la_Coop_SymbioTIC.png)
I can imagine 2 options to improve this :
1. have the content of the fields definition be a collapsible and add [collapse all] / [open all] buttons
1. make the ordering separate from the columns definitions, i.e. something like :
![Screenshot_2022-10-26_at_09-24-56_Contacts_CRM_de_la_Coop_SymbioTIC](/uploads/3d1a3692bd7cde1db996bea55fe80554/Screenshot_2022-10-26_at_09-24-56_Contacts_CRM_de_la_Coop_SymbioTIC.png)https://lab.civicrm.org/dev/core/-/issues/3943Searching for Current Member = No returns contacts who are current members if...2022-10-28T20:05:12ZlarsssandergreenSearching for Current Member = No returns contacts who are current members if they also have a non-current membershipIf you search in Advanced Search or Find Memberships with Current Member = No, you will get all contacts who have a membership which is not current. This is not the same as saying they aren't a current member, because the contact could h...If you search in Advanced Search or Find Memberships with Current Member = No, you will get all contacts who have a membership which is not current. This is not the same as saying they aren't a current member, because the contact could have another membership which is current. This is probably quite common as many contacts will buy a new membership instead of renewing their past membership.
In the case that a contact has, for example, one expired membership and one current membership, they will be found when searching for Current Member = No and also for Current Member = Yes. Confusing!https://lab.civicrm.org/dev/core/-/issues/3940Method and Tracking not set from API4 for Subscription History when creating ...2022-10-31T17:07:22ZlarsssandergreenMethod and Tracking not set from API4 for Subscription History when creating or updating GroupContactMethod and Tracking can be specified when creating or updating a GroupContact in API4 (with a default Method of API). However, these are always set as null for the Subscription History that is created.
I've been doing some debugging to ...Method and Tracking can be specified when creating or updating a GroupContact in API4 (with a default Method of API). However, these are always set as null for the Subscription History that is created.
I've been doing some debugging to follow these variables through the process and can see where this is going wrong, but am not clear on how this should actually work. The Subscription History is created by a [hook_post](https://github.com/civicrm/civicrm-core/blob/902fc38d0d6cd9d09ee02f30cc6621747151a06a/CRM/Contact/BAO/GroupContact.php#L39). The hook isn't even trying to set the Method and Tracking, nor does it have access to these variables (they are there when the GroupContact is created, but they aren't used for that).
I'm not clear on how these variables are supposed to get from the API call to the hook here. Happy to implement a fix, but not sure I understand how this is supposed to work or if we need to use an entirely different approach. I will also do the same with the delete action, which [I'm adding Subscription History to](https://github.com/civicrm/civicrm-core/pull/24804), so I'm looking for an approach which will also work for delete.https://lab.civicrm.org/dev/core/-/issues/3934Settings - Deprecate "serialize" flag2022-12-16T01:05:12ZtottenSettings - Deprecate "serialize" flag# Background: Basic settings
Settings are "key-value" pairs. The "value" part allows type `mixed` (*ie `string` or `int` or `float` or `array` or whatever*).
Support for `mixed` is consistent between `Civi::settings()` and `$civicrm_se...# Background: Basic settings
Settings are "key-value" pairs. The "value" part allows type `mixed` (*ie `string` or `int` or `float` or `array` or whatever*).
Support for `mixed` is consistent between `Civi::settings()` and `$civicrm_setting`.
```php
// Consistent access to a scalar
Civi::setting()->set('my_string', 'abc');
$civicrm_setting['domain']['my_string'] = 'abc';
assert Civi::setting()->get('my_string') === 'abc';
```
```php
// Consistent access to an array
Civi::setting()->set('my_array', [1,2,3]);
$civicrm_setting['domain']['my_array'] = [1,2,3];
assert Civi::setting()->get('my_string') === [1,2,3];
```
Under the hood, values are stored in MySQL using `serialize()`. You can see this in both recent and ancient code:
* 5.54's `setDb()`: https://github.com/civicrm/civicrm-core/blob/5.54/Civi/Core/SettingsBag.php#L413
* 5.54's `loadValues()`: https://github.com/civicrm/civicrm-core/blob/5.54/Civi/Core/SettingsBag.php#L137
* 4.3's `setItem()`: https://github.com/civicrm/civicrm-core/blob/4.3/CRM/Core/BAO/Setting.php#L325
* 4.3's `getItems()`: https://github.com/civicrm/civicrm-core/blob/4.3/CRM/Core/BAO/Setting.php#L216
# Background: `serialize` metadata
There is an additional option in `*.setting.php` metadata called `serialize`. Superficially, this resembles `serialize` metadata for DAO fields.
This option is defined for 8 settings: `contact_view_options`, `contact_edit_options`, `advanced_search_options`, `user_dashboard_options`, `address_options`, `contact_autocomplete_options`, `contact_reference_options`, and `quicksearch_options`.
In all cases, the setting has a serialization format of `SERIALIZE_SEPARATOR_BOOKEND`.
APIv4's `Setting` is a wrapper for `Civi::settings()`. Notably, it interprets the `serialize` metadata and applies an (additional/secondary) serialization.
# What's good about this?
It makes it easier for REST/AJAX agents to read and write those 8 historical settings (*the pre-existing settings with the annoying BOOKEND format*).
At the time of introduction, it probably had no effects on compatibility and required no upgrade steps.
# What's bad about this?
It encourages people to add unnecessary serialization layers. If you are writing a _new_ setting with structured data, then you'll see the `serialize` metadata and think: "I should add that!" Here are some docs that suggest `JSON` for a setting:
https://docs.civicrm.org/dev/en/latest/framework/setting/#settings-definition
But you shouldn't do that on a new setting! Here's why:
* __It adds complexity -- double-encoding.__ Every read and write of the data goes through both `serialize()` and some additional serialization method.
* __It adds complexity -- conflicted APIs.__ The setting can be viewed through various programmatic interfaces (e.g. local PHP array `$civicrm_setting`; local PHP method `Civi::setting()->get()`; e.g. remote REST method `Setting.get`). Some APIs present an `array` -- but others present an encoded string (like `^1^2^3^`). There is no decent reason why `$civicrm_setting`, `Civi::setting()`, and `Setting.get` should present it differently.
* __It distracts from the real data-modeling problem of serialized fields.__ We generally do simple settings (strings/ints) because they're easier. Complex settings (like `mailing_backend`) are possible, but we don't do them as much - because the tooling/validation/etc is not as good. Intuitively, complex settings could work better if we added more metadata. _But this is the wrong metadata._ Switching `mailing_backend` between `serialize`/JSON/CSV/YAML/etc doesn't make this any better. What you need is a sharper description of the data inside of that serialized blob.
* __It becomes overall harder to change.__ Perhaps settings should be stored with `json_encode()` instead of `serialize()`? `serialize()` has additional kinds of vulnerabilities. JSON has better support in MySQL. Plot out the path for how to migrate the entirety of `civicrm_setting.value` -- and compare that to switching serialization on a setting-by-setting basis. It's easier to change if individual settings are _not_ committed to specific serializers.
# What to do
Simplest thing:
* Keep the mechanism
* Present it as deprecatedhttps://lab.civicrm.org/dev/core/-/issues/3930Managed entity: creating custom fields with same label causes fatal error bec...2022-10-24T09:18:16ZherbdoolManaged entity: creating custom fields with same label causes fatal error because of db index.Overview
----------------------------------------
It seems a bit over the top to have fatal errors when custom field labels are not unique. This would (likely) only appear if someone had a managed entity for the custom field. Or if they...Overview
----------------------------------------
It seems a bit over the top to have fatal errors when custom field labels are not unique. This would (likely) only appear if someone had a managed entity for the custom field. Or if they were using the API directly.
Example use-case
----------------------------------------
1. Create a custom group. Add a custom field.
2. Go to API4, choose CustomField, create. Create a new custom field with the same label.
Current behaviour
----------------------------------------
> DB Error: already exists
Proposed behaviour
----------------------------------------
Remove the index from the database for the label. The custom field index on the name should be enough. The UI will still have validation to prevent duplicate labels, but that's necessary because there's no way to specify the label and name separately in the UI.https://lab.civicrm.org/dev/core/-/issues/3928Additional languages 'en_IN', 'en_SA', en_NZ, en_SG2022-10-20T07:16:47ZeileenAdditional languages 'en_IN', 'en_SA', en_NZ, en_SGCurrently in our database we have languages for
![image](/uploads/bdc8b1342d339599954b3c4f77ba00c3/image.png)
I think we should add additional variants for English where we know that English is the or an official language - as they ha...Currently in our database we have languages for
![image](/uploads/bdc8b1342d339599954b3c4f77ba00c3/image.png)
I think we should add additional variants for English where we know that English is the or an official language - as they have formatting associated with them - e.g both NZ & India use dd/mm/yyyy as the date format.
We could likely only do on new installs
I'm not imagining being incredibly thorough but these ones popped uphttps://lab.civicrm.org/dev/core/-/issues/3925CORS support for CiviCRM urls2022-10-25T11:55:21ZMichael McAndrewCORS support for CiviCRM urlsI wrote an extension that allows you to add CORS headers to CiviCRM responses: https://github.com/civicrm/civicrm-core/pull/24767.
All comments, ideas and feedback gratefully received, as always :slightly_smiling_face:.I wrote an extension that allows you to add CORS headers to CiviCRM responses: https://github.com/civicrm/civicrm-core/pull/24767.
All comments, ideas and feedback gratefully received, as always :slightly_smiling_face:.https://lab.civicrm.org/dev/core/-/issues/3924Afform linter has only been running on core-core2022-10-20T07:29:10ZtottenAfform linter has only been running on core-coreOverview
----------------------------------------
There is a linting test for Civi's Angular-HTML files (`tests/phpunit/Civi/Angular/PartialSyntaxTest.php`). However, the linting is not applied consistently, and several files are not in...Overview
----------------------------------------
There is a linting test for Civi's Angular-HTML files (`tests/phpunit/Civi/Angular/PartialSyntaxTest.php`). However, the linting is not applied consistently, and several files are not in compliance.
Having files which pass the linter ensures that:
* Modified/forked files can be easily compared to their originals.
* Files can be filtered/processed via `hook_alterAngular`.
Current behaviour
----------------------------------------
`PartialSyntaxTest` scans all available Angular modules at the time of test. In effect, it scans `civicrm-core:ang/**.html`.
When the test runs, `search_kit` and `afform` are not active, so not `civicrm-core:ext/search_kit/ang/**.html` and `civicrm-core:ext/afform/*/ang/**.html` are not scanned.
NOTE: This mechanism is built on top of PHP's `DOMDocument` (generally) and `phpQuery` (specifically). To test an HTML partial, we basically say:
```php
$doc = (new DOMDocument(...))->loadHTML($inputString);
$outputString = $doc->saveHTML();
assert $inputString === $outputString
```
So a document is considered good if it is stable/consistent across reads+writes.
Expected behaviour
----------------------------------------
All Angular HTML in `civicrm-core.git` should be scanned by a linter.
All files should pass.
Comments
----------------------------------------
There is a helper script `tools/scripts/check-angular.php` which can validate+reformat file. The script is not super-sophisticated -- but just to get a sense of it, one might call:
```
php tools/scripts/check-angular.php --colordiff $PWD/ext/search_kit/ang/crmSearchTasks/crmSearchTaskUpdate.html
```
In principal, we could run this on all the HTML files and simply commit the reformatted version. Then we might rework `PartialSyntaxTest` to plug the hole in the workflow.
But...
There's the issue of the actual changes in the formatting. It is important to note that PHP's `DOMDocument` has two formatting modes -- HTML and XML. The parser here has to use one or the other. These differ in several small ways -- eg some notations work the same in both, but some notations are rejected by one while accepted by the other. Going from memory (*based on testing yesterday*), here are some notable differences:
| Topic | Example | HTML Mode Support | XML Mode Support | Comment |
| -- | -- | -- | -- | -- |
| Standard tag, text | `<div>Hello</div>` | :white_check_mark: Read-write | :white_check_mark: Read-write | `div`, `span`, `p`, etc |
| Standard tag, empty-text | `<div></div>` | :white_check_mark: Read-write | :warning: Read-only<br/> (Prefer `<div/>`) | `div`, `span`, `p`, etc |
| Standard tag, self-closing | `<div/>` | :warning: Read-only<br/> (Prefer `<div></div>`) | :white_check_mark: Read-write | `div`, `span`, `p`, etc |
| Standard tag, self-closing, implicit | `<input>` | :white_check_mark: Read-write | :octagonal_sign: Error | `input`, `img`, `hr`, `br`, etc |
| Standard tag, self-closing, explicit | `<input/>` | :warning: Read-only<br/>(Prefer `<input>`) | :white_check_mark: Read-write | |
| Custom tag, text | `<custom>my text</custom>` | :white_check_mark: Read-write | :white_check_mark: Read-write | |
| Custom tag, empty-text | `<custom></custom>` | :white_check_mark: Read-write | :warning: Read-only<br/>(Prefer `<custom/>`) | |
| Custom tag, self-closing | `<custom/>` | :warning: Read-only<br/>(Prefer `<custom></custom>`) | :white_check_mark: Read-write | |
| Value-less attributes (custom or standard) | `<foo ng-list>` | :white_check_mark: Read-write | :octagonal_sign: Error | |
| Value for `disabled` | `<foo disabled="abcd">` | :octagonal_sign: Discard value | :white_check_mark: Read-write | |
(*I wanted to see this table because I had the nagging feeling that we were boxed in somehow -- and this does show that there are errors in either case. But these can be worked through...*)
I believe that running the auto-format (*at this moment*) would pose a few issues:
* For HTML mode (status-quo), it would discard the `disabled="..."` that appears in ~5 components. (*I suspect that this status-quo is actually a bug -- but only symptomatic when using `alterAngular`.*) We could update affected files. This may require changing some contracts.
* For XML mode, it would fail to parse `<input>`, `<foo ng-list>`, and similar. We could update these (`<input/>` and `<foo ng-list=",">`), though this would affect many more lines of code.
* In either mode, some files need to flip between `<foo></foo>` and `<foo/>`. Regex can control this a bit more tightly, though. We would need to choose which form we like.
There's also the possibility (out of left field) to replace the current parser or formatter or validator. But that feels like an even bigger rabbit hole.https://lab.civicrm.org/dev/core/-/issues/3921OptionValues & search kit - missing metadata?2022-11-11T03:26:35ZeileenOptionValues & search kit - missing metadata?We want to use search kit to create a UI to cleanup some of our languages. However, most of the fields are not available in the form-builder layer (where I would want to use them as filters).
I *think* they only show if they have `html...We want to use search kit to create a UI to cleanup some of our languages. However, most of the fields are not available in the form-builder layer (where I would want to use them as filters).
I *think* they only show if they have `html` defined in the xml - and that the right thing to do is to add `html` to `value`, `name` , `id`, `label` `is_active` and possibly others but to set most of them to `read-only` (which is a bit confusing but seems to deal with the two different use cases). Probably only `label` & `is_active` need to be editable
@colemanw