CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-27T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/2544Move Contact Layout Editor to a core extension2023-07-27T05:03:20ZcolemanwMove Contact Layout Editor to a core extensionAt some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core...At some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core tarball (via distmaker import), or the `ext/` directory of the core repo.
Today might not be the day for that, but logging some notes on it anyway:
- Today, the only benefit of moving the extension into core is it would be more visible to end-users.
However, in the future, benefits might include:
- Easier simultaneous development of extension & core with no version conflicts.
- Possible to enable the extension by default.
- Possible to rip out redundant functionality from core.
Challenges
- There isn't an easy upgrade path when an extension is moved into core; you end up with 2 copies of the extension
- Currently, the extension scanner does not give the core `ext/` directory top priority, which means older versions of the extension outside core would take precedence.
Considerations
- As handy as it is, Contact Layout Editor still uses smarty to render the page.
- Maybe the end-game is to make that page an Afform instead. However, that day is a long way off given Afform's current capabilities.https://lab.civicrm.org/dev/core/-/issues/2540Print report permissions2022-06-02T18:01:45ZDevAppPrint report permissionshttps://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions...https://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions on a report appear, but do not function.
The user is just redirected back to the same report.
The functionality appears broken, as the report gives the option to print but it does not work without the additional permission.
Possible solutions:
- Give permissions to print if access report permissions are already granted and the user can view a report
- Add a new print permission and only show the print option if enabled for user
- Hide existing print options if view report criteria not selected, as the user can't print5.51.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2522Afform - Add submit actions2022-04-01T00:40:25ZcolemanwAfform - Add submit actionsOther form-builder libraries typically have some options for post-submit, e.g.
1. Display a popup message to the user (maybe with token replacement).
2. Display a full-screen message (replacing the body of the form).
3. Redirect to anot...Other form-builder libraries typically have some options for post-submit, e.g.
1. Display a popup message to the user (maybe with token replacement).
2. Display a full-screen message (replacing the body of the form).
3. Redirect to another form/page.
All of those would be nice-to-have options. `#3` feels like the most critical (and also the easiest to code).colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/2508Improve unit tests by checking if session::setStatus sets errors2023-07-20T05:03:20ZDaveDImprove unit tests by checking if session::setStatus sets errorsThe alert popups that come up in civi happen two ways: One is via javascript-only, which is difficult to test in the regular phpunit tests, and the other is via CRM_Core_Session::setStatus().
One approach is as in https://github.com/civ...The alert popups that come up in civi happen two ways: One is via javascript-only, which is difficult to test in the regular phpunit tests, and the other is via CRM_Core_Session::setStatus().
One approach is as in https://github.com/civicrm/civicrm-core/pull/19939 but it's not workable in practice because it generates too much extra visual noise on screen. However it pointed out some tests which could be improved. See also https://github.com/civicrm/civicrm-core/pull/19939#issuecomment-809683859 for some additional details. The last one here about financialtype I think I saw a variation of on-screen once and was just that the type of popup was wrong (i.e. using error instead of success).
```
not ok 599 - Error: CRM_Contact_Form_Task_EmailCommonTest::testPostProcessWithSignature
not ok 603 - Error: CRM_Contact_Form_Task_UseraddTest::testUserCreateFail
not ok 653 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentEmptyContact
not ok 654 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentContributionsWithInvoicingEnabled
not ok 655 - Error: CRM_Contact_Page_View_UserDashBoardTest::testDashboardContentContributions
not ok 698 - Failure: CRM_Contribute_BAO_ContributionRecurTest::testAutoRenewalWhenOneMemberIsDeceased
not ok 944 - Error: CRM_Core_BAO_AddressTest::testSharedAddressChaining3
not ok 1115 - Error: CRM_Core_BAO_SettingTest::testGetItemGroup_Override
not ok 1116 - Error: CRM_Core_BAO_SettingTest::testDefaults
not ok 1117 - Error: CRM_Core_BAO_SettingTest::testOnChange
not ok 1118 - Error: CRM_Core_BAO_SettingTest::testSetCivicrmEnvironment
not ok 1119 - Error: CRM_Core_BAO_SettingTest::testPseudoConstants
not ok 507 - Error: api_v3_ContactTest::testMergedGetWithPermanentlyDeletedContact
not ok 1382 - Failure: api_v3_JobTest::testProcessMembershipDeceased
not ok 1418 - Failure: api_v3_LoggingTest::testEnableDisableLogging
not ok 1522 - Failure: api_v3_MembershipStatusTest::testDeceasedMembershipInline
not ok 280 - Error: Civi\Test\ExampleHookTest::testPageOutput
fatal error - ext/oauth-client/tests/phpunit/CRM/OAuth/MailSetupTest.php:18
not ok 2 - Failure: Civi\Financialacls\FinancialTypeTest::testChangeFinancialTypeName
```https://lab.civicrm.org/dev/core/-/issues/2505CiviReport does not localize custom fields of type Number2023-02-16T13:30:23ZjaapjansmaCiviReport does not localize custom fields of type Number**How to reproduce**
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Add a custom group for cases
3. Add a custom field of **Type** `Number` and **Field type** `Text`
4. Enter a value such...**How to reproduce**
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Add a custom group for cases
3. Add a custom field of **Type** `Number` and **Field type** `Text`
4. Enter a value such as `1,234.56` which is localized `1.234,56`
5. Create a new CiviCase detail report. Check the column to display the custom field.
**Expected result**
Value of the custom field displayed as `1.234,56`
**Actual result**
Value of custom field is displayed as `1234.56` (note the decimal separator and the missing thousand separator).
**Comment**
The display value of custom number fields is also broken on the manage case screen.
We have a function `CRM_Utils_Money::formatLocaleNumericRoundedForDefaultCurrency` to format money fields. However we do not have such a function for number fields with a decimal. So basically nowhere in CiviCRM a number field is formatted according to localization settings. Unless the smarty modifier `|crmNumberFormat` is used in the template.
A fix should probably happen in `CRM_Core_BAO_CustomField::formatDisplayValue`, see https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomField.php#L1187
However I am not exactly sure how to fix this as I could not find a number formatting function such as we have for the money field. Does such a function exists and if so where do I find it?5.38.0https://lab.civicrm.org/dev/core/-/issues/2504CiviReport does not localize custom date fields when exporting to CSV2021-04-09T13:32:59ZjaapjansmaCiviReport does not localize custom date fields when exporting to CSVCiviReport does not localize custom fields of type Date
**How to reproduce**
1. Set localization settings: **Date Format Complete date** to `%d-%m-%Y`
2. Add a custom group for cases
3. Add a custom field of Type Date and no time.
4. E...CiviReport does not localize custom fields of type Date
**How to reproduce**
1. Set localization settings: **Date Format Complete date** to `%d-%m-%Y`
2. Add a custom group for cases
3. Add a custom field of Type Date and no time.
4. Enter a value such as 31-04-2021 (1st of april 2021)
5. Create a new CiviCase detail report. Check the column to display the custom field.
6. Export the report to CSV
**Expected result**
Value of the custom field displayed as `01-04-2021` as it is shown in the report and according to the localization setting.
**Actual result**
Value of custom field is displayed as `2021-04-01` which is ISO format.
**Comment**
The format for iso format is hard coded in: https://github.com/civicrm/civicrm-core/blob/master/CRM/Report/Utils/Report.php#L270
I am not sure if that is the desired behavior. I dont think so as the custom fields of type money are localized into a CSV export. So I would argue that the date should also be formatted according to the localization settings.https://lab.civicrm.org/dev/core/-/issues/2500Run localised unit tests2023-07-18T05:03:23ZBjörn EndresRun localised unit testsOverview
----------------------------------------
Tickets like #2164 highlight again that we have a test gap for localised environments.
Example use-case
----------------------------------------
See #2164
Current behaviour
------------...Overview
----------------------------------------
Tickets like #2164 highlight again that we have a test gap for localised environments.
Example use-case
----------------------------------------
See #2164
Current behaviour
----------------------------------------
Currenlty, afaik, the unit tests are only run in the the native language (en_US).
Proposed behaviour
----------------------------------------
If there is an automated/easy way to do so, we should run the unit test suite in selected (or all?) localisations. Maybe not all the time (as in the PR hooks), but e.g. before a release.
Comments
----------------------------------------
I'm sure somebody has already looked into that, and I'd like to know what the main obstacles were.https://lab.civicrm.org/dev/core/-/issues/2499UI for the "Logging" setting is confusing/incorrect on multisite/multi-domain...2023-11-28T05:03:26Zmartin.wUI for the "Logging" setting is confusing/incorrect on multisite/multi-domain installationOverview
----------------------------------------
The UI for the "Logging" setting (i.e. detailed logging) on the **Administer -> System Settings -> Misc** page is confusing, misleading, and indeed incorrect for a multisite installation....Overview
----------------------------------------
The UI for the "Logging" setting (i.e. detailed logging) on the **Administer -> System Settings -> Misc** page is confusing, misleading, and indeed incorrect for a multisite installation. This is because when you first turn logging on ("Yes") for one site, it actually enables logging for all sites (all Civi domain IDs), not just for the current site. However, if you navigate to the **Administer -> System Settings -> Misc** on a different site, the Logging setting will still indicate logging is off ("No"). The UI on the other sites do not correctly show the logging status.
The opposite is also true. If the logging setting is "Yes" on multiple sites, as soon as you turn it off ("No") for one site, it is actually turned off for all sites. But the Misc settings page on other sites continues to show that logging is turned on.
The preferred behavior would be ensure the status of logging is always shown correctly on all sites. As soon as you set it to "Yes" or "No" on one site, navigating to the "Misc" settings page on any other site should show the same status.
Use-case 1
----------------------------------------
1. Create a multisite/multi-domain installation with at least two sites (Site A and Site B).
1. On Site A, navigate to **Administer -> System Settings -> Misc**, change **Logging** to **Yes** and **Save** changes.
1. On Site B, navigate to **Administer -> System Settings -> Misc**. Observe that the **Logging** setting __incorrectly shows__ **No**.
Use-case 2
----------------------------------------
If a new site (domain ID) is added to a multisite installation for which logging is already turned on, will the **System Settings -> Misc** page on the new site correctly show **Logging** is set to **Yes**?
Current behavior
----------------------------------------
See use case #1 above.
Proposed behavior
----------------------------------------
As above, but in use case #1 step (3), Site B correctly shows **Logging** is **Yes**.
In addition, the _"If enabled, all actions will be logged with a complete record of changes."_ help text could be changed to something like: _"If enabled, all actions will be logged with a complete record of changes. (In a multisite installation, this setting applies to all sites.)"_
In addition of course the [Sys Admin guide](https://docs.civicrm.org/sysadmin/en/latest/setup/logging/) should explain the logging behavior for multisite.
Comments
----------------------------------------
I notice that in the civicrm_setting table, the `is_domain` field for the `name = "logging"` record is "1" (meaning, presumably, that "logging" is a domain-specific setting). But in fact it is a system-wide setting, right? Would simply changing `is_domain` to `0` cause the UI to behave correctly?
Or a simpler/faster fix would be to change the code so that all of the `name = "logging"` records are updated to the same value whenever the setting is changed in the UI anywhere. (But, if a new site is added, would the "logging" setting be initialized to the correct current value?)
A third option would be to only display the Logging setting on the primary domain's Misc settings page.https://lab.civicrm.org/dev/core/-/issues/2496Api support for afform contribution pages2023-07-17T05:03:23ZeileenApi support for afform contribution pagesAfform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_pro...Afform what do we need to do to offer Contribution form
Contribution entity - but just basic fields
Payment block
To do the latter we need an api like
PaymentForm with the actions
```
->submit
->getfields
->validate
```
```payment_processor_id ``` would be required for each of these (getfields would reply with metadata that would indicate what additional fields are required)
That should be the minimum for a totally basic processor (like paypal std, paypalpro, dummy, payment express, Mollie, Sagepay recurring in Omnipay, some IATS)
All the complexity comes in when we start adding in the js - e.g Stripe, Paypal checkout, some IATS. I think it makes much more sense to get the easy ones working first - but once they are then for phase 2 we will need at minimum
- An api function to get the JS to add with some details about it
- A js object on the pay to return the total_amount from the form - this is something Matt has been working on & would need to be thought through across forms - eg. CRM.PaymentForm.getAmount() should do the same on the angular form and on the core civicrm forms. We probably need to articulate what other functions it may or may not need
On submission we would do
```
Order.create (this can just be the same params as Contribution.create in the initial submit. At minimum it is basically contribution.create with a forced ‘Pending’ status
PaymentProcessor.pay
Payment.create
```
These exist in apiv3 & I think we would use them for nowhttps://lab.civicrm.org/dev/core/-/issues/2495Proposal - populate all requested smart groups at once2023-07-17T05:03:24ZeileenProposal - populate all requested smart groups at onceThis is tied to https://lab.civicrm.org/dev/core/-/issues/2480 but I wanted to split it off as it is related specifically to the existing load() mechanism and where I think we could tweak existing code slightly to make a function that wo...This is tied to https://lab.civicrm.org/dev/core/-/issues/2480 but I wanted to split it off as it is related specifically to the existing load() mechanism and where I think we could tweak existing code slightly to make a function that would be more efficient to support APIv4
What currently happens
load() is called for each **requested** group in turn.
If you want contacts in 8 different groups is is called 8 times.
(take a moment to realise I'm not talking about populating all groups in this gl - only those groups specifically required for the action)
it follows these steps
1) checks if it has already been loaded within this php process
2) checks if the cache date on the civicrm_group is NULL or longer ago than the smart group cache timeout
3) creates a temp table
4) populates the temp table with the contents of the saved search
5) acquires a mysql lock for the group - if not aquired it returns at this point
6) removes records for those groups from the group_contact_cache table
7) inserts rows from the temp table into the group_contact_cache table
8) drops the temp table
9) updates the group contact cache table.
10) releases the lock
What I think we could do is have a new function
```
public function loadGroups($groupIds) {
}
```
which would start with ids as a list of groups to resolve but
1) filter out any ids already loaded in this php process
2) filter out any groups with expired caches
3) attempt to acquire locks on each group, filter out any groups for which a lock cannot be aquired.
3) create a temp table
4) populate the temp table with the contents of each of the filtered groups (one by one still - we could test UNION later on if we want - out of scope)
5) remove records from the group contact table for all the groups
6) insert rows from the temp table for all the groups
7) drop the temp table
8) update the group contact cache table for all groups
9) release all the locks
While this is potentially less php cycles the thing I'm really trying to get to is less inserts into the civicrm_group_contact cache table as these can clash with each other or with delete actions. There is a risk that the number of rows inserted at once would be too many (although this already exists & it's unclear whether this WOULD actually make it worse) - we might iterate through the temporary table only inserting say 50k rows per query if this turns out to be an issue in testing.
I think @mattwire developed the process whereby we build a temp table first and then insert and I believe it has been a big improvement. I think this would get us further. I would want to focus on testing / implementing it in apiv4 rather than everywhere but api v4 could then figure out what groups it wants and request that they be loaded before joining onto the group_contact_cache table (in practice
LEFT JOIN civicrm_group_contact_cache UNION civicrm_group_contact if not all groups are smart groups).
I've also been pondering the (out of scope!!!) idea of really splitting out the temporary table building from the insert into smart group contact cache - perhaps the table could be durable & the query could use the temporary table itself and we could store the temporary table name & timestamp and somehow fire off a non-browser process to reap it into the group_contact_cache and drop the table.
@pfigel @colemanw @seamuslee @mattwire @totten @bgm @sluc23 @BjoernEhttps://lab.civicrm.org/dev/core/-/issues/2487Fix recurring contribution defaults2021-04-08T21:11:19ZeileenFix recurring contribution defaultsThe contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly...The contribution_recur table defaults have some flaws. These don't really affect much in the way of existing code because people have been forced to pass them in and not rely on the defaults.
1) more fields should have defaults (mostly because it would stop test failures like this one https://test.civicrm.org/job/CiviCRM-Core-PR/40065/testReport/ - but it's also a case of bringing the API into line with the UI.
2) the default for the contribution_status_id should be pending not Completed. As long as it is correctly created as pending then the status will be updated by the BAO (to In Progress or Completed as appropriate) when a contribution is created that is linked to it. Core code correctly creates recurrings with the status id of Pending passed in but the api incorrectly defaults to Pending. Discussion is here https://github.com/civicrm/civicrm-core/pull/19512
- fields
| field | UI default | Old DB default | new db default |
| ------ | --------- | ------------- | -------------- |
| create_date | current time |none - must be passed in (required field)| current time |
| modified_date | current time |none - must be passed in (required field)| current time |
| start_date | current time |none - must be passed in (required field)| current time |
| frequency_unit | 1 |none - must be passed in (required field)| 1 |
| contribution_status_id | Pending |Completed| Pending |
Regarding frequency unit - I could see a case for the existing - required with no default - except that it's 'partner' field HAS a default of 'month' - which seems more of a leap than giving this a convenience default - especially since 1 really is the most frequent - more so than 'month' I expect5.37.0https://lab.civicrm.org/dev/core/-/issues/2485Search-kit - allow functions in the GROUP BY clause2022-05-12T13:39:07ZeileenSearch-kit - allow functions in the GROUP BY clause@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR...@colemanw I was hoping the answer to https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/issues/465 might be 'use search-kit' - but it seems reports allows the opportunity to include functions when grouping by date - eg
YEAR(receive_date)
https://www.techonthenet.com/mysql/functions/year.php5.51.0https://lab.civicrm.org/dev/core/-/issues/2480Group filtering in search kit2021-06-17T03:25:47ZeileenGroup filtering in search kitI'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups ...I'm deliberately framing this issue as group filtering because group filtering has 99% of the gains and 2% of the complexity of adding group support to search kit / apiv4.
**History**
In the beginning there were groups are smart groups and you could search on them.
There was no `group_contact_cache` table. It was possible to see 'hard' groups on the groups tab but it
was not possible to see smart groups. People asked to be able to see smart groups. Lobo said no.
Around 4.2 there was a sponsored 'improvement' to revert Lobo's 'no'. The group contact cache was added so that it was possible to populate all the smart groups and find out what group a contact was in.
Also around 4.2 and pretty much as soon as the new feature dropped a setting was added to allow sites to turn off the ability to see smart groups on the group tab because it was killing their sites.
Since 4.2 people have struggled with smart group cache performance, and lots of patches have been merged to try to address it.
Also since 4.2 people have been frustrated that there are very few places where you can access the smart groups a contact belongs to - we have had requests to show this on exports and my contact dashboard. However we switched back to the 'no' approach on this because it kills medium+ sizes sites.
More recently it has become effectively possible to turn off the smart group caching again by setting the time out to 0 and turning off opportunistic cache clearing. This is the approach I use and cautiously recommend.
**Smart groups, groups and performance**
So we have 3 things
1) which groups has someone actively been added to
2) which are the contacts that THIS saved search / smart group finds
3) of all the many many searches saved on this site which groups would find a person
Because we UI-conflate groups & smart groups we also conflate 3 into 1 & 2. I think there is a use-case for 3 but for most sites it is not worth the performance hit. We can deliver 1 & 2 in a performant way by following our existing code practices - most notably the one that made reports work ie:
If there is a group filter in play then
1) resolve the group filter to a list of relevant smart groups
2) create a temporary table of all the contacts in those groups (potentially but not necessarily using the `group_contact_cache`)
3) Use the table as the base ie `SELECT * FROM my_temp_table INNER JOIN civicrm_contact .....`
**Should we bypass the group contact cache?**
Probably codewise it's easier to populate it first because we have code that does. However, I have pretty strong doubts that it is very often effectively pre-populated before a query on a particular group runs.
There is a cron to prepopulate smart groups - on some sites this might make sense to use. My recommendation remains 'don't unless you have tested on your site'
**Could we filter off the saved search directly**
Yeah this is an interesting idea - add in a saved search rather than a group. Could be powerful. Let's keep pondering
**How would it look**
`Contact::get()->setWhere('group_id', 'IN', [8,7,89]);`
Note for not in we wouldn't be able to do the Base table inner join trick & TBH we can get the tests & contract right before we do any sort of optimisation5.39.0https://lab.civicrm.org/dev/core/-/issues/2476Proposal move weird acl stuff to extension2023-07-21T05:03:18ZeileenProposal move weird acl stuff to extensionI've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new rep...I've been cleaning up the civicrm_acl table and the code supports 3 types of acls but the UI doesn't and hooks don't leverage them.
My take is that they started out with 2 - contact based & non-smart-group-based and then added a new replacement - role based - without ever removing the first 2
The different types are denoted by the value entity_table in civicrm_acl. I believe this is only ever equal to civicrm_acl_role
I think we could simplify the code by moving the support for the other 2 to a core extension which ideally we only enable on upgrade IF we get results from
```SELECT * FROM civicrm_acl WHERE entity_table != 'civicrm_acl_role'```
@seamuslee @DaveD I'd be interested to see if you come to the same conclusionhttps://lab.civicrm.org/dev/core/-/issues/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/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/2444Searchkit search display links - can we offer option to open in an popup2021-03-18T01:59:42ZeileenSearchkit search display links - can we offer option to open in an popupWhen configuring links for search display it would be nice to be able to specify if they should open as a pop up/ modal (currently they open in a new screen and there is no choice to do differently)When configuring links for search display it would be nice to be able to specify if they should open as a pop up/ modal (currently they open in a new screen and there is no choice to do differently)https://lab.civicrm.org/dev/core/-/issues/2442Proposal - adjust weights on activity contact record types2021-04-07T22:47:08ZeileenProposal - adjust weights on activity contact record typesThis came out of testing search kit - when you search for contacts and add in activity contacts the default record type is 'Assignees' - in search kit data and, I think, real world data I think 'Target' would be a better choice as assign...This came out of testing search kit - when you search for contacts and add in activity contacts the default record type is 'Assignees' - in search kit data and, I think, real world data I think 'Target' would be a better choice as assignees are often empty and I feel like people 'know what they are doing' when trying to find assignees whereas for target I think they are less deliberate about thinking which contact they want.
![image](/uploads/400685a613ddd35ef3190da22631b067/image.png)
Changing this would mean altering the default weights on the option values to re-order the 3 activity types. Personally I think it would be fine to make this change. If we are nervous we could do for new installs only.
I'm not sure the order of source & assignee matters - I flip flop on the order I'd choose there.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/2422Add created_id & modified_id to civicrm_saved_search2021-04-19T15:15:46ZeileenAdd created_id & modified_id to civicrm_saved_searchThis would bring the table into line with civicrm_group and I can already see that once you create a few searches you start wanting to see who created them
Possibly also created_date modified_date although civicrm_group does not have t...This would bring the table into line with civicrm_group and I can already see that once you create a few searches you start wanting to see who created them
Possibly also created_date modified_date although civicrm_group does not have these as yet5.37.0