CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-03-18T01:48:44Zhttps://lab.civicrm.org/dev/core/-/issues/323Delete contact image does not remove the file2023-03-18T01:48:44ZJKingsnorthDelete contact image does not remove the fileSummary:
Contact images are not deleted from the server when they are 'deleted' through the front end.
Steps to recreate:
* Edit a contact and upload a contact image, save
* Look in the site directory for contact images - the file is t...Summary:
Contact images are not deleted from the server when they are 'deleted' through the front end.
Steps to recreate:
* Edit a contact and upload a contact image, save
* Look in the site directory for contact images - the file is there
* Edit the contact and choose 'Delete contact image'
* Refresh the directory, the file is still there (and still accessible over the web - even to anonymous users)
Technical:
The function that deletes the contact image only removes the database reference: https://github.com/civicrm/civicrm-core/blob/7432a41c4cccb22ab035aea2c5ed4780617f3676/CRM/Contact/BAO/Contact.php#L1066-L1077
What should happen:
Recognisable portraits are special personal information according to GDPR legislation. Deleting a portrait, whether at a user's request or to remove it, or if it's done by a user through a profile, should also remove that file from the server.
How to make it happen:
Make the deleteContactImage function also remove the file from the server.
How to make it happen retrospectively:
It would be feasible to create an extension(?) that would scrape through the user image directory and delete all files that aren't referenced in in the image_url of the civicrm_contact table, or the civicrm_file table? This has previously been suggested in this StackExchange response: https://civicrm.stackexchange.com/a/24206/124https://lab.civicrm.org/dev/core/-/issues/1327Address 'noise' (& performance) of status checks2023-03-17T05:03:25ZeileenAddress 'noise' (& performance) of status checksAt the New York sprint improving status checks was discussed with a view to addressing concerns that:
* Some system status messages are slow in some cases (large Dbs, connectivity issues) in an unresolvable way & sysadmins want to be ab...At the New York sprint improving status checks was discussed with a view to addressing concerns that:
* Some system status messages are slow in some cases (large Dbs, connectivity issues) in an unresolvable way & sysadmins want to be able to just stop the pain for some or all alerts
* Message is overly & inappropriately alarming for some users - e.g a manager might see a ‘warning’ and think it’s a bug.
We agreed to do the following
1. ~~Add is_active to civicrm_status_pref to disable individual status checks - this would be exposed via api but not UI. (we want it to be possible to disable them but not ‘easy’ as it needs to be very deliberate & done with clear understanding.~~
This was done in 5.19 - https://lab.civicrm.org/dev/core/issues/1295
1. Add new granular ‘view status checks permission’ - github here https://github.com/civicrm/civicrm-core/pull/14521 under discussion
1. Prototype less aggressive notification for alerts - e.g ‘you have 7 todo items’ or red (beige) ‘7’ in menu rather than an alert popups - do we still do ‘error’ as a popup?
1. Not in the sprint doc but I believed we agreed that the checks should run by cron & be displayed at user login rather than running on user login - we should add al issue when someone is ready to work on that.
The less aggressive notifications are more of a wishlist item at this stage. It would be good to fund Coleman to do it - otherwise it might flounder a bit.
Regarding the new granular status permission check - we discussed this again in Barcelona as the intent was unclear. @totten clarified his permission is that once we add ‘view status checks' permission then people with 'Administer CiviCRM' OR ‘view status checks' would see the checks. This doesn't immediately mitigate the issue as it would generally not be possible to remove Administer CiviCRM so it doesn't achieve much.
However, along with this @totten mooted the idea of adding 2 new permissions that are actually roles -
- Administer CiviCRM System
- Administer CiviCRM Data
The latter would have implicit permissions like Administering option values whereas the former would have things like view status checks by default. The main goal here would be to make it possible for sites to remove 'Administer CiviCRM' and leave most admins with just 'Administer CiviCRM Data'.
The idea was that if we have a call CRM_Core_Permission::check('view status checks') then it would return TRUE if the person has the 'view status checks' permission OR the 'Administer CiviCRM Data' permission
The issue is that the 'devil is in the detail' - for example we have a bunch of permissions jammed under 'Administer CiviCRM' that would need putting into one role or the other. We could mature this permission in an extension if we want as there is a usable hook
Related issue
https://lab.civicrm.org/dev/core/issues/1041
https://docs.google.com/document/d/1z1Lm-DUrri6xPzGXU37nLk5SfRjo4i9Elvx-lfbmK24/edit#heading=h.164d9ulc2oa3https://lab.civicrm.org/dev/core/-/issues/611Allow permissioned contact to download the invoice2023-03-15T05:03:18ZsunilAllow permissioned contact to download the invoiceTo Print other contact Invoice Logged in contact need 'access CiviContribute' permission
To Print own Invoice Logged in contact need 'view my invoices' Permission.
If user role only have 'view my invoices' permission and want to print ...To Print other contact Invoice Logged in contact need 'access CiviContribute' permission
To Print own Invoice Logged in contact need 'view my invoices' Permission.
If user role only have 'view my invoices' permission and want to print invoice of contact which have Permissioned relationship. It gives access denied message.
(e.g. Employee should print invoice of Employer contact if relationship is Permissioned)https://lab.civicrm.org/dev/core/-/issues/4164CiviMail send mails only to certain location type2023-03-13T11:54:35ZjmargrafCiviMail send mails only to certain location typeI have the following Usecase:
A big organization is using CiviCRM for mailing marketing of different departments. Their Contacts can have several email addresses (with different location types).
A Contact has an email address that is use...I have the following Usecase:
A big organization is using CiviCRM for mailing marketing of different departments. Their Contacts can have several email addresses (with different location types).
A Contact has an email address that is used by department A for the communication with the customer via mass mailing.
But department B wants to communicate with the customer via another email address via mass mailing.
Currently there seems to be no possibility to select which email address location type should be preferred for an specific mass mailing (of department A - while department B creates another mass mailing and wants to select their preferred location type for another mass mailing).
Possibilities in CiviCRM:
I can create different location types for the different purposes.
I can add email addresses with the corresponding location type.
I can select one email address as the primary email address.
I can select one email address for mass mailing.
Problem:
But I can not select different email addresses for different mass mailings
Possible Workaround:
I could keep the two contacts as duplicates in the system. But the customer still still want to have an overall overview over their communication with this contact - so simply having duplicates is not an attractive option.
Feature Request:
What I would need is the feature of selecting the preferred location type to be used for a specific mailing.
If the contact has no email address of this communication type the fallback option could be the primary / bulk-e-mail-address
What effort would it take to create such a feature? I guess it would make most sense to implement it into the civicrm core - do you aggree?https://lab.civicrm.org/dev/core/-/issues/4169Let "Number" and "Money"-type custom fields be nullable2023-03-13T07:39:11ZnoahLet "Number" and "Money"-type custom fields be nullableOverview
----------------------------------------
There are many times when NULL would be a meaningful/useful value in a custom field of type "Number" (float) or "Money" (decimal). However, it is not currently possible, via the form laye...Overview
----------------------------------------
There are many times when NULL would be a meaningful/useful value in a custom field of type "Number" (float) or "Money" (decimal). However, it is not currently possible, via the form layer, to set these fields to NULL. Blank values are currently turned into zero.
Example use-case
----------------------------------------
Let's say we need to track the elevation (meters above or below sea level) of the addresses in our database.
1. Create a custom field "Geographic Elevation" of type "Number", extending the Address entity. Leave the "Default value" blank.
1. Go to a contact and edit one of their addresses, or create a new one.
1. On the create/edit form, leave the "Geographic Elevation" field blank -- because let's say we don't know the elevation at this address.
1. Submit the form and view the saved value.
Current behaviour
----------------------------------------
"Geographic Elevation" is set to zero. That means sea level. But that's not correct -- we actually don't know the elevation.
Proposed behaviour
----------------------------------------
When the field submitted with a blank value (empty string), the database field should be set to NULL, and displayed as blank.
Comments
----------------------------------------
NULL is also a meaningful value for Money fields. Say we have a field on individuals called "Net Worth". Zero (the person is destitute) and NULL (we don't know how much money they have) are quite different.
It _is_ possible to set the field to NULL through the API, but only by passing the string 'null' (due to a PEAR DB limitation).
<details><summary>Show API example</summary>
````php
// NULL will be saved as 0
Civi\Api4\Address::update()
->addValue('Geography.Elevation', NULL)
->addWhere('id', '=', 27)
->execute();
$address = Civi\Api4\Address::get()
->addSelect('Geography.Elevation')
->addWhere('id', '=', 27)
->execute()->single();
// [
// 'id' => 27,
// 'Geography.Elevation' => 0,
// ]
// but 'null' will be saved as NULL
Civi\Api4\Address::update()
->addValue('Geography.Elevation', 'null')
->addWhere('id', '=', 27)
->execute();
$address = Civi\Api4\Address::get()
->addSelect('Geography.Elevation')
->addWhere('id', '=', 27)
->execute()->single();
// [
// 'id' => 27,
// 'Geography.Elevation' => null,
// ]
````
</details>https://lab.civicrm.org/dev/core/-/issues/1690Multiple scheduled reminders per contact when scheduled job fails2023-03-11T05:03:20ZMartinMultiple scheduled reminders per contact when scheduled job failsOverview
----------------------------------------
We're seeing scheduled reminders occurring more than once. In our case we have reminders set up before expiry of memberships (e.g. 7 days before). In some cases when we look at the activi...Overview
----------------------------------------
We're seeing scheduled reminders occurring more than once. In our case we have reminders set up before expiry of memberships (e.g. 7 days before). In some cases when we look at the activities for a contact, there are multiple entries for a reminder (all with status "completed"). For a given contact these show up once per cron run, for multiple subsequent cron intervals (i.e. 1 activity each hour for multiple hours in a row).
These occurrences coincide with failures of the send_reminder scheduled job. Looking at the job log shows this result:
```
Entity: Job Action: send_reminder
Summary
Finished execution of Scheduled reminders sender with result: Failure, Error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Details
Parameters parsed (and passed to API method):
a:1:{s:7:"version";i:3;}
Full message:
Finished execution of Scheduled reminders sender with result: Failure, Error message: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
```
It appears when this failure happens for the scheduled job, the contact still get an activity for their scheduled reminder, and they continue to do so each cron run (in our case this scheduled job is set to be hourly), until the job shows a success (at this point is the last activity they get).
Looking at the code in CRM_Core_BAO_ActionSchedule it appears that the email is sent (sendReminderEmail) before the activity is created (createMailingActivity), so I expect the contact has in fact received multiple emails, NOT that multiple activities were created without emails being sent.
Without digging further, I'm guessing maybe civi considers ALL reminders have failed in the batch if the scheduled job fails, even if some were sent out and the job failed partway through.
Reproduction steps
----------------------------------------
In our case the "MySQL server has gone away" db error appears to be causing this, which of course is a problem unto itself, but would be preferable if Civi could handle this situation better.
Current behavior
----------------------------------------
Contact receives multiple emails and activity entries when only 1 should occur. They are getting n+1 of these, where n is the number of times the scheduled job fails.
Expected behavior
----------------------------------------
It would be preferable for only 1 email to be sent to each contact, and that if the job fails, only the unsent emails are then sent later.
Contacts should only get 1 email reminder, and 1 "completed" activity. Maybe they should also get other activities for the failed cron runs with another status such as "failed" or "cancelled", but that probably doesn't matter much either way.
Environment information
----------------------------------------
* __CiviCRM:__ 5.23.0
* __PHP:__ 7.2.29
* __CMS:__ Drupal 7.69
* __Database:__ MySQL 5.7.29https://lab.civicrm.org/dev/core/-/issues/1580Allow to search on contribution id2023-03-10T06:17:56ZyashodhaAllow to search on contribution idAllow to search on contribution idAllow to search on contribution id5.28.1yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1727Allow sites to not have Billing Address Location Type2023-03-09T05:03:25ZJoeMurrayAllow sites to not have Billing Address Location TypeOverview
----------------------------------------
Currently CiviCRM has a confusing array of default location types and flags. This issue proposes changes that would allow the Is Billing flag to be the only indication that a location is ...Overview
----------------------------------------
Currently CiviCRM has a confusing array of default location types and flags. This issue proposes changes that would allow the Is Billing flag to be the only indication that a location is the billing location rather than also having a Location Type of Billing. The intent is to allow instances to experiment with simpler approaches to Location Types in order to improve the usability of the product.
Example use-case
Add a hook to allow billing location to be determined by an alternative implementation. Sample LExIM extension approach would return the address which has isBilling==True if there is no LocationType of 'Billing' or if there is no address passed to function with LocationType of 'Billing' from https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/BaseIPN.php#L491
In current places where code creates a 'Billing' type address one potential approach would assume it should be home location type for individual and household contacts and work for organizational contacts. In all cases the Is Billing would still be set. The objective of this proposal is to refactor and introduce hooks in order to allow a LExIM extension to work. More details about specific places in code that need to be changed and ideas on what exactly to do in a simpler approach to be provided if there is potential for this proposal to go forward.
Comments
----------------------------------------
Just testing water for potential support before developing more detailed proposal. Otherwise we'll likely just override core for this particular client.JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/1460How best to handle Event Dispatchers during upgrade2023-03-08T05:03:30ZseamusleeHow best to handle Event Dispatchers during upgradeAs shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discu...As shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discuss the best ways forward and if we need to move the whitelisting or similar to the dispatcher or elsewhere ping @eileen @tottenhttps://lab.civicrm.org/dev/core/-/issues/1734Remove `profile listings and forms` permission2023-03-08T05:03:29ZwmortadaRemove `profile listings and forms` permissionOverview
----------------------------------------
The `profile listings and forms` permission is shorthand for four other permissions relating to profiles - `profile create`, `profile edit`, `profile listings`, `profile view`.
I'm guess...Overview
----------------------------------------
The `profile listings and forms` permission is shorthand for four other permissions relating to profiles - `profile create`, `profile edit`, `profile listings`, `profile view`.
I'm guessing that there was a historic reason for this but I think it is confusing and potentially leaves sites less secure as a result. I propose that it is removed. Instead each of the four permissions are set individually as required.
Current behaviour
----------------------------------------
There are five permissions relating to profiles:
* `profile create`
* `profile edit`
* `profile listings`
* `profile view`
* `profile listings and forms`
The latter is a catch all for the other four.
Proposed behaviour
----------------------------------------
There are four permissions relating to profiles:
* `profile create`
* `profile edit`
* `profile listings`
* `profile view`
As part of the upgrade process the user is prompted to review permissions and ensure that any user roles that currently have the `profile listings and forms` permission are given each of the above permissions.
Comments
----------------------------------------
The reason I have raised this issue is that it was unclear to me what each of these permissions were four. Following some discussion, I have made [some](https://github.com/civicrm/civicrm-user-guide/issues/355) [proposals](https://github.com/civicrm/civicrm-user-guide/pull/441) to improve the documentation but think it would be better if this permission were just removed.
The permissions are defined in [CRM/Core/Permission.php](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#L289-L326).
I've found two uses of this permission in core:
* [CRM/Contact/BAO/Contact.php](https://github.com/civicrm/civicrm-core/blob/363ce69adee8c277d94d9b31ef3ca8782db9394f/CRM/Contact/BAO/Contact.php#L3672)
* [CRM/Core/BAO/UFGroup.php](https://github.com/civicrm/civicrm-core/blob/4cef91ce8a2df4c34ac30fc05a61900ffb046e6f/CRM/Core/BAO/UFGroup.php#L1290)
And one in CiviVolunteer:
* [api/v3/VolunteerUtil.php](https://github.com/civicrm/org.civicrm.volunteer/blob/master/api/v3/VolunteerUtil.php#L176)
(There may be more, but these are the ones I've spotted.)https://lab.civicrm.org/dev/core/-/issues/1730Allow extensions to skip entity operations by catching exceptions thrown in p...2023-03-06T05:03:25ZjensschuppeAllow extensions to skip entity operations by catching exceptions thrown in pre and post hooksOverview
----------------------------------------
Extensions should be able to skip actions performed on entities with a warning/error message. `hook_civicrm_pre()` and `hook_civicrm_post()` implementations do not allow for skipping alto...Overview
----------------------------------------
Extensions should be able to skip actions performed on entities with a warning/error message. `hook_civicrm_pre()` and `hook_civicrm_post()` implementations do not allow for skipping altogether, but only for altering parameters.
Example use-case
----------------------------------------
The [de.systopia.donrec](https://github.com/systopia/de.systopia.donrec) extension forbids contributions be deleted when they have been legally receipted, since allowing deletion of such contributions would be considered fraudulent behavior by tax authorities.
Current behaviour
----------------------------------------
Currently, exceptions thrown in implementations of those hooks produce fatal errors, which, when run via Ajax, appear to "hang the system", because the XHR returns a 500. There is no way for extensions to skip such an action in a way that would be handeled by the UI.
Proposed behaviour
----------------------------------------
`hook_civicrm_pre()` and `hook_civicrm_post()` implementations should be able to skip execution of the current action (e.g. deleting an entity). The invoking code should therefore catch exceptions thrown by those implementations. This would allow for displaying exception messages as error message popups in the UI.
Comments
----------------------------------------
I'm not sure whether this can be done generically or would have to be implemented separately for each caller. I guess it's the latter. In that case, consider this issue as a discussion starter for whether this is desirable to include in CiviCRM Core.https://lab.civicrm.org/dev/core/-/issues/1680Convert email contact "to" boxes to Entity Ref fields2023-03-01T05:03:24ZmeppsConvert email contact "to" boxes to Entity Ref fieldsCurrently, the email "to" boxes in the email contact form use an older form of search. It would be a better user experience to convert this to using the Entity Ref search box from here: https://github.com/civicrm/civicrm-core/blob/db9e09...Currently, the email "to" boxes in the email contact form use an older form of search. It would be a better user experience to convert this to using the Entity Ref search box from here: https://github.com/civicrm/civicrm-core/blob/db9e0947e008ba06308da5664e5c36a3bc2736df/js/Common.js#L739.https://lab.civicrm.org/dev/core/-/issues/1678Export time out avoidance2023-03-01T05:03:23ZeileenExport time out avoidanceSites have a php time out to prevent long running processes & out of control loops. However, there are some processes that are known to need more time that others & we can extend the timeout within php to keep them alive. This is pretty ...Sites have a php time out to prevent long running processes & out of control loops. However, there are some processes that are known to need more time that others & we can extend the timeout within php to keep them alive. This is pretty safe because it's within a loop so we extend a little each row rather a huge time extension
Basically we can check each iteration here & if less than 10 seconds remains we can add 10 seconds as a sort of heartbeat https://www.php.net/manual/en/function.set-time-limit.phphttps://lab.civicrm.org/dev/core/-/issues/1644Merge related activities not deleted when permanently deleting a contact2023-02-26T05:03:38ZeileenMerge related activities not deleted when permanently deleting a contactWhen a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained...When a contact is merged into a another contact the following happens
- the data is moved over
- the merged contact is 'deleted'
- an activity is created of type 'Contact Merged' - source is logged in contact, target is the retained contact
- If the merged contact is being deleted to trash an activity is created of type 'Contact Deleted by Merge' - source is logged in contact, target is deleted contact
When we later fully delete the contact deleted-by-merge only activities linked to no other contact are deleted - in other words the 'Contact Deleted by Merge' activity remains, linked to the source contact.
I believe this activity should be deleted on true-death , as it would not be present had they been fully deleted in the first instance
@pfigel @DaveDhttps://lab.civicrm.org/dev/core/-/issues/1582Display preferences settings "Do not notify assignees for" and "Include ICal ...2023-02-25T05:03:39ZDaveDDisplay preferences settings "Do not notify assignees for" and "Include ICal Invite to Activity Assignees" are only implemented in the form layerI'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This i...I'm unlikely to work on this but logging that these two display preferences are tied to the form layer and only referenced (either directly or indirectly) via CRM/Activity/Form/Activity.php, and so are ignored when using the api.
This is not recent. I'm sure it has always been this way.https://lab.civicrm.org/dev/core/-/issues/692Unable to use url search arguments in 'Advanced Search' using force=12023-02-25T05:03:38ZMonish DebUnable to use url search arguments in 'Advanced Search' using force=1Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm...Currently, it is not possible to use URL search arguments in 'Advanced Search' using force=1 to load search results. This is no longer working except for mailing params which are manually handled [here](https://github.com/civicrm/civicrm-core/blob/5.10/CRM/Contact/Form/Search.php#L636L647).
Following are the steps to support URL search arguments Civi component-wise:
1. All the search forms extends the parent class ```CRM_Core_Form_Search``` that will define a new function ```loadSearchParamsFromUrl()```. Definition as follows
```php
function loadSearchParamsFromUrl() {
// In case no component is defined then lookout for basic contact search fields + all enanbled components search fields
if (!$this->_component) {
if (method_exists('CRM_Contact_Form_Search', 'setSearchParamFromUrl')) {
CRM_Contact_Form_Search::setSearchParamFromUrl($this);
}
foreach ($enabledComponents as $component) {
$searchClass = $component->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
$searchClass::setSearchParamFromUrl($form);
}
}
}
elseif (array_key_exists($this->_component, $enabledComponents)) { // $_component = 'CiviMail'
$searchClass = $enabledComponents[$this->_component]->namespace . '_Form_Search';
if (method_exists($searchClass, 'setSearchParamFromUrl')) {
// call CRM_Mailing_Form_Search::setSearchParamFromUrl()
$searchClass::setSearchParamFromUrl($form);
}
}
}
```
2. This function will be called by respective search form to find the search arguments from URL and set them accordingly. And will be handled in ```SearchClass::setSearchParamFromUrl($form);``` as:
```php
class CRM_Contact_Form_Search {
...
public static function setSearchParamFromUrl(&$form) {
foreach (CRM_Contact_Form_Search_Criteria::getBasicSearchFields() as $name => $type) {
if ($value = CRM_Utils_Request::retrieve($name, $type)) {
$form->_formValues[$name] = $value;
}
}
$form->_params = CRM_Contact_BAO_Query::convertFormValues($form->_formValues);
$form->set('formValues', $form->_formValues);
$form->set('queryParams', $form->_params);
}
}
```
The intent is to generalize the workflow and let each component's search form decide and hosts its list of search arguments (on basis of enabled component) rather than manually handling them in different places.5.11Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/1653Civi::paths() - Allow bare variable lookup via getUrl/getPath2023-02-24T05:03:58ZtottenCivi::paths() - Allow bare variable lookup via getUrl/getPathOverview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
------...Overview
----------------------------------------
The `Civi::paths()->getUrl(...)` and `Civi::paths()->getPath(...)` have a quirky interpretation of bare variable expressions (eg `getPath('[civicrm.packages]')`).
Example use-case
----------------------------------------
```
# (A) With a file/folder/subpath
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/foo/bar');"
# (B) No slash, no dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
# (C) With a slash
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/');"
# (D) With a slash and dot
cv ev "echo Civi::paths()->getUrl('[civicrm.packages]/.');"
```
Current behavior
----------------------------------------
In scenarios (A), (C), and (D), the value of `[civicrm.packages]` is substituted. But in situation (B), it is treated as a literal file-name and given the default prefix.
```
$ cv ev "echo Civi::paths()->getUrl('[civicrm.packages]');"
http://site/[civicrm.packages]
```
Proposed behavior
----------------------------------------
All examples -- including (B) -- should do substitution.
The `Civi\Core\PathsTest` should be expanded to check scenario (B).
Comments
----------------------------------------
[Historically](https://lab.civicrm.org/dev/wordpress/issues/47#note_33046), when `getPath()`/`getUrl()` were first drafted to support expressions like `[civicrm.files]/persist/contribute`, the primary concerns were (1) backward compatibility for older absolute+relative expressions (without any `[foo]` expressions) and (2) new use-cases like (A). The `[foo]` notation was conceived as an *optional prefix* (with an *implied default*) - and not as a straight-up *variable*. And if you *just* wanted a raw variable, I'd've imagined it'd be faster to call `getVariable()` (bypass the string-munging with `getPath()` etc).
OTOH, if you learned of this API by skimming docblocks or examples (without that historical context), then it'd be natural to assume that (B) would work, and it really is a more approachable interface that way.
Strictly speaking, it is a change in the contract for an obscure edge-case: if you had a file named `/var/www/sites/default/files/civicrm/[foo]`, and if you requested `getPath('[foo]')`, then it currently resolves to the file. With this change, it would interpret `[foo]` as a variable - the variable is probably undefined, which leads to an exception. You'd have to rewrite the call as `getPath('[civicrm.files]/[foo]')`. That's an exceedingly marginal edge-case, and I don't really think it's worth preserving.https://lab.civicrm.org/dev/core/-/issues/2669Target contact missing for automatically generated case activities2023-02-23T16:00:45ZAndreasandreas.howiller@civiservice.deTarget contact missing for automatically generated case activitiesOverview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cann...Overview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cannot be edited through the user interface. While this is a minor issue, some users may want to leave notes about the activity (for example, why they changed a case title) and therefore need to edit it.
Reproduction steps
----------------------------------------
1. Open any case in CiviCRM and change the case title.
2. Tap edit for the corresponding activity in the activity timeline.
3. Tap save.
Current behaviour
----------------------------------------
The dialog will freeze while the CiviCRM logo keeps turning. A fatal error "DB Error: constraint violation" will be filed in the logs.
If you add any contact as a target contact in the database or in the edit screen the error won't appear anymore.
What is confusing, too: When editing the activity the client contact already wrongly shows up as target contact in this dialog and if you'd like to change it there you need to search the contact (the link to choose the client contact below the search field won't do the change here).
Expected behaviour
----------------------------------------
The Client contact is filed as target contact by default and connected problems disappear. E.g. editable activities can be saved after edit through UI now.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_ and _5.38.0_
* __CMS:__ _WordPress 5.7.2_https://lab.civicrm.org/dev/core/-/issues/1633Proposal - add an optional access_arguments key to setting spec2023-02-22T05:03:56ZeileenProposal - add an optional access_arguments key to setting specCurrently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution...Currently when calling Setting.get or Setting.getoptions you need 'administer CiviCRM' permission
I recently found that an angular form was broken for users without this & digging into it I'm using the hook as a short term solution - ie
```
if ($entity === 'setting' &&
(($action === 'get' && isset($params['return']) && $params['return'] === 'deduper_equivalent_name_handling')
|| ($action === 'getoptions' && $params['field'] === 'deduper_equivalent_name_handling'))
) {
$permissions['setting']['get'] = [['merge duplicate contacts', 'administer CiviCRM']];
}
```
But this relies on the setting being accessed this way - so it's very brittle. I'm not sold on just lowering the whole permission level.
My feeling is that we should extend the metadata spec - ie add optional key of
'access_arguments' => ['default' => 'be amazing', 'get' => 'be fair to middling']
- this would mean only amazing people can create the setting (when check_permissions are enabled) but fair to middling people could get the setting.
In all cases the default is still 'Administer CiviCRM' if nothing is set
@colemanw @totten @seamuslee @mattwirehttps://lab.civicrm.org/dev/core/-/issues/1612Extension life-cycle bug for managed entities of a type declared in the exten...2023-02-22T05:03:55ZMichael McAndrewExtension life-cycle bug for managed entities of a type declared in the extensionLets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I d...Lets say I have an extension that defines a new **entity type** Ocean.
And also declares some Oceans as **managed entities** (Atlantic, Pacific).
When I install it, everything works nicely. The managed oceans are created.
But when I disable it, I start to experience problems because (I presume) attempts to manage the oceans are happening after CiviCRM no longer knows what an ocean is.
Proposed solution: ensure that entity types defined by disabled extensions are always available during attempts to manage entities.