CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-06T06:36:35Zhttps://lab.civicrm.org/dev/core/-/issues/4404Possibility to reuse the list of languages available for "Preferred language"2023-07-06T06:36:35ZquimgilPossibility to reuse the list of languages available for "Preferred language"Overview
----------------------------------------
Out of the box, CiviCRM comes with a full list of languages used for the field "Preferred language". Right now, there is no way to reuse this list in custom fields. Admins must create the...Overview
----------------------------------------
Out of the box, CiviCRM comes with a full list of languages used for the field "Preferred language". Right now, there is no way to reuse this list in custom fields. Admins must create their own list of languages manually or use different unsupported approaches to reuse the one CiviCRM already has.
Example use-case
----------------------------------------
An international organization working with volunteers wants to know in which languages they have basic, advanced, and native/professional fluency, in separate questions.
Current behaviour
----------------------------------------
The list of languages available in CiviCRM's database cannot be reused for custom fields.
Proposed behaviour
----------------------------------------
Make the "Preferred language" list of languages available to custom fields, just like you can create any list that is then available to other custom fields.
Comments
----------------------------------------
See examples of ad hoc solutions admins are recurring to on https://civicrm.stackexchange.com/questions/6604/how-to-reuse-preferred-language-selecthttps://lab.civicrm.org/dev/core/-/issues/4403SK / API 4 Explorer: event_queue_id, job id, bounce id, etc autocompletes don...2023-07-05T04:30:05ZlarsssandergreenSK / API 4 Explorer: event_queue_id, job id, bounce id, etc autocompletes don't workEdited as this issue is more general than I thought. Fairly minor issue, but:
In SK or API 4 Explorer, for mailing event id fields (event queue id, job id, bounce id, etc), the autocomplete fields don't work. No matter what you input, i...Edited as this issue is more general than I thought. Fairly minor issue, but:
In SK or API 4 Explorer, for mailing event id fields (event queue id, job id, bounce id, etc), the autocomplete fields don't work. No matter what you input, it shows `Loading failed` and you can't make a selection.
To replicate: Choose MailingEventBounce or similar, Where event_queue_id and =.https://lab.civicrm.org/dev/core/-/issues/4402Change unsupervised Household dedupe rule to email only2023-07-06T23:20:28ZlarsssandergreenChange unsupervised Household dedupe rule to email onlyAs @DaveD [pointed out](https://github.com/civicrm/civicrm-core/pull/26673#issuecomment-1613302861), the default unsupervised Household dedupe rule that matches on name or email doesn't make a lot of sense. Presumably, you could easily h...As @DaveD [pointed out](https://github.com/civicrm/civicrm-core/pull/26673#issuecomment-1613302861), the default unsupervised Household dedupe rule that matches on name or email doesn't make a lot of sense. Presumably, you could easily have multiple households with the name "Jones family" or similar in whatever format you choose for household names. You wouldn't want these to be merged automatically.
I think the easiest and clearest solution is only to merge households with the same email, but then that won't help those without emails. We could do something like threshold 20, email 20, name 10, street address 10, phone 10, but I'm not sure we gain much from that. We can keep name or email as the supervised rule.https://lab.civicrm.org/dev/core/-/issues/4401SearchKit - Report replacement - as a standard user without edit searchkit pe...2023-07-06T06:37:04ZsamuelsovSearchKit - Report replacement - as a standard user without edit searchkit permission, add a way to show/hide columns in table displayThere is already an [extension](https://lab.civicrm.org/extensions/search_kit_reports) that recreate the queries of core reports into SearchKit so admin/super user can customize and use them instead of report.
However, as a standard use...There is already an [extension](https://lab.civicrm.org/extensions/search_kit_reports) that recreate the queries of core reports into SearchKit so admin/super user can customize and use them instead of report.
However, as a standard user, edit a Searchkit is too complicated and reports is still the better option if we need to provide a lot of flexibility to users.
Currently, in Reports, standard user have access to customize :
- Columns - no way to do this in SK without editing the SK - hence the proposal
- Sorting - already there by clicking on the columns of the SK table
- Filters - already there by configuring them with FormBuilder
- Title and Format - don't think it is required
- Email delivery - missing, already documented in https://lab.civicrm.org/dev/core/-/issues/3478
So I think the main undocumented missing feature if we want to replace the reports is to have a way for a standard user to choose which columns to show/hide in a table display. It needs to apply to the screen and to the Download action.
As an example, I like the way new reports in Quickbooks works with the ability to switch each column on/off and as a bonus allow to change columns order :
![Rapport](/uploads/550ef9e7d7ffd1f19849b4034faa7765/Rapport.png)
As a first step, I don't think we need to save the user preferences but we will probably want to be able to do that / reset to default eventually.https://lab.civicrm.org/dev/core/-/issues/4400Export of contacts when filtering on custom field exports all contacts in dat...2023-07-06T06:37:41ZtjhellmannExport of contacts when filtering on custom field exports all contacts in databaseOverview
----------------------------------------
When I filter contacts from Advanced Search and select a custom field to filter on, in the next screen, the correct list and number of records comes up. From there if I select All [number...Overview
----------------------------------------
When I filter contacts from Advanced Search and select a custom field to filter on, in the next screen, the correct list and number of records comes up. From there if I select All [number of records] records and select Export contacts, the next screen also shows the correct number of contacts from the previous screen. But when I click 'continue' to export the records, the export contains all the records in the database. This does not happen when the list is filtered for non custom fields.
Reproduction steps
----------------------------------------
1. Visit Advanced Search
1. Select a custom field value as search criteria and click search
1. See expected search results. Now click All Records and Export Contacts.
2. On the next screen see that the expected number of contacts say they will be in the export. Click continue and all the contacts in the database are in the exported file.
Environment information
----------------------------------------
* __CiviCRM:__ 5.62.1
* __PHP:__ 8.0.29
* __CMS:__ Drupal 9.5.9
* __Database:__ MySQL 5.7.39https://lab.civicrm.org/dev/core/-/issues/4399Unable to merge incomplete memberships due to missing end_date2023-07-06T06:38:24Zfreeform.stephUnable to merge incomplete memberships due to missing end_dateWhen a contribution fails when purchasing a membership, a membership remains (as either pending or cancelled) that does not have an end date. When merging contacts any memberships are expected to have an end date.
`"UPDATE civicrm_membe...When a contribution fails when purchasing a membership, a membership remains (as either pending or cancelled) that does not have an end date. When merging contacts any memberships are expected to have an end date.
`"UPDATE civicrm_membership SET end_date = '' WHERE id=ID [nativecode=1292 ** Incorrect date value: '' for column `civicrm`.`civicrm_membership`.`end_date` at row 1]"`https://lab.civicrm.org/dev/core/-/issues/4397What should the Name and Address reserved general Individual dedupe rule do?2023-06-30T00:14:21ZlarsssandergreenWhat should the Name and Address reserved general Individual dedupe rule do?We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image]...We have a reserved dedupe rule on new installs for Individuals called Name and Address.
What it actually does is matches contacts who have the same first name, last name and street address. What it claims to do is the following:
![image](/uploads/d427acb2b1c3ce07c994b68a2371ac62/image.png)
[This rule](https://github.com/civicrm/civicrm-core/blob/master/sql/civicrm_data/civicrm_dedupe_rule/IndividualGeneral.sqldata.php) also includes suffix_id and middle_name with weights of 1, which cannot influence the matches (threshold 15, all other items have weight 5), so these don't do anything.
There is a [hard-coded query](https://github.com/civicrm/civicrm-core/blob/master/CRM/Dedupe/BAO/QueryBuilder/IndividualGeneral.php) for this rule that should match up with the above (right now we are querying middle_name, suffix and birthdate for no reason, which is kind of ironic since this query claims to be optimized).
None of this has changed in at least ten years.
Personally, I don't think matching on first, last and street address is useful (as street addresses are often written slightly differently so are not that likely to match). Maybe we should just eliminate this reserved dedupe rule, since I can't see that it is used for anything. If not, maybe we should make it more useful by making it just first and last name. Or maybe there is some reason this is useful as is and we should simply make this all consistent so it just matches on first, last and address and nothing more.https://lab.civicrm.org/dev/core/-/issues/4395Token support to allow us to migrate sort_name, display_name, address formats...2023-06-28T07:10:08ZeileenToken support to allow us to migrate sort_name, display_name, address formats to tokensWe have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens...We have a goal to get sort_name, display_name and address formats to resolve using the standard token system, at the same time as the greetings are resolved.
Unfortunately there are some things they support at the moment that our tokens don't. Our tokens DO support the default filter
`{contact.first_name|default:"donor"}`
and they support the magic space - ie
`{contact.first_name}{ }{contact.last_name}`
which resolves a space in the above, but not if there is no last name.
However, in sort name there is a variant on the magic space we don't currently support in tokens - - ie
`{contact.last_name}{, }{contact.first_name}`
The regex that supports that actually removes the whole `{}` contents if the following tag is empty or renders the contents otherwise.
This is pretty hard to make compatible with smarty :-(, which is a requirement to standardise. So ideally we would
1) make the magic syntax support know usages (within reason) which so far are the magic space, the magic comma and this variant
`{contact.first_name}{ ~ }{contact.nick_name}{ ~ }{contact.last_name}`
2) add a system-check to highlight notify using variations of the magic syntax other than the 3 on our radar that they may not work in future upgrades if we don't add support & direct them to this ticket to comment & explain the use case
3) depending on the variations that come out of 2 add 'micro-conditional support'
Note micro-conditionals was an idea @totten came up with when we were spit-balling this - I've pasted his thoughts below
---------------------------------------------------------------------------------------------------------------------
micro-conditionals: special tokens that conditionally display a handful of symbols
```
---------
{contact.first_name} {contact.last_name} { ~ } {contact.nick_name}
{contact.last_name}{ }{contact.first_name}
{contact.last_name}{, }{contact.first_name}
{contact.first_name}{ (}{contact.nick_name}{) }{contact.last_name}
Dear {contact.first_name}{?friend},
----------
{contact.first_name contact.last_name " ~ " contact.nick_name}
{contact.last_name " " contact.first_name}
{contact.last_name ", " contact.first_name}
{contact.first_name " (" contact.nick_name ") " contact.last_name}
Dear {contact.first_name ?friend},
----------
{{{contact.first_name contact.last_name ~ contact.nick_name}}}
{{{contact.last_name contact.first_name}}}
{{{contact.last_name, contact.first_name}}}
{{{contact.first_name (contact.nick_name) contact.last_name}}}
Dear {{{contact.first_name??"friend"}}},
-------------
```
Also note - first draft of appropriate test https://github.com/civicrm/civicrm-core/pull/26637/files#diff-a5d237ba4e392d0e8ad764a535315f0b1101cc5ca61c39b4e572de42f5c6b4bchttps://lab.civicrm.org/dev/core/-/issues/4389Can't import using contact id2023-08-03T12:40:09Zaydunsaidan.saunders@squiffle.ukCan't import using contact idOverview
----------------------------------------
`Contact id` cannot be selected as a field to match on when importing.
(I'm fairly certain this used to work, but don't know when it stopped.)
Reproduction steps
-----------------------...Overview
----------------------------------------
`Contact id` cannot be selected as a field to match on when importing.
(I'm fairly certain this used to work, but don't know when it stopped.)
Reproduction steps
----------------------------------------
1. Click on **Contacts -> Import Contacts**.
1. Upload a CSV with a 'contact id' column
1. Note that there is no option to select 'Contact ID' in the field mapping options.
Current behaviour
----------------------------------------
Can't match to existing contact using contact id.
Expected behaviour
----------------------------------------
Can match to existing contact using contact id.
Environment information
----------------------------------------
* __CiviCRM:__ master_ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
Comments
----------------------------------------https://lab.civicrm.org/dev/core/-/issues/4388Order of constructor params for QuickForms2023-07-11T16:25:57Zluke.stewartOrder of constructor params for QuickFormsThere is a bit of chaos in param order here as encounted on related issue - is this something that we should be concerned about in this point of the lifecycle using Quickforms? Maybe if it's not broken we shouldn't fix?
Below list is a...There is a bit of chaos in param order here as encounted on related issue - is this something that we should be concerned about in this point of the lifecycle using Quickforms? Maybe if it's not broken we shouldn't fix?
Below list is a result of grep and then manual copy and paste and spacing to try and match up like orderings.
```
xbutton.php: function __construct($elementName = null, $elementContent = null, $attributes = null)
advmultiselect.php: function __construct($elementName = null, $elementLabel = null,
element.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
file.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
input.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
password.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
textarea.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
text.php: function __construct($elementName=null, $elementLabel=null, $attributes=null)
hiddenselect.php:function __construct($elementName=null, $elementLabel=null, $options=null, $attributes=null)
select.php: function __construct($elementName=null, $elementLabel=null, $options=null, $attributes=null)
autocomplete.php:function __construct($elementName=null, $elementLabel=null, $options=null, $attributes=null)
date.php: function __construct($elementName=null, $elementLabel=null, $options=array(), $attributes=null)
hierselect.php: function __construct($elementName=null, $elementLabel=null, $attributes=null, $separator=null)
static.php: function __construct($elementName=null, $elementLabel=null, $text=null)
checkbox.php: function __construct($elementName=null, $elementLabel=null, $text='', $attributes=null)
advcheckbox.php: function __construct($elementName=null, $elementLabel=null, $text=null, $attributes=null, $values=null)
radio.php: function __construct($elementName=null, $elementLabel=null, $text=null, $value=null, $attributes=null)
button.php: function __construct($elementName=null, $value=null, $attributes=null)
reset.php: function __construct($elementName=null, $value=null, $attributes=null)
submit.php: function __construct($elementName=null, $value=null, $attributes=null)
link.php: function __construct($elementName=null, $elementLabel=null, $href=null, $text=null, $attributes=null)
group.php: function __construct($elementName=null, $elementLabel=null, $elements=null, $separator=null, $appendName = true, $attributes = null)
image.php: function __construct($elementName=null, $src='', $attributes=null)
header.php: function __construct($elementName=null, $text = null)
hidden.php: function __construct($elementName=null, $value='', $attributes=null)
Page.php: function __construct($formName, $method = 'post', $target = '', $attributes = null)
Controller.php: function __construct($name, $modal = true)
html.php: function __construct($text = null)
```https://lab.civicrm.org/dev/core/-/issues/4386Contact tags don't work when triggered using the CiviRules action on Contact ...2023-06-20T13:49:44Zhitesh_compucorpContact tags don't work when triggered using the CiviRules action on Contact formOverview
----------------------------------------
When using the CiviRules extension there is an issue where adding tags to a contact does not work as expected while adding new contact using contact form. The problem arises when a rule ...Overview
----------------------------------------
When using the CiviRules extension there is an issue where adding tags to a contact does not work as expected while adding new contact using contact form. The problem arises when a rule is triggered for `Add Tag to Contact` action, causing it to remove any tags added by CiviRules before saving the contact form.
Reproduction steps
----------------------------------------
1. Create new CiviRules having Trigger as `Contact of any type is added` and Action as `Add Tag to Contact`
1. Create new contact
1. Contact tags configured by Civirules gets removed once the form is saved.
![issue_civirules](/uploads/8dcb8cc83041c41d1a2b7c48ac2df4b2/issue_civirules.gif)
Current behaviour
----------------------------------------
Tags configured from Civirules gets removed while saving contact form.
Expected behaviour
----------------------------------------
Civirules Tags shouldn't get deleted once we add new contact using contact form.
Environment information
----------------------------------------
* __CiviCRM:__ Master
* __CMS:__ Drupal 7.30
PR - https://github.com/civicrm/civicrm-core/pull/26580https://lab.civicrm.org/dev/core/-/issues/4385version=4 is not passed to Mailing.create on APIv4 so MailingJob gets scheduled2023-09-13T01:30:02ZSandor Semseyversion=4 is not passed to Mailing.create on APIv4 so MailingJob gets scheduledOverview
----------------------------------------
I'd like to create a single Mailing entity through APIv4 without scheduling a MailingJob and calculating recipients.
Reproduction steps
----------------------------------------
1. Call M...Overview
----------------------------------------
I'd like to create a single Mailing entity through APIv4 without scheduling a MailingJob and calculating recipients.
Reproduction steps
----------------------------------------
1. Call Mailing.create through API Explorer or `cv`
1. Notice that a MailingJob is created
Current behaviour
----------------------------------------
According to https://github.com/civicrm/civicrm-core/blob/94b9b95547d3f8292740c059f77f83cc45e57b57/CRM/Mailing/BAO/Mailing.php#L1622-L1629 this shouldn't happen by default, but it does: `$params['version']` is empty and `self::doSubmitActions()` is called.
Expected behaviour
----------------------------------------
`$params['version']` is populated so `CRM_Mailing_BAO_Mailing::doSubmitActions()` doesn't fire.
Comments
----------------------------------------
This is similar to https://github.com/civicrm/civicrm-core/blob/94b9b95547d3f8292740c059f77f83cc45e57b57/CRM/Member/BAO/Membership.php#L334-L343. In that case `Civi\Api4\Service\Spec\Provider\MembershipCreationSpecProvider` injects `version` parameter into the API call, but for Mailing such spec provider doesn't exists.
I can do some work with this, I'm just not sure if that spec provider is missing by design or not...
Also I can pass in `version=4` explicitly or use `_skip_evil_bao_auto_schedule_` and `_skip_evil_bao_auto_recipients_` to prevent submit actions to happen.https://lab.civicrm.org/dev/core/-/issues/4381CiviReport: default orientation for pdf output2023-06-22T08:23:40ZJanecCiviReport: default orientation for pdf outputOverview
----------------------------------------
I was unable to set the orientation for pdf output of reports.
Example use-case
----------------------------------------
1. Configure a PDF output format in settings
1. Use the "print PD...Overview
----------------------------------------
I was unable to set the orientation for pdf output of reports.
Example use-case
----------------------------------------
1. Configure a PDF output format in settings
1. Use the "print PDF letter"-action
Current behaviour
----------------------------------------
You PDF-report will be in landscape
Proposed behaviour
----------------------------------------
Use the configured setting.
Comments
----------------------------------------
Removing the hard coded value solves thishttps://lab.civicrm.org/dev/core/-/issues/4380js error on demo site2023-06-20T13:17:10Zeileenjs error on demo sitejs error on demo site
https://dmaster.demo.civicrm.org/civicrm/event/manage/fee?reset=1&action=update&id=1&selectedChild=registration#/volunteer/manage/0
![image](/uploads/d878eff48bc6312add6a8b929166a60c/image.png)
@colemanw I know y...js error on demo site
https://dmaster.demo.civicrm.org/civicrm/event/manage/fee?reset=1&action=update&id=1&selectedChild=registration#/volunteer/manage/0
![image](/uploads/d878eff48bc6312add6a8b929166a60c/image.png)
@colemanw I know you have suggested civi-volunteer remove the angular profiles & they have said 'can you give us some pointers' - this is a bit problematic as it is on our demo sitehttps://lab.civicrm.org/dev/core/-/issues/4379Preview support for event online template2023-06-20T13:20:13ZeileenPreview support for event online templateWe have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates...We have preview support for the event offline template - but it doesn't cover additional participants - focussing for now on the line items I'm documenting what to expect
1) We will assign the same variables as other financial templates (taxRateBreakdown, lineItems)
2) I think we should also assign a participant specific version of the above & then toggle whether to show all or not based on whether the participant is primary.
I'm gonna add screen shots to what happens now during an online flow because I know there are existing inconsistencies and that is considered correct
Also refer https://github.com/civicrm/civicrm-core/pull/23098 for thoughts about 'right behaviour' and
https://lab.civicrm.org/dev/core/-/issues/224https://lab.civicrm.org/dev/core/-/issues/4378Schema support for rounding2023-08-30T04:05:32ZeileenSchema support for roundingWe have an ongoing issue with rounding which I essentially believe is because our schema does not adequately support the variations on rounding in use, and I think we need to add additional fields to support this. The principle I think w...We have an ongoing issue with rounding which I essentially believe is because our schema does not adequately support the variations on rounding in use, and I think we need to add additional fields to support this. The principle I think we need to work to is:
**Can we calculate the 'missing' values with the data we have, if not we need to store it not treat it as calculable**
Our exising code assumes that if you have 2 out of 3 of tax_amount, tax_rate and one of tax_inclusive or tax_exclusive you can calculate the third. However, if what you have stored is numbers with some rounding applied you actually can't reverse engineer them.
**Specific proposal**
I propose we add to the schema
- civicrm_contribution.total_amount_exclusive
- civicrm_line_item.line_total_inclusive
- civicrm_line_item.tax_rate (note this CAN be calculated from the price field value id but could change over time either because of legislative changes such as sales tax increases - it only ever increases - or configuration changes.)
- civicrm_price_field_value.amount_inclusive
These would be calculated, if not provided, at the point of save. v4 Order api and Form Builder & BAO layer would support more nuanced usage of these but I don't anticipate any immediate changes to existing contribution or configuration quick forms to accommodate these. Search kit would expose them.
There is a bit of a gotcha around not-exposing them & being able to edit them on forms - so it is likely the contribution edit form would need to be adjusted to avoid re-saving in a way that causes problems. Possibly we need to get the ability to edit amount off the main form & into a sub-form which incorporates line item editor - this is something we have talked about before.
**Current situation**
The variations of rounding approaches we have people reporting using are
1) start with tax inclusive
2) start with tax exclusive
e.g
|Version| Tax exclusive | tax rate | tax amount | tax inclusive|
|----|----|----|----|----|
|start from inclusive| 869.57 | 15% | 130.43 | 1000|
|start from exclusive| 869.57 | 15% | 130.44 | 1000.01|
3) Round each line item before totalling (I think we are doing this) - apply tax as a % of the rounded amount, round the tax on each line
3) Store each line item un-rounded - apply tax per line item & add up
4) Total and then round the sum of the line items - apply tax to the total as a %, the amount that does not fit the line items is a rounding line item ?
The relevant existing tables /fields are
civicrm_contribution
- total_amount (inclusive)
- tax_amount
~~ - non_deductible_amount~~
civicrm_line_item
- line_total (exclusive)
- tax_amount
~~ - non_deductible_amount~~
civicrm_price_field_value
- amount (exclusive)
~~ - non_deductible_amount~~
civicrm_financial_account
- tax_rate
**Related issues**
https://lab.civicrm.org/dev/core/-/issues/3714
https://lab.civicrm.org/dev/financial/-/issues/189
https://lab.civicrm.org/dev/financial/-/issues/52
**Other**
Api v4 contribution.get supports returning `tax_exclusive_amount` for the field proposed as total_amount_exclusive abovehttps://lab.civicrm.org/dev/core/-/issues/4371AdminUI: Find contact should follow the setting "Search Primary Details Only"2023-06-20T13:19:52ZsamuelsovAdminUI: Find contact should follow the setting "Search Primary Details Only"The new "Find Contacts" shipped with Admin UI search only for Primary Email but we should take he setting "Search Primary Details Only" into account the way it is without AdminUI :
![ksnip_20230616-141644](/uploads/9441fba97690e6df4bc88...The new "Find Contacts" shipped with Admin UI search only for Primary Email but we should take he setting "Search Primary Details Only" into account the way it is without AdminUI :
![ksnip_20230616-141644](/uploads/9441fba97690e6df4bc883613ac9eb27/ksnip_20230616-141644.png)samuelsovsamuelsovhttps://lab.civicrm.org/dev/core/-/issues/4370Group opt in and subscribe/unsubscribe in form builder2023-09-01T19:44:08ZMichael McAndrewGroup opt in and subscribe/unsubscribe in form builder# Group subscribe and unsubscribe in form builder
This issue is an attempt to add functionality to handle group subscribe and unsubscribe in form builder as per the roadmap https://lab.civicrm.org/dev/core/-/issues/3761.
## Scenarios
...# Group subscribe and unsubscribe in form builder
This issue is an attempt to add functionality to handle group subscribe and unsubscribe in form builder as per the roadmap https://lab.civicrm.org/dev/core/-/issues/3761.
## Scenarios
Here are a few scenarios that we'd like to cater for...
### Opt in only flow
This flow is useful to give people the option to opt in to a group as part of another flow, e.g. when I register for an event, I might want to opt into an events newsletter. Note: I don't typically want to opt *out* of such a newsletter in these situations, and an opt out is likey unexpected and undesirable.
Opt in flows are also useful to create newsletter sign ups that contain multiple groups/mailing lists that people can sign up for.
We render a checkbox and group name. When the checkbox is ticked, we add a contact to the group (this might be a no-op if they are already in the group). If the checkbox is not ticked, we do nothing (i.e. we do not unsubscribe anyone that is already subscribed to the group).
We render a separate component for each group that the contact wants to opt into (rather than a single component that contains all groups).
By default checkboxes are not ticked when the form is loaded. This aligns nicely for workflows (e.g. GDPR compliant workflows) where opting in should be a conscious decision. However, it should be possible to set the checkbox to be ticked by default if desired. This may be appropriate in certain situations, e.g. it would be reasonable to pre-check a 'Please send me members newsletter' checkbox in a membership form if you wanted most people to receive the members newsletter but also wanted to give the option to opt out.
## Subscribe and unsubscribe flow
This allows people to both add themselves and remove themselves from groups.
This is typically used in 'Manage my notifications/communication preferences' screens and similar. It allows people to see what groups they are currently subscribed to, and subscribe and unsubscribe from them as appropriate.
We render a separate UI element for each group that the contact wants to opt into. When the checkbox is ticked, we add a contact to the group (if they are not already in it). If the checkbox is not ticked, we remove them from the group (if they are already in it).
## Automatic subscribe / unsubscribe flow
Sometimes we might want to automatically sign someone up to a mailing list without presenting a checkbox to tick. For example...
![image](/uploads/e5774b8f0d319fa33cee79f471d7049b/image.png)
One solution in this situation would be to add a hidden and checked subscribe or opt in element. In the situation that submitting the form should unsubscribe you, adding an unchecked subscribe/unsubscribe component should do the trick.
## The data model and form processing
I'm not 100% sure what the mark up for this should look like. An email join looks like this:
```html
<fieldset af-fieldset="Individual1" class="af-container" af-title="Individual 1">
<afblock-name-individual></afblock-name-individual>
<div af-join="Email">
<af-field name="email" />
</div>
</fieldset>
```
But group subscriptions and un-subscriptions don't work quite the same way.
In terms of the API, I think that what we want to do can probably be achieved with something like the save api:
```php
$results = \Civi\Api4\GroupContact::save()
->addRecord([
'group_id' => 2,
'contact_id' => 203,
'status' => 'Added',
])
->setMatch([
'group_id',
'contact_id',
])
->execute();
```
But I think there are a few tweaks that we'd want to do, e.g. we ideally do not want to record a status=removed when submitting a form with an unsubscribe/subscribe if they were not in the group in the first place.
And I am not sure how the save api gets called in formbuilder.
In terms of what the html might look like, I am wondering if it makes sense to create some components that encapsulate some of the logic, so that it ends up looking like this.
```html
<fieldset af-fieldset="Individual1" class="af-container" af-title="Individual 1">
<afblock-name-individual></afblock-name-individual>
<af-group group_id="2" />
</fieldset>
```
It might make sense to add a mode property that could be set to control the display and behaviour, e.g. `<af-group group_id="2" mode='opt-in'/>`
- normal - opts in and out
- opt-in - only allows opting in
- auto-add - hidden and adds people on submission
- auto-remove - hidden and removes people on submission
And a default property for opt in workflows, e.g. <af-group group_id="2" mode='opt-in' default=true/>
The above component would be responsible for generating the checkbox and text and for generating appropriate values when the form is submitted.
I can't see a way of doing it with the existing components. I might be missing something conceptual but here is my attempt. It made me think that a new component would probably make things easier.
```html
<fieldset af-fieldset="Individual1" class="af-container" af-title="Individual 1">
<afblock-name-individual></afblock-name-individual>
<div af-join="GroupContact">
<af-field name="group_id" /> <?-- do we also need to join on group to get the name? -->
<af-field name="status" /> <?-- Would need to translate a checkbox to value?'Added':'Removed'? -->
</div>
</fieldset>
```
## Email confirmation
At the moment, double opt in is closely linked to subscribing to an email group. IIRC in the past we have used something like
```php
<?php
civicrm_api3('MailingEventSubscribe', 'create', ...);
```
But this has a few drawbacks, including having to confirm multiple email subscriptions for a single form. Since we are also working on https://lab.civicrm.org/dev/core/-/issues/4232, we think it probably makes sense to leverage that for any logged out forms which will require that an email needs to be confirmed before any form processing occurs.https://lab.civicrm.org/dev/core/-/issues/4368Changing repeating events crashes when there are events to be deleted/removed...2023-06-20T13:29:25ZRichChanging repeating events crashes when there are events to be deleted/removed from seriesI _think_ I've pinned this one down.
When you change the end-date for repeating events, it makes a list of the original repeats and will either delete them (if no participants) or remove them from the series.
The code here just plain l...I _think_ I've pinned this one down.
When you change the end-date for repeating events, it makes a list of the original repeats and will either delete them (if no participants) or remove them from the series.
The code here just plain looks wrong to me:
https://lab.civicrm.org/dev/core/-/blob/1edfed415fe687e7c7847df41497352b5fa96368/CRM/Core/Form/RecurringEntity.php#L408
It's doing a call like `call_user_func([$classname, $argument1])` which should surely be `call_user_func([$classname, $methodname], $argument1)`
In the execution, the helper class (`$classname` above) is `CRM_Event_DAO_Event", I have no idea what method should be called, and the `$argument1` is an array of IDs.
Commenting out that line seems to be ok, but I've no idea what it was supposed to do. This problem has been here for at least 8 years(!).https://lab.civicrm.org/dev/core/-/issues/4367Apiv4 Order api2023-12-02T04:28:01ZeileenApiv4 Order api
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'conta...
There is general agreement that the biggest issue with the v3 api is the confusing arrays it requires. My preference in fact is for a fairly non-standard Order api - ie
```
Order::create()
->setContributionParameters([
'contact_id' => 56,
'financial_type_id:name' => 'Donation',
])
->addLineItem([
'price_field_value_id:name' => 'student_rate',
'entity_id.role_id:name' => 'Attended',
'entity_id.contact_id' => 87,
'entity_id.event_id' => 6,
'entity_table' => 'civicrm_participant',
])
->execute();
```
On update we would have actions like `addLineItem`, `removeLineItem`
Obviously this starts to highlight a whole lot of issues
**1) at the contribution params level**
there are some parameters that we have long-standing discussions around - financial_type_id, receive_date, payment_instrument_id. I think we should probably not start with talking about those as we might never get any further
**2) line items**
- one specific thing I think we all agree on is that we don't want line items to have to belong to the same price set. There will be some fighting with the code to get there but it's probably an issue that lives outside the bike shed
- in the example above the entity_table is passed in. For memberships that can be inferred from the price_field_value_id, but for event participants there is nothing on the price field or price_field_value that declares something as being event related
- for line items we kinda want to require the minimum required info which varies a bit.... ie
**-- if we have only the line_total (in the line item or just the contribution.total_amount) we can assume**
- the price field id is the default contribution price field
- the quantity is 1
- the unit_price is the line_total
**-- if we have only the qty and the unit_price we can assume**
- the price field id is the default contribution price field
- the line_total is unit_price * qty
**-- if we have only the line_total and the entity_table, which is civicrm_membership we can assume**
- the price field id is the default membership field
**but we require one of membership_type_id or price_field_value_id, from which we can determine amounts **
**-- if we have only the price_field_value id we can assume**
- the amount & price field can be looked up from it. We can assume qty to be 1 unless provided
- We need some way of specifying relevant entity values. (I suspect this is where the rubber hits the brake pads in the bikeshedding process). In the above example I have leveraged `entity_id` in the way we do for other apiv4 related entities. The v3 order api had some ideas about entity parameters which didn't align with our specification that closely - I think they were effectively 'sub-participants' and if we want to add that it might be `'entity_id.registered_participants' => []` perhaps. It's also rather tempting to refer to use `participant_id` to stand in for `entity_id` when it reflects the line....
**3) the add payment.**
We currently chain this - I did include above in the first iteration of this but removed based on the discussion. The world won't end if we don't do that.