CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-10-17T05:03:22Zhttps://lab.civicrm.org/dev/core/-/issues/1523Should we be overriding the default temp table size?2023-10-17T05:03:22ZJonGoldShould we be overriding the default temp table size?Overview
----------------------------------------
While working with ACLs today, I got this error message:
```
[nativecode=1114 ** The table 'civicrm_tmp_e_aclccache_67845b31b6526452bc0e37b6ce4c68fd' is full]
```
This temp table is set ...Overview
----------------------------------------
While working with ACLs today, I got this error message:
```
[nativecode=1114 ** The table 'civicrm_tmp_e_aclccache_67845b31b6526452bc0e37b6ce4c68fd' is full]
```
This temp table is set to use the MEMORY engine. Which makes sense - but then we can't create a table larger than MySQL's `max_heap_table_size`, which by default is 16MB.
Now, we should ideally never show this error. We can take one of two approaches:
* We can override `max_heap_table_size` on a per-MySQL session basis. With our centralized temp table creation, this should be easy.
* We can document this issue in the sysadmin guide, maybe under a "steps for large installations" page.
I'm inclined toward the first option - we should handle problems for sysadmins, not ask them to - but would like the input of folks who know MySQL better than me before I write a patch.
Reproduction steps
----------------------------------------
1. Create an ACL for a user who can view a lot of contacts (in my case, ~127,000).
2. As that user, search for contacts.
Current behaviour
----------------------------------------
Error above.
Expected behaviour
----------------------------------------
No error.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1516Discussion ticket for handling multivalued tokens in pdfs/emails2023-09-25T14:58:11ZDaveDDiscussion ticket for handling multivalued tokens in pdfs/emailsIn particular related to:
* https://github.com/civicrm/civicrm-core/pull/12012
* and its rebased version https://github.com/civicrm/civicrm-core/pull/16200
* https://github.com/civicrm/civicrm-core/pull/16208
There are a number of way...In particular related to:
* https://github.com/civicrm/civicrm-core/pull/12012
* and its rebased version https://github.com/civicrm/civicrm-core/pull/16200
* https://github.com/civicrm/civicrm-core/pull/16208
There are a number of ways to deal with multivalued fields when you need to produce scalar output based on the field.
For example:
* Take the "first" one.
* This has the disadvantage that "first" doesn't really mean anything, especially if the order is not guaranteed to be the same each time.
* Take the "last" one.
* Ditto.
* Combine them separated by commas.
* This has the disadvantage that it may not make any sense or might look silly. Consider something like the "With Contact" on an activity. Suppose there are 3. Suppose you want to include the primary phone of the contact. Your pdf might look like this. It's not terrible, but now think about adding in address too.
* With Contact: John Smith, Mary Brown, Indiana Jones
* Phone: 555-123-2222, , 555-383-8383
* And it's not clear to me that it can guarantee that the phone values are in the same order as the names when the tokens are separate.
* Do as in https://github.com/civicrm/civicrm-core/pull/12012, where you give the template designer the option to specify a numeric suffix on the token, e.g. {activity.target_2_display_name}. The way it's implemented there has some limitations:
* The order is still arbitrary - what does "2" actually mean?
* The template designer doesn't know max(N), so they can't easily do something like concatenate all of them if they want to.
* Provide some shorthand tokens for some common uses, e.g.
* {activity.target_1_phone} means arbitrarily take the first one.
* {activity.target_COMBINE_phone} means combine all with commas.
* {activity.target_ALL_phone} means give an array and I'll do some smarty-based looping in my template to get what I want.
Further, there are some situations where you might not want some recipients to see some of the other values. An example might be activity.case_id as in [16208](https://github.com/civicrm/civicrm-core/pull/16208). There maybe it makes sense to have a token that means "concatenate all the cases where the recipient has a role, and leave out the others". A similar one might apply for activity.target_display_name, where it might mean "concatenate all the with contact display names for activities where the recipient is one of the activity_contacts.
A related note that's just food for thought: In my other life, I always try to set up 2 fields when somebody asks for something multivalued. For example "services performed". Somebody might come to you asking for a couple of the different types of service you offer. You can designate one as the primary service, which is a single-valued field, which then makes reporting work because you don't run into double-counting, and then have a secondary services field that is multi-valued, which you don't use for reporting, and in emails/pdfs you can concatenate it without it being arbitrary because you would also output the primary which is single-valued. That may not be useful right now, but this is a discussion ticket.https://lab.civicrm.org/dev/core/-/issues/1512Address ID field should be exportable2020-01-10T23:28:27ZJonGoldAddress ID field should be exportableOverview
----------------------------------------
Address ID is currently not set as exportable.
Example use-case
----------------------------------------
The use case for exporting is to ship address data to a third party for cleanup (...Overview
----------------------------------------
Address ID is currently not set as exportable.
Example use-case
----------------------------------------
The use case for exporting is to ship address data to a third party for cleanup (vendors who will return addresses with more accurate postal codes, changes of address, etc.). It's necessary to export an address ID to allow a reimport on the same address.
Current behaviour
----------------------------------------
Address ID not exportable.
Proposed behaviour
----------------------------------------
Address ID exportable.5.23.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1510"_[custom field id number]" suffix is causing issues2020-01-10T13:06:15Zndavis"_[custom field id number]" suffix is causing issuesThis custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see f...This custom field id number changes between environments requiring a lookup algorithm to get the correct field name when writing code.
Why add this ID at all? Developers should be entrusted to name their custom fields the way they see fit. If this causes a name collision that's on the developer. It's not the project's responsibility to manage custom field names.
At the most you should force a "custom_" prefix or something similar. Forcing an _[custom field id number] suffix causes more problems than it solves, at least for those of us that don't develop on our production server since these ids change from one environment to the next, depending on what order features get implemented by the organizational development team. _PLEASE_ fix this. It makes custom fields nearly unusable for some organizations.https://lab.civicrm.org/dev/core/-/issues/1487Scheduled Reminders, Tokens listed as being available for use in the Schedule...2020-09-17T09:49:12Zjustinfreeman (Agileware)Scheduled Reminders, Tokens listed as being available for use in the Scheduled Reminder ignore the context which is used to trigger the reminder and therefore do not evaluateScheduled Reminders, Tokens listed as being available for use in the Scheduled Reminder ignore the context which is used to trigger the reminder and therefore do not evaluate. This is a bug in the Scheduled Reminder UI and is a regular p...Scheduled Reminders, Tokens listed as being available for use in the Scheduled Reminder ignore the context which is used to trigger the reminder and therefore do not evaluate. This is a bug in the Scheduled Reminder UI and is a regular point of confusion for users.
Proposed change:
1. The available Tokens shown in the Tokens drop-down list should be filtered to be relevant to the selected Entity.
2. Tokens for Contact which will work in all context should remain available.
Agileware Ref: CIVICRM-1403
![DiUC6edfBY](/uploads/d90c1aba5e288b56f2f78fa0a7afbcd4/DiUC6edfBY.png)
![chrome_MLUcPI966g](/uploads/9b015f82e89720faa6c66283819ba90d/chrome_MLUcPI966g.png)https://lab.civicrm.org/dev/core/-/issues/1476Warn on failed templates_c write2023-01-20T05:03:16ZJonGoldWarn on failed templates_c writeOverview
----------------------------------------
I think this is a problem that we've all faced at some point or another, but experienced implementers know how to fix this, and newbies get caught. When some of your `templates_c` files ...Overview
----------------------------------------
I think this is a problem that we've all faced at some point or another, but experienced implementers know how to fix this, and newbies get caught. When some of your `templates_c` files are owned by a user that's not the user running PHP, Civi silently fails in weird and wonderful ways.
Reproduction steps
----------------------------------------
1. Recursively `chown` your `templates_c` folder such that the PHP user doesn't have write access.
Current behaviour
----------------------------------------
Parts of the Smarty forms fail to render.
Expected behaviour
----------------------------------------
Some sort of warning that there's a permissions issue on the `templates_c` folder.
I don't mind doing this if it gets "Concept Approved", though admittedly I've never dug that far down. I'm worried that Smarty isn't going to bubble up an exception, but it's worth a look.https://lab.civicrm.org/dev/core/-/issues/1439No way to identify 'deceased' contacts when viewing or reporting on relations...2023-01-15T05:03:21Zellen_compucorpNo way to identify 'deceased' contacts when viewing or reporting on relationshipsOverview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as de...Overview
----------------------------------------
Marking a contact record as 'is_deceased' doesn't currently appear to have any impact on the contact's relationships, which makes sense overall (for example, if a contact was marked as deceased and then a scheduled job were to automatically expire all it's relationships, it would be very manual and annoying to reverse that if 'is_deceased' had been added by accident. However, it would be extremely useful (a) when viewing relationships on contact records and (b) when reporting on relationships, to know whether one of the contacts involved in the relationship is deceased.
Example use-case
----------------------------------------
On a contact record:
1. Create a contact (contact A)
1. Add a relationship to another contact (contact B)
1. Mark contact A as deceased
1. View relationships tab on contact record for contact B
Within reports:
1. Go to create new relationships report (/civicrm/report/instance/5?reset=1&output=criteria)
1. View columns/ filters tabs; no configurations available relating to 'is_deceased'
Current behaviour
----------------------------------------
On a contact record:
- No change to relationship (or relationship display) when one of the contacts is marked as deceased
Within reports:
- As described above
Proposed behaviour
----------------------------------------
On a contact record:
- Propose that - on the relationships tab of the contact record - after the name of the contact that is deceased is added in red "(deceased)" in the same way that it is added next to the main display name at the top of the contact record for a deceased contact currently.
![3DC980F2-DC13-440B-A9D3-6875552B2006](/uploads/fb62f7fa05eeaa9002a9298cff5813d5/3DC980F2-DC13-440B-A9D3-6875552B2006.png)
On reports:
- Propose that a filter is added so that 'deceased' contacts can be excluded from relationships reports
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/1423civicrm_contribution_recur.is_email_receipt is ignored2020-01-15T17:02:54ZRichcivicrm_contribution_recur.is_email_receipt is ignoredOverview
----------------------------------------
The recur table has a `is_email_receipt` column. To me this means that this is a per-recurring-contrib preference, but this does not appear to be honoured.
Reproduction steps
---------...Overview
----------------------------------------
The recur table has a `is_email_receipt` column. To me this means that this is a per-recurring-contrib preference, but this does not appear to be honoured.
Reproduction steps
----------------------------------------
(I've written a test in a PR to follow.)
1. Create a contribution recur record with `is_email_receipt = 1`
1. add a completed contrib
1. expect an email, don't get one.
Expected behaviour
----------------------------------------
I think the behaviour *should* be:
1. was `is_email_receipt` passed in to the API call? If so, use that.
*if not*...
2. is the contrib part of a recurring contribution, and is the recur record's `is_email_receipt` set (to 0 or 1)? If so, use that.
*if not*...
3. is the contrib linked to a contribution page? If so, use the contribution page's setting.
*if not*...
4. send one by default
Environment information
----------------------------------------
* __CiviCRM:__ _Master @ 38891c5df7
[possibly linked issue](https://lab.civicrm.org/dev/core/issues/1245)https://lab.civicrm.org/dev/core/-/issues/1416Export to PDF with useful filename2023-11-22T05:03:22ZCoreyBurgerExport to PDF with useful filenameIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titleIf you export a report to PDF, the file name is "CiviReport.PDF". That is a major headache if you are exporting multiple reports. Ideally, the report should be exported with some kind of useful title, likely a shortening of the report titlehttps://lab.civicrm.org/dev/core/-/issues/1403Change "Contribution Received Date" to be "Contribution date" where is exists...2024-01-28T01:17:26ZJamie Novick - CompucoChange "Contribution Received Date" to be "Contribution date" where is exists and basically sort this Contribution dates mess out once and for allOk... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion ...Ok... sorry if this comes across as a bit of a rant but as a qualified accountant this has been driving me crazy for years and I think we've been skirting around this issue for sometime. I wanted to put in a gitlab to start a discussion to allow us to sort this out once and for all.
**Overview:**
----------------------------------------
CiviCRM has a core field on the contribution called "receive_date". This shows up on various screens and has led to significant debate about whether it should be a required field or not, and what it's real use case is. For example discussions below where debate has raged on how it should work:
https://lab.civicrm.org/dev/core/issues/1057
https://lab.civicrm.org/dev/core/issues/680
https://lab.civicrm.org/dev/core/issues/1140 - slightly different but related re: accruals accounting
https://lab.civicrm.org/dev/core/issues/1402
**The issue:**
----------------------------------------
So... there are a few problems with this field:
a) The idea of a "received date" is a bit meaningless (and confusing to users) when you have a pending contribution. You haven't quite received anything yet.
b) The idea of a "received date" conflicts with the payments dates if you have multiple payments (or could even be made to be different from the payment date) again which is nonsensical.
I assume contribution received date was a field that pre-dated the CiviCRM accounting implementation and hence perhaps hasn't kept up with the reality of the situation. In any case I believe this is causing some real issues now and should be sorted out.
Note the field is used:
1) As the date when initial accounting transactions are made. i.e. create a new pending contribution it will be the date of the Debit and Credits / transaction recorded in CiviCRM and hence by default it is the "revenue recognition date" for account purposes for the income.
This then leads to a multitude of other issues:
a) If I "complete" a pending membership contribution for a new membership by recording a payment, what should the start date of the membership be? (see: https://lab.civicrm.org/dev/core/issues/1402)
b) We've then introduced another field called "revenue_recognition_date", which should actually be field 1 above - as that is when we are recognising the transactions. We shouldn't have another field for this.
c) For some reason we now have a field on the invoice called "invoice date" which prints todays date which again is incorrect as it should be the same as item 1 above. The invoice should reflect the revenue recognition date. https://civicrm.stackexchange.com/questions/21128/how-do-i-print-the-received-date-on-an-invoice
**Proposed solution:**
----------------------------------------
The solution is relatively simple. We should change the "received_date" field to simply be the "Contribution date".
| Invoicing? | Contribution status | What the field means | Changes required to CiviCRM |
| ------ | ------ | ------ | ------ |
| Not using invoices | Pending | Represents the date the contribution was recorded on the system. | When later marking the contribution as completed give users the option to update the date or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.
| Not using invoices | Completed | Represents the date the contribution was recorded on the system but also record a payment on the same date.
| Using invoices | Pending | Represents the date the invoice was recorded on the system and hence the invoice date and the revenue recognition date. | We should update the invoices to use this date as the invoice date. This field should not be updated when marking the invoice as complete (or better still don't offer the option to complete a contribution and simply only allow users to enter the payment separately.)
| Using invoices | Completed | Represents the date the invoice was recorded on the system but also the date the payment for that invoice was received. Ideally we would split the invoice and payment sections from each other on the "create new" form.
**Future:**
----------------------------------------
At some date in the future it would then be good to properly decouple payments from contributions and get rid of the terrible contribution status field once and for all.
Basically the contribution would reflect an order or invoice object, i.e. the obligation to pay for something. The payment transaction then would be separate and would represent the actual payment of that obligation. Accounting software has done this correctly for years so it's about time CiviCRM did too!
@mattwire @eileen @KarinG @dylan-circle @jaapjansma @JoeMurray @ErikHommel @fabian_SYSTOPIA and a few Compucorp names also - @omar_compucorp @Miya27
I'm sure you will all have opinions on this...https://lab.civicrm.org/dev/core/-/issues/1402Inconsistent behaviour when paying/completing a pending contribution with lin...2023-12-30T05:03:27ZJamie Novick - CompucoInconsistent behaviour when paying/completing a pending contribution with linked membershipOverview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applie...Overview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applies to both a "new/pending" membership or when renewing an expired membership.
Reproduction steps
----------------------------------------
Scenario 1: New membership
----------------------------------------
Create a membership with start date 1/1/2019 and term 1 year.
Set the membership status to anything.
Set the contribution status to pending.
Save
Scenario 1.1: Record payment
If you completed the payment using “Record Payment” and no matter what you set the receive date to during completing the payment the end date and the start date will remain the same (start date = 1/1/2019 , end date = 31/12/2019).
Scenario 1.2: “Edit Contribution -> change status to completed"
While completing the payment using “Edit Contribution -> change status to completed” will result in changing the membership start date to equal the contribution receive date and the end date to be 1 term away from the receive date, so if you set the receive date for example to 1/3/2019 then the start date will become 1/3/2019 and the end date 29/2/2020
Scenario 2. Renew membership that has expired (end date in the past)
----------------------------------------
Create a membership with start date 1/1/2018 and term 1 year.
Set the membership status to anything. It will be created as an expired membership.
Set the contribution status to completed.
Save
Scenario 2.1: Record payment
If you complete the renewal pending payment using “Record Payment” option, then no matter what you set the payment receive date to, the start date will change to “today's date” and the end date will be one 1 term after the start date
Scenario 2.2: “Edit Contribution -> change status to completed"
If you complete the payment with “edit contribution -> change status to completed” then also here Civi ignores the the receive date and it will always set the start date to “today's date” and the end date to 1 term after the start date.
Expected behaviour
----------------------------------------
Well, they should at least be consistent... but perhaps this is our opportunity to make CiviCRM less opaque and give users control over how the system should work?
| Scenario no | Situation | Recording payment approach | Current behaviour | Suggested behaviour |
| ------ | ------ | ------ | ------ | ------ |
|1.1| New | Record payment | Start date will remain as before | Message 1 below
|1.2| New | Edit Contribution -> change status to completed | Changes the membership start date to equal the contribution receive date | Message 1 below
|2.1| Renew expired | Record payment | The start date will change to “today's date” and the end date will be one 1 term after the start date | Message 2 below
|2.2| Renew expired | Edit Contribution -> change status to completed | Set the start date to “today's date” and the end date to 1 term after the start date. |Message 2 below
Message 1:
Show a message / popup to tell ask the user "The membership payment has been made in full, but the membership's start date is different to the payment date. Would you like to set the membership start date to the payment date?
1. Option 1: Yes - Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 2: No - Do not change the membership start date (**Show the existing start date**)
Message 2:
Show a message / popup to tell ask the user "The membership payment has been made in full. Please select a start date:
1. Option 1: Set Membership Start Date to the previous membership term end date
1. Option 2: Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 3: Create a new membership line with Membership start date on the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
In future we could allow admin to have a setting to set the defaults and hide the message to define the behaviour.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _Master/5.21 etc
Comments
----------------------------------------
This isn't the place for the long discussion about it but just to reiterate that I think the contribution "received" date field needs the label changed to be something more generic like "contribution date" as the field is used as the invoice date when generating an invoice (and cannot mean received date when the contribution is pending...). It also leads to inconsistencies with the above - the date of the last payment could be different from the contribution received date which is a meaningless statement. We should decouple "payment" from the order or invoice object (the contribution) and make the payments mean what they mean - when we got the payment - and the order/invoice mean what is means - when the contact entered into the obligation to pay from an accounting perspective.
Oh well seems I started a discussion on that here: https://lab.civicrm.org/dev/core/issues/1403#note_27422 and a decision on how the above should work should be done once the contribution date field usage is confirmed.https://lab.civicrm.org/dev/core/-/issues/1392Auto-fix missing system message templates2023-01-08T05:03:30ZbgmAuto-fix missing system message templatesDuring [PR#15844](https://github.com/civicrm/civicrm-core/pull/15844), we discussed that the upgrader can fail when there are missing message templates in the database. Their absence can go unnoticed when their related features are not u...During [PR#15844](https://github.com/civicrm/civicrm-core/pull/15844), we discussed that the upgrader can fail when there are missing message templates in the database. Their absence can go unnoticed when their related features are not used.
Since the upgrader can detect missing templates, it could also automatically re-create them.
Do we have all the required metadata in order to re-create them automatically?https://lab.civicrm.org/dev/core/-/issues/1385Adding multiple Contacts to case bulk action2023-01-06T05:03:33ZreneolivoAdding multiple Contacts to case bulk actionOverview
----------------------------------------
We want to add multiple clients to a single case.
Example use-case
----------------------------------------
1. Click on **Search** > **Find Contacts**
2. Click on the **Search** submit ...Overview
----------------------------------------
We want to add multiple clients to a single case.
Example use-case
----------------------------------------
1. Click on **Search** > **Find Contacts**
2. Click on the **Search** submit button
3. Select any number of contacts
4. Click on **Actions** > **Add to case as role**
5. **Assign to** any open case
6. **Relationship Type** should be **client** :warning:
Current behaviour
----------------------------------------
The are no **client** relationships.
We treat **client** as a relationship when we show them on the case's roles panel, but don't show this relationship type on the bulk actions.
We understand this issue happens because CiviCRM manages relationships between contacts, and Cases are an entity. But, for the user perspective, we should add support to this type of relationship.
Proposed behaviour
----------------------------------------
We have two proposals:
1. Add **client** as a relationship type for the **Relationship Type** dropdown on the **Add to case as role** bulk action. This can be added through hooks (more on that in a bit)
2. Add a new **Add to case as client** bulk action.
#### Option 1
We push `['client' => 'Client`]` directly to the list of relationship types here:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/Form/AddToCaseAsRole.php#L13
then we handle the form differently if the selected role was client:
```php
// ...
public function postProcess() {
$values = $this->controller->exportValues();
$caseId = (int) $values['assign_to'];
$roleTypeId = (string) $values['role_type']; // need to change this
$contacts = $this->_contactIds;
// if "client" was selected then we handle the form diferently
if ($roleTypeId === 'client') {
// add selected contacts as clients
} else {
// handle the form as normal when no custom handlers have been defined
}
}
```
#### Option 1 using hooks
This could be accomplished by allowing a hook on this line: https://github.com/civicrm/civicrm-core/blob/master/CRM/Case/Form/AddToCaseAsRole.php#L13
The code could look as follows
```php
<?php
// ...
public function buildQuickForm() {
$roleTypes = $this->getRoleTypes();
// this is a sample class that triggers the hook by passing these
// role types and allowing the array to be manipulated by hooks:
CRM_Hooks_updateBulkActionRoleTypes($roleTypes);
// continue building the form as usual...
}
```
The hook's implementer could do the following:
```php
myextension_civicrm_updateBulkActionRoleTypes(&$roleTypes) {
$roleTypes[] = ['client' => 'Client'];
}
```
Then, when the form is processed we can trigger a hook to get handlers:
```php
// ...
public function postProcess() {
$values = $this->controller->exportValues();
$caseId = (int) $values['assign_to'];
$roleTypeId = (string) $values['role_type']; // need to change this
$contacts = $this->_contactIds;
$addToCaseAsRoleHandlers = [];
// a custom hook as well:
CRM_Hooks_getAddToCaseAsRoleHandlers($addToCaseAsRoleHandlers);
// if we have custom handlers we run them:
if (count($addToCaseAsRoleHandlers)) {
foreach ($addToCaseAsRoleHandlers as $addToCaseAsRoleHandler) {
$addToCaseAsRoleHandlers->run([
'caseId' => $caseId,
'roleTypeId' => $roleTypeId,
'contacts' => $contacts
]);
} else {
// handle the form as normal when no custom handlers have been defined
}
}
```
#### Option 2
We add "Add to case as client" directly to the list of bulk action tasks:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/Task.php#L60
We add a custom form to handle adding the clients to the case.
#### Option 2 using hooks
We would do something similar to option #1 by executing a hook that adds more bulk actions task to a list. In this case the extensions can add their own bulk action:
```php
myextension_civicrm_getBulkActions(&$bulkActions) {
$bulkActions['ADD_TO_CASE_AS_CLIENT'] = array(
'title' => 'Add to case as client',
'class' => 'CRM_Case_Form_AddToCaseAsClient',
'result' => FALSE,
);
}
```
Comments
----------------------------------------
Let me know which option you would prefer. There are advantages to implementing them directly into core, or going the hook route:
* if we implement them directly everyone benefits from this feature.
* if we use hooks we don't add a feature that users might not need, but allow developers to customise the experience.https://lab.civicrm.org/dev/core/-/issues/1368Renaming "Current Employer" Field on Employer Relationship Type2023-01-03T05:03:32ZJerry AyodeleRenaming "Current Employer" Field on Employer Relationship Type**How it is:**
Currently the (Employer of/Employer is) relationship type includes an optional data field called “Current Employer”. Use cases where contacts have multiple employers suggest that this field can be put to more accurate use ...**How it is:**
Currently the (Employer of/Employer is) relationship type includes an optional data field called “Current Employer”. Use cases where contacts have multiple employers suggest that this field can be put to more accurate use with a little renaming.
![Screenshot_2019-11-05_at_13.19.57](/uploads/f58ccb8c984b3aacce2bf03b83357bf0/Screenshot_2019-11-05_at_13.19.57.png)
**How it should be:**
* Suggestion to change the phrasing of the “Current Employer” field in the Relationship section of contact records in CiviCRM to “Primary Employer”. As the field’s name in the Database is “employer_id”, it is fair to assume this change to not be too disruptive. This would allow for users to have multiple employers and separation, if necessary, between employers.
* It would also not be amiss to have a help icon on the field that users can toggle to get a clearer understanding of the field and its intended use.
If the suggested changes are made, Tokens, Import and Export functionality will likely be affected by the syntax changes and will need to be visited accordingly.https://lab.civicrm.org/dev/core/-/issues/1355Add mechanisn for avoiding conflicts when deduping2020-01-23T01:31:46ZeileenAdd mechanisn for avoiding conflicts when dedupingWe see occasional conflicts when 2 dedupe jobs try to dedupe 2 conflicts at the same time. It creates database deadlocks and noise on something where it feels like an Exception could be thrown and appropriately handled by the calling co...We see occasional conflicts when 2 dedupe jobs try to dedupe 2 conflicts at the same time. It creates database deadlocks and noise on something where it feels like an Exception could be thrown and appropriately handled by the calling code. In addition it's possible for 2 jobs to 'successfully' dedupe the same contact at the same time. This looks like : Job 1 loads the contact, Job 2 loads the contact, Job 1 dedupes the contact, Job 2 dedupes the contact, based on data from before Job 1 deduped the contact. In some cases this means Job 2 makes incorrect changes because it is acting on out-of-date data.
Now that we are pretty happily using mysql locks in their post-5.7.5 incarnation of actually working I think we can use these to address the issue.
In general I don't think a dedupe task wants to proceed if any other process is changing the given contact. For that reason I think it makes sense for the dedupe task to try to acquire generic 'contact' locks on the 2 contacts it is trying to dedupe before loading data about them. If any other task has demonstrated that it is acting on them (by acquiring one of both contact locks) the dedupe task can throw an exception & the form layer or batch job layer can handle that (as they already do handle exceptions).
I propose the exception is a new Exception for the purpose - CRM_Core_Exception_ResourceConflictExceptionhttps://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/core/-/issues/1311Help bubble on directories/resource url pages has some hidden diagnostic powers2023-04-15T05:03:32ZDaveDHelp bubble on directories/resource url pages has some hidden diagnostic powersThere's a help icon in the intro section on both the administer - system settings - directories and resource urls pages. It pops up a box that tells you what civi thinks things like `[civicrm.root]` evaluate to. This can be very helpful ...There's a help icon in the intro section on both the administer - system settings - directories and resource urls pages. It pops up a box that tells you what civi thinks things like `[civicrm.root]` evaluate to. This can be very helpful for diagnostic use, but there's nothing suggesting that the help icon has those powers.
![screenshot](/uploads/f972af49f9cc6115f1c9ed0a00e1c194/screenshot.gif)
I'm thinking it might be more obvious as a button somewhere lower down in body of the page, called something like "Explain shortcodes". Quick mockup:
![mockup](/uploads/819eb9783b4722ba9372cca177a48544/mockup.gif)
Thoughts?https://lab.civicrm.org/dev/core/-/issues/1307Add tracking table for import jobs2022-06-10T09:06:03ZeileenAdd tracking table for import jobsA current blocker to refactoring the import jobs to use queue processes / non-timeout UI methods is persistence of output data.
We discussed this in Barcelona and came up with the following proposal
1) create a new table civicrm_user_j...A current blocker to refactoring the import jobs to use queue processes / non-timeout UI methods is persistence of output data.
We discussed this in Barcelona and came up with the following proposal
1) create a new table civicrm_user_job with the fields
- contact_id (or created_id?)
- job_identifier (or name?) - we probably would need this to be unique but the BAO could handle appending to it if it is not.
- start_timestamp
- end_timestamp
- job_hash - used for file naming
2) files created as a result of the job could have a standard naming convention - e.g
import_{job_hash}_validation_errors.csv
import_{job_hash}_duplicates.csv
3) We would need a cleanup job which would also remove the files - e.g more than one week old
4) The UserJob BAO would obviously run pre & post hooks - allowing tracking by extensions
5) Permissioning of file retrieval can be via Attachment api - Tim thinks we know how that works but he is wrong.
6) When viewing the results of the import this creates options for us to potentially present a user with their imports (plural) results & for them to choose which they want. (Perhaps exposing the job_idenfier field to them would help here?
@totten @pfigel @seamuslee5.51.0https://lab.civicrm.org/dev/core/-/issues/1172Mapping field schema inadequate2022-11-30T08:21:42ZeileenMapping field schema inadequateI've been digging into the import code in the hope of applying a similar combination of Iterate by Month & Leap by Extension as we have recently done for export.
In the course of the export UI work we established that if we separated th...I've been digging into the import code in the hope of applying a similar combination of Iterate by Month & Leap by Extension as we have recently done for export.
In the course of the export UI work we established that if we separated the building of the mapping out from the rest of the code then the form & the work engine only had to agree on that format to be upgraded separately. For export the format was pretty straight forward -ie. use the schema / api for MappingField & Mapping.
For import I've discovered a few issues with how the Mapping Fields currently store the import mappings
1) Labels - unlike the export fields, which sensibly store field names, the Import schema stores the field label into the 'name' field (obviously any renaming breaks it)
2) Soft credits = arg. The field mappings store this in the sort of way Cinderella's sisters got that slipper on... In the 'name' / label field the word 'Soft Credit' is stored. In the 'contact_type' field the identifier is stored (ie. contact_id, external_identifier, email). The 'soft credit type' can be configured via the UI but per https://lab.civicrm.org/dev/core/issues/654 is never saved...
I think it would be good to agree if mapping_field is the right place to store mappings - I'm inclined to think it is - but if so we probably want to extend the schema to support soft credits - probably in a slightly more generic way than just adding 'soft_credit_identifier' & 'soft_credit_type_id'...
It's worth also noting some of the things the current import DOES do for a user since the temptation to just replace it wholesale (which I don't think removes the 'how do we map' question) needs to be balanced against what it needs to do
- allows a range of date formats in import csv
- allows importing to a range of related contacts fields
- allows importing soft credits with a range of match criteria
- supports varied match criteria - eg. external_identifier, email, contact_id & for contribution trxn_id, invoice_reference
- provides a range of dedupe options & rule
- provides a range of matching - e.g matches to labels, values, state abbreviations
Does not
- allow you to choose whether 'empty' overwrites or is ignored
- allow you to specify a column value (ie. for everything in this import I want the source to be 'my import 2019' - potentially only if blank or for all fields). This can be done in the csv but ... users.https://lab.civicrm.org/dev/core/-/issues/1160Events with templates but no custom field values don't save custom fields2021-04-07T01:44:01ZJonGoldEvents with templates but no custom field values don't save custom fieldsThis is closely related to core#553, but the fix for #553 doesn't solve this.
In core#553, if you have an event template that DOES specify values for custom fields, they don't get copied to a new event.
In this case, if you have an eve...This is closely related to core#553, but the fix for #553 doesn't solve this.
In core#553, if you have an event template that DOES specify values for custom fields, they don't get copied to a new event.
In this case, if you have an event template that does NOT specify values for custom fields, then any values you enter for custom fields are ignored.
This is true both with and without [PR #14063](https://github.com/civicrm/civicrm-core/pull/14063) so it's not an unreleased regression.