Development issues
https://lab.civicrm.org/groups/dev/-/issues
2023-09-02T01:47:32Z
https://lab.civicrm.org/dev/core/-/issues/4444
Multilingual problem with required title fields
2023-09-02T01:47:32Z
eileen
Multilingual problem with required title fields
We recently made `contribution_page.title` and some similar fields required. However, I just discovered that `testGitLabIssue1108` fails locally and the reason feels like it has implications
The test fails because when multilingual is d...
We recently made `contribution_page.title` and some similar fields required. However, I just discovered that `testGitLabIssue1108` fails locally and the reason feels like it has implications
The test fails because when multilingual is disabled it does an INSERT for en_US but the value for fr_FR is not set - which fails due to the change making title_fr_FR required.
I don't know why this didn't surface before but I suspect we need to make required fields of type text have different sql attributes - ie probably a default of ''
5.66.0
https://lab.civicrm.org/dev/core/-/issues/3049
Auto-complete option values aren't available to anonymous users
2023-09-02T01:04:32Z
JonGold
Auto-complete option values aren't available to anonymous users
Overview
----------------------------------------
A custom field of input type "Autocomplete-Select" doesn't return results for anonymous users, even with the "Access AJAX API" permission granted.
Reproduction steps
--------------------...
Overview
----------------------------------------
A custom field of input type "Autocomplete-Select" doesn't return results for anonymous users, even with the "Access AJAX API" permission granted.
Reproduction steps
----------------------------------------
1. Change an existing field (e.g. "Soup Selection") from **Dropdown** to **Autocomplete-Select**.
1. Add the field to a profile on a public-facing event page.
1. Grant the anonymous user the **Access AJAX API** permission.
1. View as an anonymous user.
Current behaviour
----------------------------------------
No results are returned.
Expected behaviour
----------------------------------------
Results are returned, as they are with a "Dropdown" input type.
Comments
----------------------------------------
The error is that anonymous users don't have access to the "Optionvalue.getlist" API because it requires "Access CiviCRM". This seems like the wrong permission; I think "Access AJAX API" should be sufficient. From a UX perspective, it's pretty inconsistent that a Select works but not an Autocomplete-Select.
I'm proposing that we allow anonymous users to access OptionValue.get - I'm interested in whether there are use cases where this results in an information disclosure vulnerability. I can't think of any myself.
https://lab.civicrm.org/dev/core/-/issues/4370
Group opt in and subscribe/unsubscribe in form builder
2023-09-01T19:44:08Z
Michael McAndrew
Group 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/2572
Prevent unintentional removal from group for anonymous users filing out profiles
2023-09-01T19:44:06Z
larsssandergreen
Prevent unintentional removal from group for anonymous users filing out profiles
Currently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, ...
Currently, if an anonymous contact submits a profile that contains a groups field and the profile submission is deduped on submission with an existing contact, the group selections in the profile overwrite the contact's previous groups, for the groups that are included in the profile (i.e. the public groups). The result is that if someone is subscribed to a mailing list and fills in a profile anonymously and doesn't check the same group name, they will be unsubscribed from the group. This is definitely not what users expect! I think it's clear that checking the box will add you to the group, but I doubt many expect that they will be removed from a group if they don't check the box that they've checked in the past.
This is also not what happens with other profile fields that are left blank, nor is it what happens if two contacts are merged manually.
I propose to ignore group checkboxes that are not checked in a profile submitted anonymously. No change for profiles submitted with known cids (as these will have the appropriate checkboxes already checked, allowing the contact to unsubscribe by unchecking them if desired). Currently, all group ids in the profile are being [passed here](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Contact/BAO/GroupContact.php#L534), removing the contact from groups that were unchecked. Will submit PR if supported.
EDIT: Here is some discussion on StackExchange: [Unwanted unsubscribe in profile](https://civicrm.stackexchange.com/questions/39403/unwanted-unsubscribe-in-profile/39406), [Anonymous user filing out a profile unintentionally remove themselves from groups](https://civicrm.stackexchange.com/questions/29337/anonymous-user-filing-out-a-profile-unintentionally-remove-themselves-from-group)
https://lab.civicrm.org/dev/core/-/issues/4442
Add action to convert smart group to regular group
2023-08-31T16:33:25Z
yashodha
Add action to convert smart group to regular group
There are cases when smart groups have actually run their course. The list is not going to change after a while so no need keeping the group smart esp when the criteria is quite complex and increases the load time. The idea here is keep ...
There are cases when smart groups have actually run their course. The list is not going to change after a while so no need keeping the group smart esp when the criteria is quite complex and increases the load time. The idea here is keep only those groups that are needed as smart/dynamic so that it prevents unnecessary process of re-calculating the groups that just shouldn't be if deletion of the group is not an option.
In such cases, provide the ability to convert smart group to regular group.
Proposal : Provide action link for smart groups to convert to regular group.
- refresh the smart group
- move from the group contact cache to group contacts
- unset the saved search on the group
yashodha
yashodha
https://lab.civicrm.org/dev/core/-/issues/444
Updated alterReportVars or new hook for reports
2023-08-31T08:51:04Z
JoeMurray
Updated alterReportVars or new hook for reports
There is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report....
There is no way to currently change a core report to get it to expose custom fields for a component if it does not do it already. It's not unusual an unusual use case to combine creating a custom field with exposing it in a core report. What's needed is to be able to use a hook to add values to $_customGroupExtends. This would also allow extensions to define their own custom fields and add them to a report.
The alterReportVar hook is one place where this functionality could be added https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_alterReportVar/. The current three supported varTypes, columns, rows and sql, could be extended by a new one, customFields, or some similar name.
There has been criticism in the past of this hook. IIRC @eileen the concern was especially around how it was not well designed for the sql argument, but I don't recall the details. Perhaps it was that the hook was trying to do too many things and provided too broad a surface.
Rather than further complexifying this hook, an alternative approach would be to create a new one focussed exclusively on the issue of changing custom field exposed by a report. Perhaps it could be call alterReportCustomFields.
So we'd like feedback on
1. Should there be hook support for changing the custom fields exposed by reports?
2. If so, should we change alterReportVar or create a new hook, alterReportCustomFields?
https://lab.civicrm.org/dev/core/-/issues/2690
Print mailing label doesn't work with the same address
2023-08-31T05:03:27Z
Monish Deb
Print mailing label doesn't work with the same address
Steps to replicate:
1. Choose one or more contacts on Advance Search which has same address
2. Then select action: 'Print - Mailing Label'
3. Select all the three options and then click on 'Make Mailing Labels':
Demo:
![before](/upl...
Steps to replicate:
1. Choose one or more contacts on Advance Search which has same address
2. Then select action: 'Print - Mailing Label'
3. Select all the three options and then click on 'Make Mailing Labels':
Demo:
![before](/uploads/ae7a772e2f85d5d23c8d8bf62cd26ed8/before.gif)
Here I have chosen two contact with same address. And mailing labels show the contact twice, one with name and other without name - [MailingLabels_CiviCRM__28_.pdf](/uploads/13d3f95541eb7ce9f34d71f8cf01f4d9/MailingLabels_CiviCRM__28_.pdf)
5.41.0
Monish Deb
Monish Deb
https://lab.civicrm.org/dev/core/-/issues/2686
Mailings with no text in HTML body are sent empty
2023-08-31T05:03:27Z
sluc23
Mailings with no text in HTML body are sent empty
There's an issue when an Individual Email or Scheduled Reminders are sent with a Html Body that does not contain any text, no matter the HTML tags in the source, the email is sent with an empty body.
This type of HTML body is common sp...
There's an issue when an Individual Email or Scheduled Reminders are sent with a Html Body that does not contain any text, no matter the HTML tags in the source, the email is sent with an empty body.
This type of HTML body is common specially in Scheduled reminders where only a generic `<img>` tag is included in the body (for Anniversaries, Birthdays, etc..), the user will receive an empty email.
The culprit is this line: https://github.com/civicrm/civicrm-core/blob/5.39.0/CRM/Utils/Mail.php#L191
Which trims the HTML body if it does not contain any text, rather than html tags.
This does not reproduce in CiviMailings, because it's mandatory to include optOut links, so at least they have some text
https://lab.civicrm.org/dev/core/-/issues/3676
Replace packages/html2txt with Composer package
2023-08-31T03:38:35Z
JonGold
Replace packages/html2txt with Composer package
There is a [html2txt package](https://packagist.org/packages/html2text/html2text) on Packagist, which is an updated version of the same class we have in the `packages` repo, but updated for PHP8, includes tests, and assumes UTF-8 encodin...
There is a [html2txt package](https://packagist.org/packages/html2text/html2text) on Packagist, which is an updated version of the same class we have in the `packages` repo, but updated for PHP8, includes tests, and assumes UTF-8 encoding is available in mail clients (e.g not changing `©` to `(c)`). It also handles some less usual cases that the current class doesn't.
If we don't do this, we would at least want to pull in the [updated class from Roundcube](https://github.com/roundcube/roundcubemail/blob/master/program/lib/Roundcube/rcube_html2text.php).
5.52.0
https://lab.civicrm.org/dev/core/-/issues/4441
Error "There might be a data problem, contribution id could not be loaded fro...
2023-08-31T03:17:17Z
DaveD
Error "There might be a data problem, contribution id could not be loaded from the line item"
I've been seeing this the last two days or so on event registrations. Not sure yet what it's from but it's something new. Easy to reproduce:
1. Events - Register Event Participant.
2. Pick a contact.
3. Pick an event.
4. Click save.
Se...
I've been seeing this the last two days or so on event registrations. Not sure yet what it's from but it's something new. Easy to reproduce:
1. Events - Register Event Participant.
2. Pick a contact.
3. Pick an event.
4. Click save.
Seems to be in 5.64 but not 5.63.
5.64.0
https://lab.civicrm.org/dev/core/-/issues/4134
SearchKit: Add TIMESTAMPDIFF to calculate between two dates in years, months,...
2023-08-30T15:49:10Z
francescbassas
SearchKit: Add TIMESTAMPDIFF to calculate between two dates in years, months, weeks, etc.
Overview
----------------------------------------
Allow to calculate number of days, weeks, months, years, etc. between two dates.
[DATEDIFF](https://github.com/civicrm/civicrm-core/pull/24875) only allows to calculate difference betwee...
Overview
----------------------------------------
Allow to calculate number of days, weeks, months, years, etc. between two dates.
[DATEDIFF](https://github.com/civicrm/civicrm-core/pull/24875) only allows to calculate difference between two days in days. Instead, TIMESTAMPDIFF allows set the unit (years, months, weeks, etc.) units in which you want to get the difference between two dates.
Eg. to calculate age of a contact at the time they registered for an event between contact birthday and registration event date.
Current behaviour
----------------------------------------
Can't calculate years between two dates.
![datediff](/uploads/b7a37ccd3a0c048750934fadc5cf5763/imatge.png)
Proposed behaviour
----------------------------------------
Can calculate years (and FRAC_SECOND (microseconds), SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, QUARTER) between two dates.
![timestampdiff1](/uploads/6dcc9610fd2fc195d2157007f3b71fba/Captura_de_pantalla_de_2023-02-17_09-36-56.png)
![timestampdiff2](/uploads/b6e7b2822f7a55eee279ea251536f913/imatge.png)
Comments
----------------------------------------
TIMESTAMPDIFF can in principle reproduce the same behavior as DATEDIFF. If so, current _Days between two dates_ field transformation could be replaced with _Diff between two dates_ ensuring that it continues to work for old cases.
https://lab.civicrm.org/dev/translation/-/issues/83
No translation for "sections" in "New <contact>"
2023-08-30T12:57:17Z
thoni56
No translation for "sections" in "New <contact>"
When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmav...
When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmavbild_2023-08-11_kl._13.38.33](/uploads/effa60ca9aa352a2d735ddfe89bb8d79/Skärmavbild_2023-08-11_kl._13.38.33.png)
I'm contributing to the Swedish translation so I know that the strings are translated in Transifex ;-). I have `uplang` installed and it seems to update other translations (although I would love a way to explicitly trigger the download, see https://lab.civicrm.org/extensions/uplang/-/issues/2).
https://lab.civicrm.org/dev/core/-/issues/2683
Apiv4 ContributionProduct - add pseudoconstant for product option
2023-08-30T05:03:26Z
eileen
Apiv4 ContributionProduct - add pseudoconstant for product option
Product option needs some extra metadata
- this appears to be from the product table & somewhat nasty - see ``getPremiumProductInfo``
```
<field>
<name>product_option</name>
<title>Product Option</title>
<type>varchar</typ...
Product option needs some extra metadata
- this appears to be from the product table & somewhat nasty - see ``getPremiumProductInfo``
```
<field>
<name>product_option</name>
<title>Product Option</title>
<type>varchar</type>
<length>255</length>
<export>true</export>
<comment>Option value selected if applicable - e.g. color, size etc.</comment>
<add>1.4</add>
</field>
```
https://lab.civicrm.org/dev/core/-/issues/2115
Move financialACLs to a core extension
2023-08-30T05:03:25Z
eileen
Move financialACLs to a core extension
This work has already started with the code being moved from LineItem api to a pre hook in the hidden ext/financialacls extension.
The definition of done is:
1) we find all places that refer to isACLFinancialTypeStatus & find a way to m...
This work has already started with the code being moved from LineItem api to a pre hook in the hidden ext/financialacls extension.
The definition of done is:
1) we find all places that refer to isACLFinancialTypeStatus & find a way to move them over
2) at that point it should be possible to unhide the extension and allow people to enable it only if they want it
3) we would reconcile it with the extension outside of core & consolidate
@monish.deb @JoeMurray @seamuslee this is really just creating a GL for what we have already discussed. Since it's membership-theme-month I'm gonna take a look at the bits of this as relate to membership
https://lab.civicrm.org/dev/core/-/issues/4378
Schema support for rounding
2023-08-30T04:05:32Z
eileen
Schema support for rounding
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 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 above
https://lab.civicrm.org/dev/core/-/issues/4541
Membership renewal on Feb 29 of a leap year is calculated incorrectly
2023-08-29T19:23:09Z
larsssandergreen
Membership renewal on Feb 29 of a leap year is calculated incorrectly
Or it doesn't match what the test expects, anyways.
Basically, the [membership renewal here](https://github.com/civicrm/civicrm-core/blob/bb49a5de4a1630e57e91e3618c370bc075a793b5/CRM/Member/BAO/MembershipType.php#L524) in CRM_Member_BAO...
Or it doesn't match what the test expects, anyways.
Basically, the [membership renewal here](https://github.com/civicrm/civicrm-core/blob/bb49a5de4a1630e57e91e3618c370bc075a793b5/CRM/Member/BAO/MembershipType.php#L524) in CRM_Member_BAO_MembershipType::getRenewalDatesForMembershipType() will renew a membership that expires on Feb 29 for one year and set the new expiry date to Feb 28. But the [test here](https://github.com/civicrm/civicrm-core/blob/bb49a5de4a1630e57e91e3618c370bc075a793b5/tests/phpunit/CRM/Member/BAO/MembershipTest.php#L518) in CRM_Member_BAO_MembershipTest::testRenewMembership() thinks the membership should expire on Mar 1, which is actually more reasonable.
The problem is the kind of funky add one day and then subtract it later after adding a membership period logic, which doesn't make sense in this case as Feb 29 exists one year, but not the next.
https://lab.civicrm.org/dev/core/-/issues/4232
Improve FormBuilder handling of non logged in flows
2023-08-29T16:49:11Z
Michael McAndrew
Improve FormBuilder handling of non logged in flows
We've been working with a few clients on forms that should be available to the outside world / logged out users and want to suggest some improvements to Form Builder to cater to these scenarios.
They revolve around a couple of workflows...
We've been working with a few clients on forms that should be available to the outside world / logged out users and want to suggest some improvements to Form Builder to cater to these scenarios.
They revolve around a couple of workflows.
1. Require email confirmation **to view a form**.
2. Require email confirmation **to process a form**
We plan on adding an 'Anonymous users' setting to the FormBuilder settings to support this. It will be a select that allows people to choose between the above two options.
### Require email confirmation **to view a form**
We're using this to make a 'Communication preferences' form available to non logged in users 'on demand'.
When a non logged in user visits https://example.org/civicrm/communication-preferences, they will see an email field and a message along the lines of "Enter your email below and if your email exists in our system we will send you a link to the 'Communication preferences' page".
We only send an email if the email already exists in CiviCRM. If it does not, we silently ignore it. Clicking on the checksum link will authenticate them and send them back to the same form.
This is similar in nature to the traditional checksum workflow.
### Require email confirmation **to process a form**
We're using this, for example, to provide 'double opt in' functionality to newsletter sign up forms. And also to get users to confirm any changes to their email address.
It probably make sense to make this option configurable so it can be set
- for just logged out users
- for logged out users *and* logged in users if the email has changed
We think we can implement this by adding an early event listener that logs the submission, sends an email to the user asking them to confirm their email address (using the email submitted in the form) and stops the event propagation *before any entities are updated*.
If and when the person confirms their email by clicking a link in the email we restart the processing by dispatching the event again with the submitted data and update entities as necessary.
### More thoughts
Both these measures act as a form of spam protection. Unlike the current double opt in which creates a contact before the email is confirmed (with a pending subscription), in the Require email confirmation **to process a form** flow, no contact is created until the email is confirmed. This should result in less spam contacts ending up in CiviCRM.
Require email confirmation **to process a form** probably won't play nicely with file attachments out of the box (and we think that is OK for a v1).
Not sure if Require email confirmation **to process a form** would make sense on a form that is doing financial transactions but we're treating that as out of scope for now (seems fine since you can't use form builder to process transactions right now any way!)
Require email confirmation **to process a form** is a subset of a wider workflow which is require confirmation to process a form, e.g. confirmation from staff that an update to a member profile is acceptable before being published on a website.
If we're lucky, we might be able to implement all of this an an extension but at the same time, it feels quite core and would be up for adding it to core if preferred.
***Your thoughts and feedback how we can improve this proposal and any potential issues very welcome!***
Kurund Jalmi
Kurund Jalmi
https://lab.civicrm.org/dev/core/-/issues/4535
View Membership lists template contributions along with actual contribution u...
2023-08-29T10:36:47Z
Rich
View Membership lists template contributions along with actual contribution under "Related Contributions and Recurring Contributions"
This is confusing. The status column is blank, too, so it looks at a glance as though this is a real payment:
![image](/uploads/61a1120ef3c1f389c2dda90bb0bd38f5/image.png)
I propose that template contributions are NOT shown on that pag...
This is confusing. The status column is blank, too, so it looks at a glance as though this is a real payment:
![image](/uploads/61a1120ef3c1f389c2dda90bb0bd38f5/image.png)
I propose that template contributions are NOT shown on that page. Agree?
https://lab.civicrm.org/dev/core/-/issues/2678
The summary statistics look confusing when all are made in different dollars
2023-08-29T05:03:27Z
yashodha
The summary statistics look confusing when all are made in different dollars
These 3 amounts have different currencies (USD, AUD and CAD) which is why they can't be summed for the same criteria. But the display looks confusing as all the amounts are displayed as dollars and hard to tell which is which![currency](...
These 3 amounts have different currencies (USD, AUD and CAD) which is why they can't be summed for the same criteria. But the display looks confusing as all the amounts are displayed as dollars and hard to tell which is which![currency](/uploads/ef5eca0fed81edf34ed60e81189d3d5a/currency.png)
https://lab.civicrm.org/dev/core/-/issues/2672
CiviCase Case Type blank
2023-08-29T05:03:26Z
gcpower
CiviCase Case Type blank
Overview
----------------------------------------
_Please describe your problem or bug in detail._
I have a new local install. I enabled CiviCase and checked permissions - all OK. I installed CiviCase and attempted to add a new case ...
Overview
----------------------------------------
_Please describe your problem or bug in detail._
I have a new local install. I enabled CiviCase and checked permissions - all OK. I installed CiviCase and attempted to add a new case type and a blank screen was shown. It also froze any further activity. I deleted url up to civicrm and function restored. I flushed caches and ran rebuild.php still the same error.
Reproduction steps
----------------------------------------
1. Disable CiviCase
2. Flush caches
3. Enable CiviCase
4. Select Administer/CiviCase/Case Type
5. Blank screen and following url shown http://localhost:8891/drupal_8/web/civicrm/a#
6. System freezes and /a# removed
7. System restored
Current behaviour
----------------------------------------
No error messages shown on Drupal log file, but in Develop on Safari 404 shown when accessing CiviCRM /drupal_8/web/libraries/civicrm/core//bower_components/dc-2.1.x/dc.min.js.map```
Three 404 errors displayed when accessing Case type
/drupal_8/web/libraries/civicrm/core/bower_components/angular-file-upload/angular-file-upload.min.map```
/drupal_8/web/libraries/civicrm/core/bower_components/angular-sanitize/angular-sanitize.min.js.map```
/drupal_8/web/libraries/civicrm/core/bower_components/angular-route/angular-route.min.js.map```
```
Expected behaviour
----------------------------------------
_What should happen._
When accessing Case Types, I expect the two existing types to be displayed and an add new option is available to add more types
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. -->
* __Browser:__ _Safari 14.1.1
* __CiviCRM:__ _Master/5.38.0 <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.3.24__
* __CMS:__ _Drupal 8.9.16_
* __Database:__ _MySQL 5.7.32_
* __Web Server:__ _Apache 2.4.46/Nginx 2.7.13/..._
Comments
----------------------------------------
_Anything else you would like the reviewer to note._