Development issueshttps://lab.civicrm.org/groups/dev/-/issues2022-01-09T23:43:19Zhttps://lab.civicrm.org/dev/financial/-/issues/89A contribution batch containing transactions of more than one currencies caus...2022-01-09T23:43:19ZkleehkA contribution batch containing transactions of more than one currencies causes fatal errorMy setup: CiviCRM 5.18.3 on Drupal 7.
I created a Contribution batch. At transactions I chose two transactions of difference currencies e.g. HKD and USD and Assign them to the batch.
Then I no longer be able to retrieve the list of bat...My setup: CiviCRM 5.18.3 on Drupal 7.
I created a Contribution batch. At transactions I chose two transactions of difference currencies e.g. HKD and USD and Assign them to the batch.
Then I no longer be able to retrieve the list of batches because of fatal error: Dialog: DataTables warning: table id=crm-batch-selector-2 - Ajax error. For more information about this error, please see http://datatables.net/tn/7
Even I cancel the offending transaction it does not help. I had to delete the transaction in that batch to revive the batch's functioning.
Originally posted at StackExchange
[Link here](https://civicrm.stackexchange.com/questions/33382/a-contribution-batch-containing-transactions-of-more-than-one-currencies-causes)
```
Oct 17 09:53:08 [debug] $backTrace = #0
/var/www/c53/web/sites/all/modules/civicrm/CRM/Core/Error.php(463):
CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /var/www/c53/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(55): CRM_Core_Error::handleUnhandledException(Object(CRM_Core_Exception))
#2 /var/www/c53/web/sites/all/modules/civicrm/drupal/civicrm.module(444): CRM_Core_Invoke::invoke((Array:3))
#3 /var/www/c53/web/includes/menu.inc(527): civicrm_invoke("ajax", "batchlist")
#4 /var/www/c53/web/index.php(21): menu_execute_active_handler()
#5 {main}
```
Attached please see the error screen capture![MixedCurrencyError](/uploads/a472c5fec8af87b6b62e8e13342c9c99/MixedCurrencyError.png).5.47.0JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/financial/-/issues/88Should we add is_deleted to the civicrm_contribution table?2019-10-24T11:38:33ZeileenShould we add is_deleted to the civicrm_contribution table?Despite @JoeMurray's best efforts we DO all contributions to be deleted. We do have precedent on other tables for soft deletions via an is_deleted flag. The difficulty with switching to that is it takes time to filter out possible places...Despite @JoeMurray's best efforts we DO all contributions to be deleted. We do have precedent on other tables for soft deletions via an is_deleted flag. The difficulty with switching to that is it takes time to filter out possible places of leakage.
However, we have just added is_template to the civicrm_contribution table (https://lab.civicrm.org/dev/financial/issues/72) on the understanding we will put the time into filtering out leakage over a few releases before starting to use it (& initially not in core) - which makes me wonder if we should add is_deleted & do the work on that at the same time & perhaps add an extension for soft deleting for those who want to be ahead of the game.
@JoeMurray @BjoernE @mattwire @ejegg @pradeep @monish.deb @ayduns @artfulrobot - any thoughts?https://lab.civicrm.org/dev/core/-/issues/1336CRM_ACL_BAO_Cache::updateEntry is bonkers and possibly even broken2019-10-30T01:35:14ZseamusleeCRM_ACL_BAO_Cache::updateEntry is bonkers and possibly even brokenThe function mentioned seems to be written in such a way as it is trying to do two jobs at once which seems very very odd indeed.
Firstly the $id param isn't clearly spelled out however when it calls the deleteEntry() function it seems ...The function mentioned seems to be written in such a way as it is trying to do two jobs at once which seems very very odd indeed.
Firstly the $id param isn't clearly spelled out however when it calls the deleteEntry() function it seems that the $id is of the contact being viewed.
however later on when it calls getAllACLs for contact and also build the cache table it is now believing that $id is the contact id of the user trying to access the contacts. Which makes more sense but still feels very much odd ball.5.20.0seamusleeseamusleehttps://lab.civicrm.org/dev/financial/-/issues/84Making the poor performance associated with the creditnote_id field opt in r...2021-03-31T02:07:56ZeileenMaking the poor performance associated with the creditnote_id field opt in rather than opt outSometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers pe...Sometime before the joys of Lexim code was introduced to Core to add a creditnote_id to any contribution whose status was changed to Refunded, or Cancelled (later Chargeback was added).
This fitted a specific use case - the numbers permitted a prefix & had to be sequential. However, anecdotally most large sites have hacked it out because the performance is so bad.
During the Barcelona sprint a [patch was merged](https://github.com/civicrm/civicrm-core/pull/15232) making it possible to install [an extension](https://github.com/greenpeace-cee/at.greenpeace.creditnope) to opt out of having a credit note sloooowwwly calculated.
However, in the world of Lexim use-case specific functionality should be OPT IN rather than opt out. Ie it should be the case that you need to install an extension to GET the slow behaviour not to NOT get it.
This is also a good test case for the general practice of moving functionality out of core into an extension. Here are the steps I believe are required
1) Determine where the code interacts with core. I did this & determined that all the places where createCreditNoteID is called from other than Contribution.create are not hit & I added a [pr to deprecate them](https://github.com/civicrm/civicrm-core/pull/15492) & fix the one place where it is hit. As a result of this the only interaction required would be in the pre_hook so we don't need to add a hook to generate this field (per https://lab.civicrm.org/dev/core/issues/1308) - this is a good thing as the assumption that credit notes & contributions would not be many to one is flawed & we don't want to bake this into core - we want to get it out of core
2) Create an extension that can be installed to add the credit note id in the pre hook.
3) Get the extension reviewed & approved for automatic installation
4) Add this new extension so it is installed on upgrade for existing sites - this step will require some input from @totten on how to do it & not knowing how is a blocker but probably getting the extension ready is a necessary pre-step & is probably only a couple of hours of work
Also we should consider this proposed performance improvement https://github.com/civicrm/civicrm-core/pull/15235https://lab.civicrm.org/dev/core/-/issues/1335Saving a case type can give a php warning, but the warning is more hidden tha...2019-10-20T20:04:13ZDaveDSaving a case type can give a php warning, but the warning is more hidden than usual so it seems like everything is okIgnoring for the moment the part about the hidden warning, what's happening is:
When you retrieve a case type, e.g. via the api or lower level functions, [this line](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseT...Ignoring for the moment the part about the hidden warning, what's happening is:
When you retrieve a case type, e.g. via the api or lower level functions, [this line](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseType.php#L283) is doing this:
`$activityType = json_decode(json_encode($activityTypeXML), TRUE);`
which seems to be a quickie way of converting the whole object and its children to an array. This works fine when none of the children have blank node text, and you get `$caseType[...intermediate keys...]['default_assignee_contact'] = '203'` or whatever. If they are blank, like `<default_assignee_contact></default_assignee_contact>`, then the blank node text is actually treated as an empty object, and so gets converted to an empty array and you get `$caseType[...intermediate keys...]['default_assignee_contact'] = []`. By itself not too bad.
Now when you convert back to xml, either by saving or calling api.create or a lower level function, [these lines](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseType.php#L152-L156) do this:
```
$xmlFile .= "<ActivityType>\n";
foreach ($values as $key => $value) {
$xmlFile .= "<{$key}>" . self::encodeXmlString($value) . "</{$key}>\n";
}
$xmlFile .= "</ActivityType>\n";
```
The encodeXmlString function just calls htmlspecialchars. But if you pass an array to htmlspecialchars it gives a warning.
So at least two possibilities for how to fix:
1. Alter encodeXmlString to return the empty string if it's not passed a string to begin with.
2. Don't return mixed data types for elements and instead either return an empty string if it's an empty array, or omit the xml element completely. I'd hesitate a little because technically it would change for example what the api returns for CaseType.get for something like default_assignee_contact when it's blank.
Sample steps to reproduce:
1. Create a new case type.
1. Add a timeline.
1. Add a followup activity to the timeline and for default assignee select By Relationship, and pick a relationship type.
1. Click Save.
1. Now go back and edit the case type and don't change anything just click save.
1. Check drupal watchdog and you'll see the warning listed.
1. At this point you can also do something further like this using cv, but you first have to edit CRM_Case_BAO_CaseType::convertDefinitionToXML() because for some reason when run through cv error_reporting gets set to E_ERROR only, so add a line at the top of that function `error_reporting(E_ALL);`. Yet another weirdness.
1. Then you can do this, but replace '3' with the case type id. `cv php:eval "$id = 3; $x = civicrm_api3('CaseType', 'get', ['id' => $id]); $y = CRM_Case_BAO_CaseType::convertDefinitionToXML($x['values'][$id]['name'], $x['values'][$id]['definition']);"`
1. Check drupal watchdog and you'll see the same warning.
Another way to think of this is that api.get followed directly by api.create without touching the data gives a warning.
Why this doesn't pop up a warning on the screen, or output anything during `cv` calls, is a little bit of a mystery. What I can see is that drupal's error_handler is logging it to drupal watchdog, but in other places throughout civi warnings that get logged to drupal watchdog usually show up on the screen, if not on the same page then when you go to another page. I'd be curious if running this through cv in joomla or wordpress does output the warning.5.20.0https://lab.civicrm.org/dev/core/-/issues/1334Cannot submit event registration for free ticket2019-10-20T23:06:09ZiamandanycCannot submit event registration for free ticket**Overview**
My event registration and payment form suddenly stopped working for the complimentary/free ticket option. Users cannot press "continue" to submit the form if they chose complimentary ticket.
Event registration page: [click ...**Overview**
My event registration and payment form suddenly stopped working for the complimentary/free ticket option. Users cannot press "continue" to submit the form if they chose complimentary ticket.
Event registration page: [click here](https://apprenticelearning.org/civicrm/?page=CiviCRM&q=civicrm%2Fevent%2Fregister&reset=1&id=7)
**Before**
It was working fine and we registered a bunch of complimentary ticket users until it suddenly stopped working.
**After**
When you click the submit button, the next page does not load and it stays on the current page, i.e. folks cannot register.https://lab.civicrm.org/dev/financial/-/issues/80Noisily deprecate transact api2019-10-24T21:16:11ZeileenNoisily deprecate transact apiWe should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/79We should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/795.20.0https://lab.civicrm.org/dev/financial/-/issues/79Deprecate Contribute.transact api2019-10-24T21:15:57ZeileenDeprecate Contribute.transact apiThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussionThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussion5.20.0https://lab.civicrm.org/dev/financial/-/issues/77PaymentProcessor.pay should handle 'invoice_id' & map it to a getter so pro...2019-11-04T23:47:09ZeileenPaymentProcessor.pay should handle 'invoice_id' & map it to a getter so processors can retrieve it5.20.0https://lab.civicrm.org/dev/core/-/issues/1331Don't freeze fields for auto-renew memberships2020-03-30T14:18:17ZwmortadaDon't freeze fields for auto-renew membershipsIf a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* M...If a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* Membership type
* ~~Membership end date~~ [no longer frozen]
* Membership status
![image](/uploads/2ac776a76bf0a662e89f6426604da0ce/image.png)
This issue is split out from https://lab.civicrm.org/dev/core/issues/1126 which looked specifically at the end_date field. This fix has now been merged into core ([PR #15540](https://github.com/civicrm/civicrm-core/pull/15540)).
I've created this ticket to look at the other fields that are also frozen following discussion in my [original PR](https://github.com/civicrm/civicrm-core/pull/15505).
# Issue
The ability to edit the membership type is an issue for our organisation because sometimes people sign up for the wrong membership type and we need to change this. For non-recurring payments this is no problem, we can just change it manually and if necessary take additional payment or make a refund. But for recurring payments we are unable to do this because the field is frozen. We are then stuck and have no way of changing the membership type in CiviCRM through the UI.
The ability to edit the membership organisation isn't an issue for us as we only have one membership organisation. However, other organisations may want to be able to do this for the same reason as above.
The ability to edit the membership status also isn't an issue for us, but I don't really understand the logic of freezing it for auto-renew memberships and so I'm also including it here for consistency.
# Proposal
My proposal is that CiviCRM core shouldn't freeze any of these fields. If required they can be frozen by an individual payment processor or other extension.
My feeling was that the logic about whether the fields should be editable or not will vary from organisation to organisation depending on the business processes of the organisation and the payment processor that they use. So, I don't feel that CiviCRM core should be imposing this. It should be down to each organisation to make their own customisations as required. If and where appropriate it could be included in the logic for an individual payment processor.
This involves removing the relevant code as per [PR #15505](https://github.com/civicrm/civicrm-core/pull/15505).
# Summary of changes
*This summary is for the benefit of those who don't want to read the lengthy discussions below. It can also be used in the release notes.*
This change fixes an issue which meant that it wasn't possible to edit some membership fields when a membership was set to auto-renew. Following the change it is now possible to edit all of the fields on the edit membership form.
* These fields are no longer frozen:
* Membership Organisation
* Membership Type
* Membership Status
* A warning is displayed to alert users that any changes they make to the membership may not be reflected in the payment processor
* The Membership Organisation/Type field is initially uneditable but there is a link to make it editable
If the membership is *not* set to auto-renew there is no change to the edit membership form. So this change will have no effect on organisations that don't offer recurring payments for membership.
If your organisation *does* offer recurring payments for membership you should make staff aware of these changes. In particular you should make them aware that changes they make to the membership may not be reflected in the payment processor. This means that if you make a change you may also need to update the corresponding record in the payment processor. This depends on the particular payment processor that your organisation uses so you will need to check the functionality that your payment processor supports.
If you would like to restore the previous functionality so that these fields are frozen and uneditable you can install this extension: [Freeze Membership Fields](https://lab.civicrm.org/extensions/freeze-membership-fields).
The change will be included in CiviCRM version 5.25 which is due for release in May 2020. See [PR #16609](https://github.com/civicrm/civicrm-core/pull/16609) for more details on the change.
https://lab.civicrm.org/dev/core/-/issues/1330Too many custom fields2022-06-29T04:32:32ZkristinecToo many custom fieldsAdding 93+ custom fields within a custom_group seems to cause a DB Constraint error and gives an error when clicking manage cases (for some cases). To replicate:
1. Create a custom group
2. Add 93 custom fields
3. Once you pass 93, the ...Adding 93+ custom fields within a custom_group seems to cause a DB Constraint error and gives an error when clicking manage cases (for some cases). To replicate:
1. Create a custom group
2. Add 93 custom fields
3. Once you pass 93, the error "DB Constraint Violation - custom_group_id should possibly be marked as mandatory for CustomField,create API. If so, please raise a bug report" appears when saving a new custom field.
4. Find several cases and when trying to access their case page, I get an error: "case_id is not valid : 1."
5. Disable the custom group. Error #4 disappears.
This can be marked as a paid-issue-queue.https://lab.civicrm.org/dev/core/-/issues/1329Too many dead people in sample data2019-11-27T02:16:43Zjustinfreeman (Agileware)Too many dead people in sample dataCiviCRM sample data contains too many dead people (Contact, Individual, Deceased = True) - there's a total of 27 dead contacts. Can we bring these people back to life please?
The number of dead people that you actually want in your CRM ...CiviCRM sample data contains too many dead people (Contact, Individual, Deceased = True) - there's a total of 27 dead contacts. Can we bring these people back to life please?
The number of dead people that you actually want in your CRM data should be a very small percentage, unfortunately this state of being seems to be over-represented in the sample data.
Let's breathe some life back into the sample data!
Agileware Ref: CIVICRM-13775.20.0https://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/1326when filing on case, original activity not retained2023-09-08T20:15:55Zlcdwebwhen filing on case, original activity not retainedIn previous versions, when an activity was filed to a case, the activity remained on the contact record with the text "Filed on case..." prepended to the subject. That changed with this commit:
https://github.com/civicrm/civicrm-core/com...In previous versions, when an activity was filed to a case, the activity remained on the contact record with the text "Filed on case..." prepended to the subject. That changed with this commit:
https://github.com/civicrm/civicrm-core/commit/9a30d940eee1d62e57d1a5db7a8651b46cc7a674
The activity still has the text prepended to the subject, but because the activity is marked as not a current revision, it doesn't appear on the contact record's activity listing.
I think the activity should be marked as not a current revision if the activity is moved, but not if filed on a case. Looking for feedback on the concept before I file a PR. @mattwire can you chime in, as that was your PR.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1325Autoassignees on case activities might assign the wrong person if client has ...2020-07-06T23:21:37ZDaveDAutoassignees on case activities might assign the wrong person if client has another case with that role assigned thereIn a case type timeline you can configure autoassignees for activities based on a role in the case. To reproduce:
1. In the case type edit screen configure a role like "Benefits Specialist is".
2. Add another timeline (you can use the s...In a case type timeline you can configure autoassignees for activities based on a role in the case. To reproduce:
1. In the case type edit screen configure a role like "Benefits Specialist is".
2. Add another timeline (you can use the standard one but it's easier to see with a new one).
3. In that timeline add a followup activity and set the autoassignee to be by relationship and to "Benefits Specialist is".
4. Save the case type.
5. Create a case of that type.
6. Assign the role of "Benefits Specialist is" to someone.
7. Add the other timeline via the Add Timeline dropdown on manage case. So far ok.
8. Create another case for the *same client*.
9. Don't assign the role of "Benefits Specialist is".
10. Add the other timeline again to this case.
11. The Benefits Specialist from the OTHER CASE gets assigned here.
**Note that this happens even if you close the first case before the second.**
I think there's two things going on. One is a variation of issues with closed cases and relationships noted elsewhere, and the other is that the lookup for who to assign doesn't take case_id into account. The first part though would be made irrelevant here if the case_id is taken into account.
There is a little gotcha for relationships that can and usually do exist outside the case, like spouse. If you assign the relationship outside the case, then you might actually expect it to be assigned to the activity without having to assign it specifically as a role on every case.
TBD
And this isn't a recent issue I'm thinking it's always been independent of case_id since introduced.5.29.0https://lab.civicrm.org/dev/core/-/issues/1324Customfields attached to addresses break the profile page2019-10-28T08:08:37ZVangelisPCustomfields attached to addresses break the profile page## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm...## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm.org (CiviCRM 5.20.alpha1) :
* Create a new CustomGroup and assign it to the entity 'Address'
* Create a new customfield (for example of type textfield)
* Populate the field with some dummy information
* Create a new profile and add 2 fields:
* Street Address
* Your newly created customfield
* Click on 'More -> Use edit mode'
* The page should break with error `DB Error: no such field`
## Background
It seems that the issue starts here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Contact.php#L1784
and then goes here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1036
and the actual join should take place somewhere here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1307
In short: There is an additional field, the id of the customtable that is holding the customfield in the select query that is not being joined properly (join is actually missing) from the constructed query.5.20.0https://lab.civicrm.org/dev/core/-/issues/1323Can't use "Add Activity" task from Search Builder2019-10-16T20:33:23ZJonGoldCan't use "Add Activity" task from Search BuilderSteps to replicate:
* Do a search from Search Builder.
* Select *Add Activity* as your task.
* Submit the activity.
Observe your yellow screen of death.
It's a one-line fix, the wrong user context is passed to the state machine.Steps to replicate:
* Do a search from Search Builder.
* Select *Add Activity* as your task.
* Submit the activity.
Observe your yellow screen of death.
It's a one-line fix, the wrong user context is passed to the state machine.5.19.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1320Workflow templates - Include displayname in subject2019-10-26T20:33:11Zmagnolia61Workflow templates - Include displayname in subjectMany email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it mak...Many email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it makes the email more personal as it is clear who it is addressed to.
This is proven to be beneficial for open-rates of transactional mails.
The messages will be upgraded in 5.20alpha1 by #15491
https://github.com/civicrm/civicrm-core/pull/155135.20.0magnolia61magnolia61https://lab.civicrm.org/dev/core/-/issues/1319No Household Member Relationship Created when an Individual shares a relation...2020-02-19T20:48:07ZalicefruminNo Household Member Relationship Created when an Individual shares a relationship with a householdWhen editing a Contacts Address:
IF one clicks "Use another contact's address"
AND then selects a HOUSEHOLD contact to share an address with
THEN the address is shared BUT a **household member relationship is NOT created**.
The S...When editing a Contacts Address:
IF one clicks "Use another contact's address"
AND then selects a HOUSEHOLD contact to share an address with
THEN the address is shared BUT a **household member relationship is NOT created**.
The Shared Address help text says: "If you link an individual's address to an organization, an employee-employer relationship will be automatically created. **If you link an individual's address to a household, a household member relationship is created.**"
Which leads me to believe this is a regression. It seems the functionality for linking an individual's address to an organization has been enhanced specifically:
When one clicks "Use another contact's address"
AND then selects a ORGANIZATION contact to share an address with
THEN a "Set this organization as current employer" checkbox appears
IF checked then a relationship is created... if not no relationship is created
as discussed [here](https://github.com/civicrm/civicrm-core/pull/12574)
Perhaps a similar checkbox should appear when sharing a household address.
![sharedAddressHelpText](/uploads/9800c3df1b22b02f4342ccf05fb141cc/sharedAddressHelpText.png)5.23.0https://lab.civicrm.org/dev/user-interface/-/issues/11Remove CiviCRM install count from dashboard2023-12-02T18:42:58ZnicolRemove CiviCRM install count from dashboardIt was said at the 2019 Summit/Sprint that a requirement to get CiviCRM listed in the Wordpress plugins directory was to turn off statistics pingback on new installs by default - and this happened a few months ago (can anyone confirm? @c...It was said at the 2019 Summit/Sprint that a requirement to get CiviCRM listed in the Wordpress plugins directory was to turn off statistics pingback on new installs by default - and this happened a few months ago (can anyone confirm? @cividesk?). As a result all new installs of CiviCRM are not pinging stats collection so the total site count appears to have fallen in the same period from near 11,000 six months ago to around 10,000 today:
![image](/uploads/0630494d9e7df38a00001212afca3d9e/image.png)
Perhaps there is is another cause, but is it time to just remove this stat from the main CiviCRM dashboard? This was a post-it proposal put to the UX/UI group during the sprint as the notice seems to be giving a false impression of the project being in decline. Not sure what this would entail but it appears linked to this template: [templates/CRM/Dashlet/Page/GettingStarted.tpl](https://github.com/civicrm/civicrm-core/blob/8b9a8f4abb25cfa7a498eaaa3e459e4d313e350a/templates/CRM/Dashlet/Page/GettingStarted.tpl) & this file: [CRM/Dashlet/Page/GettingStarted.php](https://github.com/civicrm/civicrm-core/blob/bdeb5d154507df2dc913fc1ee9aaedfaa4721c04/CRM/Dashlet/Page/GettingStarted.php).bgmbgm