Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-07-13T05:03:25Zhttps://lab.civicrm.org/dev/core/-/issues/2405More operators for search kit2023-07-13T05:03:25ZeileenMore operators for search kitCurrently searchkit supports '=' or 'LIKE '%x' but in order to start to replace some of the dashlets created by CiviReport I think more flexibility is needed - for example if I want an afform to help me find donors with a total giving **...Currently searchkit supports '=' or 'LIKE '%x' but in order to start to replace some of the dashlets created by CiviReport I think more flexibility is needed - for example if I want an afform to help me find donors with a total giving **Greater Than** x. Another example is NOT IN - as currently on the activities dashlet
@colemanw has already added date search ranges ('this.week') etc to give some flexibility.https://lab.civicrm.org/dev/core/-/issues/347Buttons inconsistencies2023-07-12T11:52:57ZAkA84Buttons inconsistencies# Problem
While working on Shoreditch I spent some time doing an inventory of the different variations, in terms of markup, of a button in civi (it's not fully comprehensive, for example i left out the "disabled" versions) and it looks t...# Problem
While working on Shoreditch I spent some time doing an inventory of the different variations, in terms of markup, of a button in civi (it's not fully comprehensive, for example i left out the "disabled" versions) and it looks to me that there are several inconsistencies that civi would benefit from addressing or at least mitigating
![buttons](/uploads/c2b53a6da6be011b62195255395dfc5c/buttons.png)
_(source: https://gist.github.com/AkA84/9cfcfa610971461493dee1e63c0e06fb)_
## 1. Too many ways of doing the same thing
Right now there are several ways to add a standard civi button to a page, and all of them with caveats:
1. Use the `.button` class, but only if you apply it to a `<a>` or a `[type="button"]`
2. Use the `.crm-button` class, but it won't work correctly if you apply it to a `<a>`
3. Use the `.crm-form-submit` class, but only if you apply it to a `input[type="button"]` or a `input[type="submit"]`
4. Use the plain tag without classes, but only if it's `[type="button"]`, as either `<button>` or `[type="submit"]` will not be styled
Ideally there should be only one class that provides the desired state (say, `.crm-button`). Just like it works in Bootstrap (http://getbootstrap.com/docs/3.3/css/#buttons)
## 2. There are differences to the style in each variation
The differences are mostly about padding, which in turn cause the height to vary
1. `a.button` has a padding of `2px 6px`, resulting in a height of 23px
2. `span.button` has a padding of `1px`, resulting in a height of 20px
3. `button.crm-button` has a padding of `3px 6px` resulting in a height of 24px
4. `input[type="button"]` and `input[type="submit"]` have the same padding of `a.button`, but probably because of how they are rendered by the browser they end up with a different height, 19px
5. `.crm-button input[type=button]` has a padding of `3px 5px 2px`, resulting in a height of 22px
6. `.crm-button .crm-form-submit` has a padding of `1px 8px 2px 4px`, resulting in a height of 21px
It gets pretty evident once you line them up
![heights](/uploads/4901d492dca87220731572f8dfa45583/heights.png)
## 3. Some variations are floated by default
`a.button` and `span.crm-button` are floated by default to the left, which is pretty confusing. Not sure why this layout decision was hardcoded on these variations, but it prevents one to use them without having to "counter" the floating each time
# Solution
I think issue no.2 is the one with the better chances of being fixed without introducing regression issues, as it's just about consolidating the padding and height of all the variations
Issues no.1 and no.3 instead I can imagine that if fixed would likely cause problems downstream. At the very least some documentation of what should be the correct/preferred way to add a button in a civi page should mitigate the confusion and eventually lead to an adoption of a single variation as the "right" one over the others, which over time would become legacy and could eventually be removed
Shoreditch of course should be able to correct most if not all of the above by simply overriding the original css, but I thought worth flagging the problem anyway as it might be worth considering addressing the problems in the original "theme" as wellhttps://lab.civicrm.org/dev/core/-/issues/2483Passing an array activity_id to ActivityContact.create silently casts it to a...2023-07-12T05:03:23ZDaveDPassing an array activity_id to ActivityContact.create silently casts it to activity id 1What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicr...What happens is it silently updates activity id 1 with the new contact ids.
I think it would be better if it failed hard.
Where the cast is happening is in pear::DB because it's not expecting an array: https://github.com/civicrm/civicrm-packages/blob/c127df846491ee13b2a4dce5816f3da8b1d98d9a/DB/DataObject.php#L1224-L1231
It's the same in api3 and 4.https://lab.civicrm.org/dev/core/-/issues/23355.34 Upgrade fail when row format is not Dynamic2023-07-12T05:03:22Zeileen5.34 Upgrade fail when row format is not Dynamic [type] => DB_Error
[user_info] => ALTER TABLE `civicrm_action_schedule` ADD COLUMN `created_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'When was the schedule reminder created.' [nativecode=1118 ** Row size too large.... [type] => DB_Error
[user_info] => ALTER TABLE `civicrm_action_schedule` ADD COLUMN `created_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'When was the schedule reminder created.' [nativecode=1118 ** Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs]
NOTE THIS WORKS
ALTER TABLE `civicrm_action_schedule` ADD COLUMN `created_date` timestamp NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'When was the schedule reminder created.', ROW_FORMAT=DYNAMIC;https://lab.civicrm.org/dev/core/-/issues/3805Error on membership fee token when using Print/Merge Document2023-07-12T00:29:55ZgiammiError on membership fee token when using Print/Merge DocumentOverview
----------------------------------------
The issue has been reported on
https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-using-print-merge-document/42443#42443
Reproduction steps
------------...Overview
----------------------------------------
The issue has been reported on
https://civicrm.stackexchange.com/questions/42438/error-on-membership-fee-token-when-using-print-merge-document/42443#42443
Reproduction steps
----------------------------------------
I did a short test on the demo sandbox.
Selected "Find Membership" and selected one record. I then choose Print/Merge Document and added 2 tokens, {membership.id} and {membership.fee} Then clicked "Preview" to see the pdf outcome.
If I use only the token {membership.id} I do not get any error message and the preview is created.
Adding {membership.fee} I get the following error message below.
Current behaviour
----------------------------------------
```
The website encountered an unexpected error. Please try again later. TypeError: Return value of
CRM_Utils_Money::formatUSLocaleNumericRounded() must be of the type string, null returned in
CRM_Utils_Money::formatUSLocaleNumericRounded() (line 207 of /srv/buildkit/build/d9-master/vendor/civicrm/civicrm-
core/CRM/Utils/Money.php).
CRM_Utils_Money::formatUSLocaleNumericRounded() (Line: 249) CRM_Utils_Money::formatLocaleNumericRoundedByPrecision() (Line: 234)
CRM_Utils_Money::formatLocaleNumericRoundedByCurrency() (Line: 281)
CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency() (Line: 65) CRM_Member_Tokens->evaluateToken() (Line: 146)
Civi\Token\AbstractTokenSubscriber->evaluateTokens() (Line: 264) Symfony\Component\EventDispatcher\EventDispatcher->doDispatch()
(Line: 239) Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 73)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 209) Civi\Core\CiviEventDispatcher->dispatch() (Line: 354)
Civi\Token\TokenProcessor->evaluate() (Line: 64) CRM_Core_TokenSmarty::render() (Line: 349)
CRM_Core_BAO_MessageTemplate::renderTemplateRaw() (Line: 271) CRM_Core_BAO_MessageTemplate::renderTemplate() (Line: 131)
CRM_Member_Form_Task_PDFLetter->generateHTML() (Line: 98) CRM_Member_Form_Task_PDFLetter->postProcessMembers() (Line: 75)
CRM_Member_Form_Task_PDFLetter->postProcess() (Line: 573) CRM_Core_Form->mainProcess() (Line: 56)
CRM_Core_QuickForm_Action_Submit->perform() (Line: 203) HTML_QuickForm_Controller->handle() (Line: 103) HTML_QuickForm_Page-
>handle() (Line: 355) CRM_Core_Controller->run() (Line: 319) CRM_Core_Invoke::runItem() (Line: 69) CRM_Core_Invoke::_invoke()
(Line: 36) CRM_Core_Invoke::invoke() (Line: 88) Drupal\civicrm\Civicrm->invoke() (Line: 80)
Drupal\civicrm\Controller\CivicrmController->main() call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 80) Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 58)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48) Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85) Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51) Drupal\Core\StackMiddleware\NegotiationMiddleware-
>handle() (Line: 23) Stack\StackedHttpKernel->handle() (Line: 709) Drupal\Core\DrupalKernel->handle() (Line: 19)
```
Expected behaviour
----------------------------------------
No error message should appear and a PDF (and/or emailing) should be possible
Environment information
----------------------------------------
Demo Sandbox on CiviCRM Website5.63.0https://lab.civicrm.org/dev/core/-/issues/4227Contact import (new) deletes contact fields2023-07-11T16:34:41ZBjörn EndresContact import (new) deletes contact fieldsOverview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=...Overview
----------------------------------------
It seems like the "new importer" that has been implemented with [5.51](https://lab.civicrm.org/groups/dev/-/issues/?sort=updated_desc&state=closed&milestone_title=5.51.0&label_name%5B%5D=comp%3AImport&first_page_size=100) has slightly changed its behaviour: if you import/update contacts with empty fields these fields will be deleted, where they used to be ignored (pre 5.51).
Reproduction steps
----------------------------------------
1. Import test contact using the "Import Contacts" menu item with [this file](/uploads/5c56a58c83b7a1fcd5f69ddab02a5c23/ISSUE-4227_step1.csv) and check whether the contact was created.
2. Update the contact by using the import again with [this file](/uploads/62ef3aa3a3c6b975d2dbfa7d060248fc/ISSUE-4227_step2.csv), setting the "For Duplicate Contacts" setting to "Update"
3. Observe, that the birthday field in the new contact was deleted.
Current behaviour
----------------------------------------
Currently, the contact's birthday field is deleted.
Expected behaviour
----------------------------------------
Contact's birthday field should be left untouched, as was the behaviour pre ``5.51.0`` (tested with ``5.40.2``).
Environment information
----------------------------------------
Reproduced on ``dmaster``.
----------------------------------------
This might be an intentional change in behaviour, but I haven't found any documentation on this.5.62.0https://lab.civicrm.org/dev/core/-/issues/2086Editing an activity always logs a backtrace about duplicate key if you don't ...2023-07-11T05:03:30ZDaveDEditing an activity always logs a backtrace about duplicate key if you don't change the With Contacts@eileen One thing I'm seeing as a result of https://github.com/civicrm/civicrm-core/pull/18566 is that every time you edit an activity and save it it silently logs a backtrace for the PEAR error since the target contact always already ex...@eileen One thing I'm seeing as a result of https://github.com/civicrm/civicrm-core/pull/18566 is that every time you edit an activity and save it it silently logs a backtrace for the PEAR error since the target contact always already exists if you haven't changed it. I suppose edits are less common than new activities, so maybe it's still a net win, but logging a backtrace maybe is worse than an extra query.
To think about...
I haven't marked it regression since it's not a bug exactly.https://lab.civicrm.org/dev/core/-/issues/2440Contact Custom Fields not automatically populating upon creation2023-07-10T05:03:24ZswebervnaContact Custom Fields not automatically populating upon creationOverview
----------------------------------------
When the public accesses our donation page and donates, it'll automatically create a contact for them. And for all contacts, I have a set of custom fields with **default** values, but I'v...Overview
----------------------------------------
When the public accesses our donation page and donates, it'll automatically create a contact for them. And for all contacts, I have a set of custom fields with **default** values, but I've noticed that some (or most) new contacts don't have these fields automatically populated - to set them, you have to click on them and click **Save**. This is a problem for us because we frequently run reports, and without these fields populated they can miss our reports. It would be tedious to have to manually set and save these fields for each new contact.
Current behavior
----------------------------------------
1. New contact custom fields:
![image](/uploads/3ccf2c3b29aa841750af4bfc414ea5fc/image.png)
2. When you click on the custom fields:
![image](/uploads/de3c243fe46a1140b37c9d481ed0bb7b/image.png)
3. When you click **Save**:
![image](/uploads/de81d753ebd639a925d2bbedb1400b33/image.png)
(Fields are set as they should be done automatically)
```
Expected behavior
----------------------------------------
Upon a new contact created, CiviCRM should automatically populate these custom fields with their default values, so they can accurately show up on Reports.
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 necessary. -->
* __Browser:__ _Chrome 88.0.4324.190_
* __CiviCRM:__ _5.33.2_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _(Unknown)__
* __CMS:__ _Drupal 7.?_
* __Database:__ _(Unknown)_
* __Web Server:__ _(Unknown)_https://lab.civicrm.org/dev/core/-/issues/2457Notice: A non well formed numeric value encountered when choosing "other amou...2023-07-09T19:01:32ZDaveDNotice: A non well formed numeric value encountered when choosing "other amount" on contribution page using non-US settings`Notice: A non well formed numeric value encountered in CRM_Price_BAO_LineItem::format() (line 317 of .../web/sites/all/modules/civicrm/CRM/Price/BAO/LineItem.php).`
Haven't looked further yet. Set the settings to non-US money formats a...`Notice: A non well formed numeric value encountered in CRM_Price_BAO_LineItem::format() (line 317 of .../web/sites/all/modules/civicrm/CRM/Price/BAO/LineItem.php).`
Haven't looked further yet. Set the settings to non-US money formats and then visit a contribution page and choose other amount and fill it in, e.g. `12,34`, then on the next page you get the notice. Everything still works though.https://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/2454Access Control by Financial Type permissioning does not cover contribution_recur2023-07-08T05:03:19ZandyburnsAccess Control by Financial Type permissioning does not cover contribution_recurWhen having _Access Control by Financial Type_ turned on a user without the permission over a given financial type can still access it in 3 ways:
- Can view corresponding recurring contribution (under recurring contributions tab)
- Can ...When having _Access Control by Financial Type_ turned on a user without the permission over a given financial type can still access it in 3 ways:
- Can view corresponding recurring contribution (under recurring contributions tab)
- Can cancel it
- Can view all contributions related to the recurring. So it is a backdoor around the permissioning.
I've checked the financial type in civicrm_contribution_recur and it is one they should not see.
![cancel-recurring](/uploads/f514ebffe682dfa823c54512a9a5b505/cancel-recurring.png)
![recurring-contritbutions-log](/uploads/a28ecf0d139ff3c11c1b3aad320576f3/recurring-contritbutions-log.png)
WP 5.6.2 Civi 5.31.1https://lab.civicrm.org/dev/core/-/issues/2447Wrong event fee shown in CiviCRM2023-07-07T05:03:20ZjaapjansmaWrong event fee shown in CiviCRM**Steps to reproduce**
1. Set the localization settings to **decimal separator**: `,` and **thousand separator**: `.`
2. Create a price set with two quantity fields and a drop down.
3. Create an event with only registration and payments...**Steps to reproduce**
1. Set the localization settings to **decimal separator**: `,` and **thousand separator**: `.`
2. Create a price set with two quantity fields and a drop down.
3. Create an event with only registration and payments and select the created price set above
4. Do a registration and a payment. All amounts are correct on the registration screen
5. After you have done a registration check the participant list or the event tab on the contact card. And/or click on view participant. The total amount for the event fee is displayed wrong.
**Screenshot**
Below a screenshot which shows the wrong amount.
![Screenshot_20210309_114606](/uploads/c3150fda8f90aacccfc26b9c50584e92/Screenshot_20210309_114606.png)
**Remarks**
This also happens when you do an event registration from the contact record in CiviCRM.
**Environment**
Drupal 7
CiviCRM 5.37.aplha1 (dmaster)https://lab.civicrm.org/dev/core/-/issues/2456Explore use of JWTs for authentication2023-07-07T05:03:19ZcolemanwExplore use of JWTs for authentication(*Migrated from a totten comment on another thread about simulating permissions in afform and searchkit*)
## JSON Web Tokens: Microsoft example
(*This example demonstrates the data-flow. Many symbols/URLs are edited to improve readabil...(*Migrated from a totten comment on another thread about simulating permissions in afform and searchkit*)
## JSON Web Tokens: Microsoft example
(*This example demonstrates the data-flow. Many symbols/URLs are edited to improve readability/intuition.*)
A "JSON Web Token" (JWT) is a building-block for an access-control system. (Analogy: JSON serves a purpose like XML... but JSON is easier to encode/decode/remix/improvise. Similarly, JWT serves a purpose like ASN.1/X.509... but JWT is easier to encode/decode/remix/improvise.)
Microsoft uses JWT for their web-service APIs - and also for email APIs, like MS Exchange Online. When Civi talks to MS Exchange Online, it uses JWTs. In this process, a user "Alice" (`alice@example.com`) starts out in Civi web UI. We redirect her to `https://login.microsoftonline.com`, where she clicks a button to say "Yes, trust CiviCRM", and (long-story-short) MS sends us an access token.
This access token looks like a long, random password (`aSdF12.34QwErTy.DvORak`), and we can use it to make REST calls. For example, we might request a copy of Alice's user profile:
```
GET https://api.microsoft.com/about-me HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
```
```
HTTP/1.1 200 OK
Content-type: application/json
{"email": "alice@example.com", "first_name": "Alice", "last_name": "Alison", ...}
```
Again, it looks like a password, so one can plug it into many different systems. We can use it to connect to IMAP or SMTP servers.
But it's not really a password. It is encoded JSON. If you clean it up, then it looks like this:
```js
{
"issuer": "login.microsoftonline.com",
"user": "alice@example.com",
"scopes": ["imap", "smtp", "profile"],
"expires": "2021-04-08 12:16:20"
}
```
This says that `login.microsoftonline.com` (the master security service at Microsoft) is vouching for us. We're approved to access a few services (`"scopes":["imap", "smtp", "profile"]`) on behalf of a particular person (`"user": "alice@example.com"`). When we connect to `api.microsoft.com` or IMAP or SMTP, the server parses the JWT, validates the signature cryptographically, and then gives us access.
The fields (`user`, `scopes`, etc) determine access control. If we try to access any other API -- editing Alice's address book, deleting Word docs, generating maps, etc -- then it will reject us. That's because our `"scopes"` do not include `address_book`, `manage_docs`, or `mapping`.
The token format doesn't *have* to be based on JSON or JWT. Civi's email hashes are a fine example of a token that doesn't use JSON. However, JSON is flexible and easy to parse. If you're designing a protocol, you have a lot of latitude to pick and choose which fields to include. Additionally, because it's standard, it's easier to inspect/debug. (Got a failed request? Decode the JWT and see if anything looks wrong.)
## JSON Web Tokens: Why
Why would someone like Microsoft adopt an access-token pattern like JWT?
Because they are actually running many distributed apps - and, when you get to a certain scale (#apps/#devs/#users), it gets hard to think straight (or run performantly) if they are linked-up one-by-one using a shared session.
Ordinarily, one would expect the demands on a self-hosted PHP app to be gentle enough to address with a straight-forward session/global variable (`$session->get('userID')`; `global $user`). There's a lot of mileage there. However, with the complexity of supporting multiple CMSs with different routing/session/identity mechanisms -- and with the goal of doing targeted permission escalations/changes/bypasses -- I'm not so sure. Civi is not positioned to be as simple as a singular PHP app - maybe it's more like a distributed app (where access+identity messages are coordinated among many different components - Drupal, Joomla, WordPress, Civi QF, Civi APIs, etc)
## Browser (JS) apps and alternative permissions
OK, so how would you use JWT to accomplish alternate permissions in a Civi/JS/Angular/API app?
Recall that the page-load goes a bit like this:
```
GET https://example.org/civicrm/search HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/SavedSearch/get?name=foobar HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/Contact/get?complexCriteria=... HTTP/1.1
Cookie: SESS=abcd1234
```
In each request, the permissions are determined by the cookie. But you don't want those permissions. So... don't use the cookie. Use something with different permissions - like a JWT.
```
GET https://example.org/civicrm/search HTTP/1.1
Cookie: SESS=abcd1234
GET https://example.org/civicrm/ajax/api4/SavedSearch/get?name=foobar HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
GET https://example.org/civicrm/ajax/api4/Contact/get?complexCriteria=... HTTP/1.1
Authorization: Bearer aSdF12.34QwErTy.DvORak
```
During the initial page-view, you have to construct and output the token. This is where you decide what kind of actions will be permitted. Maybe it looks like:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 3600,
'scopes' => ['api4/SavedSearch/get', 'api4/Contact/get'],
]);
Civi::resources()->addSetting('apiAuthToken', $token);
```
or maybe:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 1800,
'scopes' => ['SavedSearch:foobar'],
]);
Civi::resources()->addSetting('apiAuthToken', $token);
```
or:
```php
$token = Civi::service('crypto.jwt')->encode([
'exp' => time() + 3600,
'contactId' => 1234,
'savedSearch' => 'foobar',
'perms' => ['access AJAX API']
Civi::resources()->addSetting('apiAuthToken', $token);
```
This is a very generic/flexible way to think about changing permissions while supporting AJAX apps.https://lab.civicrm.org/dev/core/-/issues/4300FormBuilder: Client-side email validation doesn't work2023-07-07T03:55:58ZkcristianoFormBuilder: Client-side email validation doesn't workThis is a follow up issue to https://lab.civicrm.org/dev/core/-/issues/4173 and relayed to https://lab.civicrm.org/dev/core/-/issues/4174#note_90537
Steps to Reproduce:
- Build WP site with latest CiviCRM - Cureently using WP 6.2.1 and...This is a follow up issue to https://lab.civicrm.org/dev/core/-/issues/4173 and relayed to https://lab.civicrm.org/dev/core/-/issues/4174#note_90537
Steps to Reproduce:
- Build WP site with latest CiviCRM - Cureently using WP 6.2.1 and CiviCRM 5.61.2
- Create a submission form with the following Fields - all required
- First Name
- Last Name
- Email
- Phone
Compete the form, but for email use `meatme` as the email address.
- expected behavior - fails validation
- Actual behavior form submits
Email validation not working client side or server side. I have confirmed this on WP and Drupal 7.
~~Possibly related - on phone or address - add a second item (second phone in my testing). Do not choose a location type. Form submits, but the record does not update CiviCRM. This behavior only exists on WP, I cannot reproduce on Drupal. I can break this out as another issue if needed. But adding here as I see this as validation failing.~~
EDIT: The location issue is fixed in WP with the master branch.
ping @eileen @colemanw @shaneonabike @JonGold As we all commented on original issue notifying and asking for feedback and comments on a possible way to fix.https://lab.civicrm.org/dev/core/-/issues/2455league/csv package a bit of a booby trap in waiting2023-07-06T05:03:19Zeileenleague/csv package a bit of a booby trap in waitingWe currently have v9.3 of csv/league on our wmf code and 9.2 in our civi code and have no issues - however we recently tried 9.6 in our CI and found it crashes when co-existing with 9.2 which civi has - due to this removal
https://githu...We currently have v9.3 of csv/league on our wmf code and 9.2 in our civi code and have no issues - however we recently tried 9.6 in our CI and found it crashes when co-existing with 9.2 which civi has - due to this removal
https://github.com/thephpleague/csv/commit/bbfb63b6c4df045353f095f842942038a529f69a#diff-fe65dcdace9cc44252b537bee79dd574edd1bccf6cee646cc860006a6ec50e8bL119
Although we have no specific reason to update to 9.6 at this stage we can assume that some WP sites might in the nearish future and I think we could mitigate the iminent pain by upgrading civi to a patched version of 9.6 that puts that function back & hence gets us past the transitional wobbles (we can unpatch later on)https://lab.civicrm.org/dev/core/-/issues/2441Print Report from Manage Case for closed cases doesn't show roles properly2023-07-06T05:03:18ZDaveDPrint Report from Manage Case for closed cases doesn't show roles properlyIt's not identical to https://lab.civicrm.org/dev/core/-/issues/1948 but might be the same underlying reason.
1. Create a case.
2. Add some roles.
3. Close the Case.
4. Choose Print Report on Manage Case.
5. Look at the roles near the t...It's not identical to https://lab.civicrm.org/dev/core/-/issues/1948 but might be the same underlying reason.
1. Create a case.
2. Add some roles.
3. Close the Case.
4. Choose Print Report on Manage Case.
5. Look at the roles near the top - they should be there.
Ditto for the Activity Audit which is the same codebase as Print Report.https://lab.civicrm.org/dev/drupal/-/issues/186drupal 9: Create User Record action crashes if using first+last+email as unsu...2023-07-05T23:49:05ZDaveDdrupal 9: Create User Record action crashes if using first+last+email as unsupervised ruleSee https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.See https://civicrm.stackexchange.com/questions/44841/create-user-record-action-on-a-contact-summary-page-throws-error-is-this-a-bug
Putting as regression for now but not completely sure.
Doesn't happen in drupal 7.5.63.0https://lab.civicrm.org/dev/core/-/issues/4317Import contribution fails with custom fields2023-07-05T23:48:39ZPhilipp MichaelImport contribution fails with custom fieldsOverview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Cl...Overview
----------------------------------------
When importing contributions with field mappings to a custom field, the process fails after continuing from step 2 of 3.
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Import Contributions**.
1. Choose mandotory options and continue to step 2.
1. In "Matching CiviCRM Field" choose at least one custom field and try to continue to step 3
1. Got an error "**TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned**".
Current behavior
----------------------------------------
Regardless of the provided CSV data, the process fails with:
```
TypeError: CRM_Import_Parser::getFieldMetadata(): Return value must be of type array, null returned in CRM_Import_Parser->getFieldMetadata() (line 1768 of /var/www/html/vendor/civicrm/civicrm-core/CRM/Import/Parser.php).
CRM_Import_Parser->getFieldMetadata('Zu_belastendes_Konto.nur_anstehende_Zuwendungen._IBAN') (Line: 165)
CRM_Contribute_Import_Parser_Contribution->getMappedRow(Array) (Line: 221)
CRM_Contribute_Import_Parser_Contribution->validateValues(Array) (Line: 2551)
CRM_Import_Parser->validateRow(Array) (Line: 1842)
CRM_Import_Parser->validate() (Line: 90)
CRM_Import_Form_MapField->postProcess() (Line: 612)
CRM_Core_Form->mainProcess() (Line: 144)
CRM_Core_StateMachine->perform(Object, 'next', 'Next') (Line: 43)
CRM_Core_QuickForm_Action_Next->perform(Object, 'next') (Line: 203)
HTML_QuickForm_Controller->handle(Object, 'next') (Line: 103)
HTML_QuickForm_Page->handle('next') (Line: 355)
CRM_Core_Controller->run(Array, NULL) (Line: 319)
CRM_Core_Invoke::runItem(Array) (Line: 69)
CRM_Core_Invoke::_invoke(Array) (Line: 36)
CRM_Core_Invoke::invoke(Array) (Line: 88)
Drupal\civicrm\Civicrm->invoke(Array) (Line: 83)
Drupal\civicrm\Controller\CivicrmController->main(Array, '')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
```
Environment information
----------------------------------------
* __CiviCRM:__ _Master/5.60/5.62/5.64_
* __PHP:__ _8.0_
* __CMS:__ _Drupal 9.5.9_
* __Database:__ _MariaDB 10.4.28_
Comments
----------------------------------------
I've tested latest versions and can reproduce it in 5.60 and later. It was probably caused with changes in [Update Contribution Import to use apiv4 field names, prior to adding hooks](https://github.com/civicrm/civicrm-core/pull/25886). The way of getting custom fields available for import has changed, which leads to different field keys respectively option values. Previously you got the short version "custom_xy", now you get a long database field name like one.
5.59:
![mapping-custom-fields-options-5.59](/uploads/e4f4adc83357fd0c3e7613b6f92d5bb2/mapping-custom-fields-options-5.59.png)
5.60 (and 5.62, 5.64):
![mapping-custom-fields-options-5.62](/uploads/d0f7573c8f279bc53c794949d3183ea9/mapping-custom-fields-options-5.62.png)
The import parser can't find related field meta data regarding to those keys.
I'm not sure, if those key names provided by the API are intended and therefor can't provide a PR.5.63.0https://lab.civicrm.org/dev/core/-/issues/4258Show next scheduled contribution date for recurring contributions on contact2023-07-05T23:48:38ZlarsssandergreenShow next scheduled contribution date for recurring contributions on contactCurrently, the active recurring contribution start date is shown, but the next scheduled contribution date would be much more useful (I often find myself looking for the next contribution date, especially when there is a credit card issu...Currently, the active recurring contribution start date is shown, but the next scheduled contribution date would be much more useful (I often find myself looking for the next contribution date, especially when there is a credit card issue, but rarely need to know the start date for the series).
For inactive recurring contributions, it would be much more useful to know the cancellation date than the start date.
For reference, the current situation:
![image](/uploads/a955ce997cc6063eab4dee4852a0d282/image.png)
Will submit PR if supported.https://lab.civicrm.org/dev/core/-/issues/4260CiviEvent: Submit button has wrong label in online registrations with multipl...2023-07-05T23:48:38ZAndreasandreas.howiller@civiservice.deCiviEvent: Submit button has wrong label in online registrations with multiple participants (on free events without confirmation screen)Overview
----------------------------------------
On a registration page for an event that allows multiple attendees, the submit button is labelled "Review" instead of "Register" though confirmation screen is disabled and event has no f...Overview
----------------------------------------
On a registration page for an event that allows multiple attendees, the submit button is labelled "Review" instead of "Register" though confirmation screen is disabled and event has no fees:
![grafik](/uploads/212957e4dfcbd9d321ff468009e9fce7/grafik.png)
Reproduction steps
----------------------------------------
1. Create a event free of charge with online registration
1. Enable checkbox "Register multiple participants?"
1. Try out registration page
Current behaviour
----------------------------------------
1. Button is labelled "Review" when option for multiple participants is enabled and drop down option is "1".
2. For dropdown "2" the label is "Continue" in the first step of the form. The last step then shows "Continue" again.
Expected behaviour
----------------------------------------
The "final submission button" should here always have the label "register" as it is the case when disabling "Register multiple participants".
Environment information
----------------------------------------
Reproduced on:
* __CiviCRM:__ _5.61.alpha1/5.60.0/5.58.1_
* __PHP:__ _8.1/7.4_