CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-09-24T16:09:28Zhttps://lab.civicrm.org/dev/core/-/issues/587Permissions on GroupContact API calls seem wrong2023-09-24T16:09:28ZJonGoldPermissions on GroupContact API calls seem wrongI got a support request from a user who didn't have "Edit All Contacts" permissions stating that they couldn't remove someone from a group. Sure enough, [edit all contacts](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/Permissio...I got a support request from a user who didn't have "Edit All Contacts" permissions stating that they couldn't remove someone from a group. Sure enough, [edit all contacts](https://lab.civicrm.org/dev/core/blob/master/CRM/Core/Permission.php#L1229) is the necessary permission. However, editing/removing tags just requires "access CiviCRM".
Does this seem correct to folks? Is it to prevent someone escalating their ACL permissions? If so, it feels like we need a different permission, and predates more nuanced solutions such as [Group Protect](https://github.com/CiviCooP/org.civicoop.groupprotect). The only other entity that needs such high permissions is Relationship - that also seems wrong.
I propose that we add both GroupContact and Relationship entities to the `_civicrm_api3_check_edit_permissions()` function. If you can edit the contact, you can edit their groups/relationships. If someone gives this a "Concept: Approved" I'll work on the PR.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/182Proposal - add testSetup hook2023-09-19T05:03:18ZeileenProposal - add testSetup hookI am having a problem with test interoperability. I have an extension that other extensions can hook into (by virtue of having an api with a particular action).
The issue appears in unit tests. On the main extension test it will call t...I am having a problem with test interoperability. I have an extension that other extensions can hook into (by virtue of having an api with a particular action).
The issue appears in unit tests. On the main extension test it will call the code in the other extension as it would in production. However, there are some specific set up actions required for testing on other extension that happen in it's own tests but not, currently, in the main extension's test runs.
My best idea for this is to have a hook that sits in core called civicrm_testSetup & which could be called from the setup function in a unit test.
I did think about using the existing Config hook - but we run these tests under the Drupal CMS rather than under the Unit tests CMS so I'm not sure how we would identify it's a test. There is also something a bit odd about putting test concerns in the main config function.
I also thought about just putting the hook in my extension - but it seems that I would quickly want to add it to more than one extension - hence I think core maybe makes sensehttps://lab.civicrm.org/dev/core/-/issues/487Replace ancient menubar plugin with something responsive2023-09-19T00:35:47ZcolemanwReplace ancient menubar plugin with something responsiveThe current menubar jQuery plugin dates back to prehistoric times.
There have been some attempts to work around it with styling in Shoreditch and adding a hamburger menu for small screens with the [slicknav extension](https://github.com/...The current menubar jQuery plugin dates back to prehistoric times.
There have been some attempts to work around it with styling in Shoreditch and adding a hamburger menu for small screens with the [slicknav extension](https://github.com/aghstrategies/com.aghstrategies.slicknav) but IMO we need something better for core.
Plan o' action:
* [x] Create an extension implementing SmartMenus (thanks @ayduns!) https://github.com/aydun/uk.squiffle.kam
* [x] Migrate the [QuickSearch](https://civicrm.org/extensions/quicksearch) extension into core (see https://github.com/civicrm/civicrm-core/pull/13039).
* [x] Add `CRM.menubar` abstraction layer to provide a client-side api for adding/removing menu items, etc.
* [x] Fix click-to-open behavior (interaction is a bit confusing because the menubar opens on hover but closes on click)
* [x] Adjust icon spacing in the markup
* [x] Fix the CMS-specific placement issues (right margin for D7, admin region for Joomla)
* [x] Migrate the extension into Core.
* [ ] Consider bundling the extension into ESR (may not be possible due to core patches required).https://lab.civicrm.org/dev/core/-/issues/2546Add Settings, Disable, Delete buttons to group contacts listing page2023-09-14T15:09:10ZlarsssandergreenAdd Settings, Disable, Delete buttons to group contacts listing pageCurrently, you can only change settings, disable or delete a group from the Manage Groups page. It would make sense to be able to change the settings at least on the page that lists all the contacts in a group (disable and delete are les...Currently, you can only change settings, disable or delete a group from the Manage Groups page. It would make sense to be able to change the settings at least on the page that lists all the contacts in a group (disable and delete are less important, but I think they might as well be added as well). I often find I click into a group when I want to make it a mailing list and then realize I have to go back to the Manage Groups page and click settings.
I think this would make the most sense at the top of the page, maybe right below the "Add Contacts to this group" button or alternately, just above select records. Relatedly, I would also propose to put the "Edit Smart Group Criteria for this group" and "Add Contacts to this group" buttons on the same line, as they are currently on two.
For reference:
![image](/uploads/b7ed25111565401ddf2ae295795f3b8c/image.png)
I'll give this a go if it is supported.https://lab.civicrm.org/dev/core/-/issues/4569Proposal: Adding confirmation messages flexibly to Form Builder2023-09-14T15:03:30ZAndreasandreas.howiller@civiservice.deProposal: Adding confirmation messages flexibly to Form BuilderOverview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexib...Overview
----------------------------------------
This issue explains a new proposal for the "Support more workflows" section in the [Form Builder roadmap](https://lab.civicrm.org/dev/core/-/issues/3761): Add confirmation messages flexibly as we know it from Drupal webforms or Caldera Forms.
Current behaviour
----------------------------------------
Currently, there is no success message at all when I submit a form - as a user, I do not receive any feedback as to whether my data has really been processed.
Proposed behaviour
----------------------------------------
There should be a message for a successful submission resp. a message for errors.
For simple use cases such as editing data in the backend, the definition of messages per form (cf. #2957) is certainly sufficient. For more complex applications, more flexibility would also make sense in view of other features on the Form Builder roadmap, e.g. displaying messages after forwarding to a multi-step form (cf. #4574) or modal forwarding. To put it short: We should do it the way webforms does:
![confirmation_webforms](/uploads/74fa65d8d384b1f6b5de1da76be0e56c/confirmation_webforms.png)
Comments
----------------------------------------
1. There should probably be a translated fallback / standard message as well.
2. In order to be able to design success messages more individually, it should be possible to include form entries in the success message. Example: Dear Frank, thank you for signing our petition. In Caldera Forms, for example, this is comfortably solved via slugs / "magic tags":
![grafik](/uploads/097c919b39a4b575a524cf4b96b4f50a/grafik.png)
Cf. "post-submit tokens" on Form Builder roadmap and #4576https://lab.civicrm.org/dev/core/-/issues/2750Events RSS Feed doesn't include Event Date Field2023-09-14T05:03:24ZBarijohnEvents RSS Feed doesn't include Event Date FieldOverview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website ...Overview
----------------------------------------
Add Event Date to Event RSS template to allow easy aggregation into external websites.
Example use-case
----------------------------------------
To display events on an external website using the inbuilt RSS feed and CiviCRM Event functionality to reduce duplication of work.
Current behaviour
----------------------------------------
```
<item>
<title>Fall Fundraiser Dinner</title>
<link>https://dmaster.demo.civicrm.org/civicrm/event/info?reset=1&id=1</link>
<description> Kick up your heels at our Fall Fundraiser Dinner/Dance at Glen Echo Park! Come by yourself or bring a partner, friend or the entire family! This event benefits our teen programs. Admission includes a full 3 course meal and wine or soft drinks. Grab your dancing shoes, bring the kids and come join the party! When: January 26th, 2022 5:00 PM through January 28th, 2022 5:00 PM Where: 14S El Camino Way E Collinsville, CT 6022 United States </description>
<category>Fundraiser</category>
<author>development@example.org</author>
<guid isPermaLink="false">CiviCRM_EventID_1_f90c7968e68e8bc667d6d4c8808f6985@dmaster.demo.civicrm.org</guid>
</item>
```
Proposed behaviour
----------------------------------------
Remove author and add Event Start Date and Time.
Comments
----------------------------------------
Currently the default display of the RSS Feed doesn't include the start date of the event which makes it rather pointless as a RSS feed into external websites. I am sure this used to be there but it was rather a long time ago! It has the field of author which I don't feel is a useful field at the expense of start date at least.https://lab.civicrm.org/dev/core/-/issues/468Missing transaction ids on reports2023-09-10T05:03:24ZfrancescbassasMissing transaction ids on reports**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaa...**How to reproduce**
1. Create `contributionA` on `contactA` without assigning any *transaction_id*. A record on `civicrm_contribution` is created with `transaction_id = NULL`
2. Modify `contributionA` to assign a *transaction_id = aaaaaa*. The record previously created on `civicrm_contribution` stills have `transaction_id = ǸULL`
3. Create `contributionB` on `contactA` with a *transaction_id = bbbbbb*
4. Visualize a *Contribution Details* report with column *transaction_id* enabled and filtering results for `contactA`
5. Note that *transaction_id* column for `contributionA` is *empty* instead of *aaaaaa* and *transaction_id* column for `contributionB` is *bbbbbb*
Same happens on *Event Participants List* report for event related contributions in which the *transaction_id* was edited a posteriori.https://lab.civicrm.org/dev/core/-/issues/4557Proposal - Allow empty profile field labels instead of null2023-09-08T15:11:53ZshaneonabikeProposal - Allow empty profile field labels instead of nullPresently, when you create a Custom Profile and add fields you need add a label. In some cases, having a large question makes the label kind of awkward and crammed. It makes for a bad UX experience I believe.
So the workaround by most o...Presently, when you create a Custom Profile and add fields you need add a label. In some cases, having a large question makes the label kind of awkward and crammed. It makes for a bad UX experience I believe.
So the workaround by most of the designers I work with is to simply remove the ```label``` and then drop the question in the Pre text. This works just dandy, except that CiviCRM is adding ```null``` for empty texts. The only way to prevent this is to modify the label in the DB.
I would like to propose that we remove the code that is setting this text to null. I could make a quick patch. I realize the label is being used to create the actual field name, but in the case of the Profile the field name is already created.
![Selection_007](/uploads/48ab9decd2a6b1c3bb5a380a8278f12d/Selection_007.png)https://lab.civicrm.org/dev/core/-/issues/3753Proposal: Allow negative rules for ACLs2023-09-08T10:52:34ZTobias Voigttobias.voigt@civiservice.deProposal: Allow negative rules for ACLs**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - ...**PROBLEM:**
When defining ACL rules, it is only possible to 'allow' certain behaviour but not to 'disallow' it. This makes it tedious to define a set of rules that restricts access to e.g. groups of contacts or sets of custom fields - especially if you have many (groups or sets of custom fields).
**USE CASE:**
In one of our client's system, we have many groups and many sets of custom fields. What I want to achieve is:
1. define a privileged group / role that has exclusive access to **one** set of custom fields
2. allow access to all other sets of custom fields for all users
3. prevent 'normal' users from giving themselves access to the exclusive information by adding themselves to the privileged group
Because I can only define 'positive' ACL rules, here's what I have to do:
- turn off the WP permission for custom fields for the relevant roles (to be able to define my rules via CiviCRM ACLs)
- allow access to all sets of custom fields for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each set of custom fields**
- define a rule to allow access to the restricted set of custom fields to the privileged role
Depending on the number of sets of custom fields, this can be a tedious process. Not only that - if I create a new set of custom fields at a later time, I have to remember to create a new ACL rule for that as well.
Now for the third task (preventing users from adding themselves to the privileged group). To achive this I furthermore have to:
- turn off the WP permissions for viewing and editing all contacts for the relevant roles
- allow access to all groups for 'everyone' (excluding the one I want to restrict access for) - **by creating a rule for each contact group**
- define a rule to allow access to the restricted contact group only for the privileged role
Again: With about 50+ groups, that's a tedious task. And again: I have to remember to create a new ACL rule each time I add a new group.
All in all I could end up with a multitude of rules (in our case 70+) that are really hard to maintain.
**PROPOSAL:**
This task could be so much easier, if it was possible to define 'negative' ACL rules. If this was possible, I could:
- turn off the relevant WP permissions
- allow access to all sets of custom fields for everyone (1 rule)
- allow access to all contact groups for everyone (1 rule)
- disallow access to the restricted set of custom fields for everyone (1 rule)
- disallow access to the restricted contact group for everyone (1 rule)
- allow access to the restricted set of custom fields for the privileged role (1 rule)
- allow access to the restricted contact group for the privileged role (1 rule)
As is implied above, **there would have to be some form of priorisation** of rules to make this work.
This way I would end up with only 6 rules and would not have to remember to create new rules whenever I create a new set of custom fields or a new contact group.5.64.0https://lab.civicrm.org/dev/core/-/issues/3556Deleting a sent mailing leaves activities with invalid links to a mailing rep...2023-09-05T10:00:34ZlolcodeDeleting a sent mailing leaves activities with invalid links to a mailing report that doesn't workAssuming: Civicrm uses the default setting "Enable CiviMail to create activities on delivery"
If a mailing is created, sent and then deleted then the recipients of that mailing will have activities that link to a mailing report using an...Assuming: Civicrm uses the default setting "Enable CiviMail to create activities on delivery"
If a mailing is created, sent and then deleted then the recipients of that mailing will have activities that link to a mailing report using an invalid id. If the link is followed the error will be:
> Sorry, due to an error, we are unable to fulfill your request at the moment. You may want to contact your administrator or service provider with more details about what action you were performing when this occurred.
> Expected one Mailing but found 0
If clicked from the popup activity view it will just be a network error.
The body of the activity will also be blank after the mailing is deleted.
I am not convinced that allowing sent mailings to be deleted at all is a good design.
Some kind of an archive function might be better.
In the short term however the link should probably be removed from these activities.https://lab.civicrm.org/dev/core/-/issues/3552Set time limit for bounce types with hold_threshold > 12023-09-05T10:00:02ZMichael McAndrewSet time limit for bounce types with hold_threshold > 1Bounce types can be split into those with a hold_threshold = 1 where a single bounce should cause this contact to be put on hold (e.g. mailbox non existent), and those where more than one bounce is required (mailbox full).
We don't curr...Bounce types can be split into those with a hold_threshold = 1 where a single bounce should cause this contact to be put on hold (e.g. mailbox non existent), and those where more than one bounce is required (mailbox full).
We don't currently set a time limit on those where more than one bounce is required, which is an oversight. For example, the bounce threshold for Mailbox full is 3. This means that as soon as we have received more than 3 mailbox full messages for a contact, their email will be put on hold. This might make sense if it was 3 in the last year, but doesn't really make sense if it was three in the last 10 years.
Similar arguments can be made for other bounce types, like Away, which is set to 30. If I send a fair amount of email to people that are out of the office quite a lot, over time a significant chunk of these will send me > 30 out of the office messages.
Hence we should only consider messages received in a certain time period. I am going to suggest one year. I would be up for making it user configurable (number of days) if people feel strongly about it.
Let me know what you think.https://lab.civicrm.org/dev/core/-/issues/3049Auto-complete option values aren't available to anonymous users2023-09-02T01:04:32ZJonGoldAuto-complete option values aren't available to anonymous usersOverview
----------------------------------------
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/2572Prevent unintentional removal from group for anonymous users filing out profiles2023-09-01T19:44:06ZlarsssandergreenPrevent unintentional removal from group for anonymous users filing out profilesCurrently, 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/444Updated alterReportVars or new hook for reports2023-08-31T08:51:04ZJoeMurrayUpdated alterReportVars or new hook for reportsThere 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/4134SearchKit: Add TIMESTAMPDIFF to calculate between two dates in years, months,...2023-08-30T15:49:10ZfrancescbassasSearchKit: 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/core/-/issues/2115Move financialACLs to a core extension2023-08-30T05:03:25ZeileenMove financialACLs to a core extensionThis 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 membershiphttps://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/4045Ideas for (funded) speed improvements in mailings2023-08-28T14:44:15ZAndrew WestIdeas for (funded) speed improvements in mailingsWe'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There a...We'd be interested in funding some speed improvements when building mailing recipients in CiviMail. They'd inherently feed through to Mosaico, I think.
We find the mailings screens pretty snappy apart from selecting recipients. There are few bottlenecks that it'd be nice to get rid of:
**Improve the dropdown**
When you have lots of groups and mailings the dropdown doesn't work very well. It stalls, with multiple spinners appearing, or wipes out your text while typing, or says 'none found' for a bit before updating, or alternates between 'Searching' and 'Loading', and generally takes an achingly long time to find the groups in its own dropdown.
![image](/uploads/91dcd7a0a2c2e7d3230c4016d1d49db0/image.png)
Compare this to the smart group dropdown in Search Kit, which is blindingly fast.
Maybe this could be replaced with the new API4-based entityref? Possibly split into two (or even four?): Groups to include / Groups to Exclude / Mailings to include / Mailings to exclude?
**Improve generating the list of recipients**
A complicated selection of groups can easily take 30 seconds to update and save, for us. This is very frustrating when adding one smart group at a time in the dropdown. Possible fixes:
- Refactor CRM_Mailing_BAO_Mailing::getRecipients(). At the moment this function seems to create a lot of temp tables, and uses a bunch of heavy queries to compare them against each other. Again, Search Kit can do complicated includes/excludes way faster. So I figure this could be modernised.
- Possibly the slow part here is emptying/filling civicrm_mailing_recipients each time the criteria are changed. Maybe add a 'getRecipientCountPreview' function to get a count of recipients without actually populating the table? This would let people experiment in the mailing screen quickly. Then only generate the actual recipient list when the mailing is scheduled or saved as a draft?
Any other ideas? Or thoughts on whether the above makes sense?
We could fund maybe 15hrs on this atm. If anyone wants to join us that'd be great too :-)https://lab.civicrm.org/dev/core/-/issues/2644Proposal - new core extension for scheduled reminders using criteria from sea...2023-08-28T12:20:35ZeileenProposal - new core extension for scheduled reminders using criteria from search-kitThis replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contr...This replaces https://lab.civicrm.org/dev/core/-/issues/2267 as a way to address the same issue - ie our search criteria for scheduled reminders is way too brittle due to the inflexible schema. For example it is not possible to use contributions > x amount or contributions from campaign y.
Given that we Apiv4 / search kit is the way we are going with search criteria it makes sense to use these as criteria for the reminder search too to replace (in the distant future) the existing fields.
#2267 proposed adding api params & api entity to the scheduled reminder table but I now think it makes more sense as an extension - which I have been experimenting with.
This extension does not have to go into core - it could be something I just maintain to the degree I see fit.
However, the main reason we would consider it as a core extension is that it could eventually replace the existing scheduled reminder form (which would fit our LEXIM plan to get off quick forms and onto everything being apiv4 based). The hope is not to replace the additional functionality in CiviRules for people who want that but to reduce pain points in the scheduled reminder code that is already in core and as a path away from maintaining the relevant quickforms.
Note that if we proceed with this as a core extension I will PR it in once it hits 'alpha' but we would not enable by default and we can have a discussion at that point as to whether it should be hidden or not depending on how mature it is.
I note @totten's response to the question as to whether it should go into core rather seemed to hinge on whether the UI is any good - and since it's not yet written we can't address that at this stage.https://lab.civicrm.org/dev/core/-/issues/1164Editing event participant can affect wrong record if multiple participants ar...2023-08-24T10:07:23ZJKingsnorthEditing event participant can affect wrong record if multiple participants are opened in multiple tabs/windowsThis is an old issue (sorry I couldn't yet find the original issue in JIRA that was raised for this.)
It was recently attempted to get fixed here: https://lab.civicrm.org/dev/core/issues/1164 / https://github.com/civicrm/civicrm-core/pu...This is an old issue (sorry I couldn't yet find the original issue in JIRA that was raised for this.)
It was recently attempted to get fixed here: https://lab.civicrm.org/dev/core/issues/1164 / https://github.com/civicrm/civicrm-core/pull/14244 but a regression caused the patch for event participants to be reverted.
The problem, example of dmaster:
* Events > Find participants > Search
* 'Edit' one participant (Lincoln) in a new tab
* 'Edit' a second participant (Teresa) in a new tab
* Go to Lincoln's edit tab, change to no-show, save
* The change has been applied to the WRONG record (Event registration information for Teresa Terry has been updated.)
This is because the participant ID is being stored in the session.