CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-12-21T05:03:20Zhttps://lab.civicrm.org/dev/core/-/issues/3206Cannot save a copy of a report without the "administer reports" permission2023-12-21T05:03:20ZbgmCannot save a copy of a report without the "administer reports" permissionTo reproduce:
* Create a user with the following permissions
* access CiviReport
* access Report Criteria
* save Report Criteria
* Go to an existing report (or a template)
* Refresh the results
* Under Actions, click "save as"
Re...To reproduce:
* Create a user with the following permissions
* access CiviReport
* access Report Criteria
* save Report Criteria
* Go to an existing report (or a template)
* Refresh the results
* Under Actions, click "save as"
Result: javascript error: "TypeError: $refresh_field.html() is undefined"
![report-saveas-2021-08-05_14-45](/uploads/fe812c8f50c77c51a5a010987cd9b86d/report-saveas-2021-08-05_14-45.png)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/2730Consider replacing fopen() call in CRM_Utils_File::isIncludable with stream_r...2021-08-09T12:58:54ZDaveDConsider replacing fopen() call in CRM_Utils_File::isIncludable with stream_resolve_include_path()The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or ma...The problem is depending on how strict your setup is, some code that uses the error suppression operator (e.g. `@unlink('file_which_may_not_exist')`) behaves differently in php 8 and doesn't get supressed, either flooding your logs or making civi unusable in some cases.
In particular the api magic function provider uses an algorithm for e.g. getfields, where often the first guess is wrong, leading to an error.
isIncludable was added in 2011, and while stream_resolve_include_path was available at that time, it was introduced into php in 2010, so it's possible not a lot of sites had it.5.41.0https://lab.civicrm.org/dev/core/-/issues/2720Consider bringing export permission into core2024-02-26T05:03:21ZeileenConsider bringing export permission into coreI took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissio...I took a look at https://github.com/progressivetech/net.ourpowerbase.exportpermission in the light of https://github.com/civicrm/civicrm-core/pull/20945 and felt like maybe this should be in core. It basically adds and checks 4 permissions
- 'Access "Export as CSV" drop down menu item from actions menu on after search/report'
- Access "Print" drop down menu item from actions menu on search/report
- Access "Print/Merge document (PDF Letter)" drop down menu item from actions menu on search/report
- Access "Print Mailing Labels" drop down menu item from actions menu on search/report
In terms of reasons why this would be better in an extension than core - here are some questions I think we would consider
1) does it impose a maintenance burden on core (in this case I would say no)
2) does it have/need unit tests. In this case (incredibly) I would be OK without tests - but they would be super-easy to add to https://github.com/civicrm/civicrm-core/pull/20944
3) does it meet a generic needs or a specific need - this feels fairly generic
4) does it over-complicate using core
5) is it just too hard to negotiate with the community on this topic.
My suspicicion is that the reason for not putting this in core in the past falls between 4 & 5 - ie. some people feel that adding more permissions over-complicates the permissions UI as a matter of principle. But I think it's worth asking the question againhttps://lab.civicrm.org/dev/core/-/issues/3578Send order when A/B testing2024-02-15T05:03:25ZufundoSend order when A/B testingAs far as I can see current behaviour when processing an A/B test mailing is that CiviMail sends out to all A recipients then all B recipients.
If you have rate limiting on outbound email that is significant relative to your list size, ...As far as I can see current behaviour when processing an A/B test mailing is that CiviMail sends out to all A recipients then all B recipients.
If you have rate limiting on outbound email that is significant relative to your list size, this can result in a significant difference in (average) send time between the A group and the B group, which may then be confounding your A/B test results.
I wonder how hard it would be to implement some kind of interpolation (?) for the sends for an A/B mailing -- something like firing off equal numbers of As and Bs in each mailing batch as they are processed?https://lab.civicrm.org/dev/core/-/issues/2669Target contact missing for automatically generated case activities2023-02-23T16:00:45ZAndreasandreas.howiller@civiservice.deTarget contact missing for automatically generated case activitiesOverview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cann...Overview
----------------------------------------
Some actions on cases leave automatically generated activities in the case activity log, but have no target contacts. Examples: Change case title, change case tags. As a result, they cannot be edited through the user interface. While this is a minor issue, some users may want to leave notes about the activity (for example, why they changed a case title) and therefore need to edit it.
Reproduction steps
----------------------------------------
1. Open any case in CiviCRM and change the case title.
2. Tap edit for the corresponding activity in the activity timeline.
3. Tap save.
Current behaviour
----------------------------------------
The dialog will freeze while the CiviCRM logo keeps turning. A fatal error "DB Error: constraint violation" will be filed in the logs.
If you add any contact as a target contact in the database or in the edit screen the error won't appear anymore.
What is confusing, too: When editing the activity the client contact already wrongly shows up as target contact in this dialog and if you'd like to change it there you need to search the contact (the link to choose the client contact below the search field won't do the change here).
Expected behaviour
----------------------------------------
The Client contact is filed as target contact by default and connected problems disappear. E.g. editable activities can be saved after edit through UI now.
Environment information
----------------------------------------
* __CiviCRM:__ _5.35.2_ and _5.38.0_
* __CMS:__ _WordPress 5.7.2_https://lab.civicrm.org/dev/core/-/issues/3190How to package SearchKit Displays in an extension2022-04-22T18:06:46ZcolemanwHow to package SearchKit Displays in an extension## Use Case
Ship an extension with SearchKit-based tabs for the Contact Summary screen.
## Requirements
Using a Search Display as a contact summary tab requires 3 interconnected entities:
1. A **SavedSearch** containing the api param...## Use Case
Ship an extension with SearchKit-based tabs for the Contact Summary screen.
## Requirements
Using a Search Display as a contact summary tab requires 3 interconnected entities:
1. A **SavedSearch** containing the api params for the search.
2. A **SearchDisplay** linked to the `SavedSearch` by id (`saved_search_id = $savedSearch.id`).
3. An **Afform** linked to both the `SavedSearch` and the `SearchDisplay` by name (via embedded tag).
## Solutions
### 1. The Status Quo
Afforms can already be packaged as `.aff.html/.aff.json` files, and the Afform API & GUI have excellent handling for packaged Afforms to be overridden and reverted by site admins. If an extension upgrade provides updates to a packaged Afform, overrides will not be affected but the default version will be upgraded automatically.
DAO-based entities like `SavedSearch` and `SearchDisplay` can be packaged as `.mgd.php` files which will be added to the database via `hook_civicrm_managed`. However, the `CRM_Core_ManagedEntities` system doesn't provide any way for admins to override and then revert back to the packaged version, nor to reconcile potentially overridden entities with new packaged versions during extension upgrades. There are also an issue where the system doesn't guerantee write order, and in this case we need it to write the `SavedSearch` prior to the `SearchDisplay`, which contains a foreign key to the former.
Currently there is a workaround using chaining and `'update' = 'never'`, for example as used by the [Deduper Extension](https://github.com/eileenmcnaughton/deduper/blob/master/entities/SavedSearch.mgd.php).
`CRM_Core_ManagedEntities` offers us 2 modes for packaging `SavedSearch` and `SearchDisplay` entities, neither is ideal:
1. **`'update' = 'always'`** will essentially lock the entities. Any changes to the search made by the site admin will be overwritten on a regular basis. This solves the extension upgrade problem at the cost of configurability.
2. **`'update' = 'never'`** will drop the entities into the database and then never touch them again. This is the lesser of two evils because at least this way they are configurable.
**The bottom line:** The status quo allows us to package searches and displays. They will be user-configurable but not revertable (if the admin makes a mess of them, he'd have to delete them all and then uninstall/reinstall the extension). During extension upgrades, the packaged Afforms will update, but changes to `.mgd.php` files will do nothing unless the extension is uninstalled, searches are deleted, and then it's reinstalled.
### 2. Create APIv4 `PackagedEntity` class
This would do something like the `Afform` APIv4 entity: read from the database and *also* from json files. This would need to be opt-in on a per-entity basis (starting with `SavedSearch` and `SearchDisplay`) and would be mostly for configuration entities, as a file/DB hybrid would not be able to perform joins in the GET action.
**Tasks**
1. Add an APIv4 trait `PackagedEntity`
2. Opt-in `SavedSearch` and `SearchDisplay` to use that trait
3. Add a specialized `get` action which would read from json files and the database.
4. Add calculated fields comparable to Afform's `has_base` & `has_local` to `get` output.
**Pros**
- Would give excellent feature parity with Afform's packaged systems.
- Reverting and upgrades would be simple.
**Cons**
- Involves extra file i/o and directory scanning with each `get` - feasible with hundreds of records but not many thousands.
- Restricted to APIv4 as the packaged entities wouldn't exist as far as the DAO is concerned.
- Entities have to opt-in (whereas `mgd` works on any entity).
- Retrofitting an existing API over would involve a slight BC breakage as the new `get` method would be missing `JOIN`, and `HAVING` clauses.
### 3. Improve `CRM_Core_ManagedEntities`
Make the manager aware of whether a record has been manually updated. Add a new `'update' = 'auto'` mode which would intelligently push updates from `.mgd.php` only to untouched records. Add a way to revert a record.
**Tasks**
1. Add an `is_overridden` column to the `civicrm_managed` table.
2. Add some type of trigger to set that column when manual changes are made to a managed entity.
3. Add some type of `Revert` api action (currently the `Managed` class doesn't even have an API so this will take some thought).
4. Add a way to know if a database record has a corresponding managed entry (maybe a calculated field or maybe a DFK join - both would be slightly tricky).
**Pros**
- Fully backward compatible with existing entities.
- Improves the existing "Managed" system instead of inventing a new one.
- Wouldn't be a drag on performance.
**Cons**
- Might be a lot of work.https://lab.civicrm.org/dev/core/-/issues/2650Use consistent token syntax for pseudoconstants2022-09-01T07:55:13ZeileenUse consistent token syntax for pseudoconstantsAt some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core...At some point we want to have consolidated token code. One thing that is missing at the moment is agreement as to what tokens we are working towards. (this came out of discussion fixing for php8 in https://github.com/civicrm/civicrm-core/pull/20591) I want to constrain this issue to the very narrow question of syntax for pseudoconstants & unique names in tokens.
If we look at [the test](https://github.com/civicrm/civicrm-core/blob/275686a34ca7bf5e9c4d6653cd8cca5cf15e36cf/tests/phpunit/CRM/Contribute/Form/Task/PDFLetterCommonTest.php#L264) we can see the current tokens supported by the existing code. A somewhat different set is supported by the [TokenProcessor class for contributions](https://github.com/civicrm/civicrm-core/blob/c2a33d9c890f81bf2287351f0a830ef58b1dc98c/CRM/Contribute/Tokens.php#L26)
So we can see that in one place you would pass
{contribution.contribution_status_id} to get 'Pending'
and in the other it would be {contribution.status}
We are also 'promoting' (by presenting in the UI selector) {contribution.contribution_source} over {contribution.source} in how we present tokens, even though in this case I think both work.
I would propose that our preferred tokens adhere to apiv4 style conventions as much as possible. Preferring means that we work towards the following (on an ad hoc basis).
1) the tokens that are selectable in the UI on the form return the preferred variants
2) we support the preferred variants in tested code on both token methods
3) we run db update scripts to replace the less preferred with the preferred in the msg_template and action_schedule tables as we feel safe doing so
4) we deprecate less preferred variants by adding deprecation notices to places where they are used, when we feel safe doing so.
Proposed conventions
1) deprecate unique name prefixing - ie prefer {contribution.source} over {contribution.contribution_source}
2) actual field name returns the value of that field - ie {contribution.contribution_status_id} would return a number rather than a string
3) we use apiv4 style tokens for labels - ie {contribution.contribution_status_id:label}
(out of scope for this issue = apiv4 style custom field names or custom fields in general, returning calculated values for eg. contribution.check_number)
If we go with the above the specific action I will add to my (long) todo list is to engage with fixing contribution_status_id to make it consistent between the 2 classes and the selector - ie
1) Replace the 'advertised' token from
``` 'contribution.contribution_status_id:label' => 'Contribution Status'```
'contribution.contribution_status_id:label' => 'Contribution Status'
2) add tested support for ```'contribution.contribution_status_id:label'``` to both classes
3) fix any core message templates to use 'contribution.contribution_status_id:label'
4) fix the upgrade script to str_replace 'contribution.contribution_status_id' in the message template table (only)
The other fields in this space that are currently inconsistent are
- financial_type_id, campaign, payment instrument id, cancel_date, source
@colemanw @totten @seamuslee @mattwire5.43.0https://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/2639Money: Plan to migrate from currency separators from locale2023-08-16T05:03:18ZeileenMoney: Plan to migrate from currency separators from localeThere is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com...There is a goal to switch to sites specifying their money_locale from specifying currency separators
The original discussion on how to do this was in the dev-digest and a PR. @mattwire has since suggested an alternate https://github.com/civicrm/civicrm-core/pull/20296#issuecomment-855377189
"Override currency separators" - "By default CiviCRM will format currency in accordance with the locale for the user that is viewing the information"
I've moved the text below from a comment on the github PR to here ....
In terms of adding a setting I went hunting for where it was discussed before & it is here
https://github.com/civicrm/civicrm-core/pull/19753
![image](https://user-images.githubusercontent.com/336308/120940640-63d47800-c772-11eb-8b46-302f4d311ef3.png)
Further down the same PR is the content that was pasted into the dev-digest
![image](https://user-images.githubusercontent.com/336308/120940681-92eae980-c772-11eb-9ff9-588d1e3ca663.png)
Compared to @mattwire's suggestion this is
1) implicitly opt in at the start - ie let early adopters set it & when we are confident be more aggressive
2) a different setting name / description - I think setting money_locale might be less intuitive short term (since it magically disables the other settings) and more intuitive longer term since the other settings should become meaningless & disappear over time.
Revisiting @jaapjansma's comment
![image](https://user-images.githubusercontent.com/336308/120940808-33410e00-c773-11eb-9bae-9910a3ff7583.png)
It DOES seem like site locale is going to be wanted as a setting - although it could be that this is not the point where we add ithttps://lab.civicrm.org/dev/core/-/issues/2638Money - create new Civi:: facade - now format helper2023-09-24T22:53:25ZeileenMoney - create new Civi:: facade - now format helperOur CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here...Our CRM_Utils_Money class wound up a mess so we talked about creating a new supported/tested/readable class to put our money functions in and this class would be supported for use by core & external code.
@seamuslee did a first cut here https://github.com/civicrm/civicrm-core/pull/20296 which highlighted some of the issues / complexity
I made comments there but I've moved them to this gitlab
Useful framing by @jaapjansma
CiviCRM has the following ways of displaying data:
- On the screen in back office (this is the language and locale of the logged in user)
- On the screen in front office screens (such as registering for an event, this should be the sites locale and language)
- In communications with the contact, such as letters and pdf. We should use the language and locale of the contact
Ideally we should also have a setting for the locale and not only the language.
Looking at @jaapjansma's list it seems that at the end of the day we want (these don't have to be all working / added now but I think we might want to comment in the intent into the class)
```
Money()->formatMachine($amount, $currency);
Money()->formatSiteLocale($amount, $currency);
Money()->formatUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatSpecifiedLocale($amount, $currency, $locale);
```
We also have 2 other variables in the mix - precision & noCurrencySymbol
I tend to prefer to use separate functions for noCurrencySymbol - eg
```
Money()->formatNumericOnlyMachine($amount, $currency);
Money()->formatNumericOnlySiteLocale($amount, $currency);
Money()->formatNumericOnlyUserLocale($amount, $currency, $contactID); // defaults to logged in user
Money()->formatNumericOnlySpecifiedLocale($amount, $currency, $locale);
```
but it could be a consistent parameter in the other functions
On the precision question we have
- fixed precision
- no rounding
- currency specific precision
Perhaps this is a parameter on all the above functions ('fixed', NULL or 'by_currency' ) - I personally prefer documenting that in the comment block than using a constant although some people like constants
This is quickly getting us back into the confusion of CRM_Core_Money which this PR was intended to get us away from but hopefully we can figure out the set of signatures we want this time AND remember what they actually mean!
Also - we probably want functions that returns the actual Money object - not just the output
Note that where we want to be is that the CRM_Utils_Money class can be an internal class and the Civi::Money is an external class - so how we deal with the thousand separator in CRM_Utils_Money can change over timehttps://lab.civicrm.org/dev/core/-/issues/2635Download latest version of an extension without installing2023-08-19T05:03:24Zmagnolia61Download latest version of an extension without installingOverview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an ex...Overview
----------------------------------------
It would be good to be able to download the latest version of an extension without installing it for security reasons.
Current behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to download and install
![image](/uploads/c618c97b6ec39f98d9b884b0211187fb/image.png)
Proposed behaviour
----------------------------------------
1. an extension that was previously installed but since disabled or uninstalled remains present in the extension directory
2. the extensions management ui provides buttons to "download" or to "download and install"
Comments
----------------------------------------
Of course best practice is to remove any extension which is uninstalled, but disabled extensions are also present in the filesystem. Being able to update extensions that are not installed, improves security as the latest stable code can be downloaded.https://lab.civicrm.org/dev/core/-/issues/2634Membership api for v42021-08-25T22:27:29ZeileenMembership api for v4Apiv4 doesn't have a membership api yet - mostly because of issues with the membership.create process.
I caught up with @kcristiano this week & we fleshed out what the 3 issues are
1) Membership api does financial stuff including creat...Apiv4 doesn't have a membership api yet - mostly because of issues with the membership.create process.
I caught up with @kcristiano this week & we fleshed out what the 3 issues are
1) Membership api does financial stuff including creating line items and in some cases creating contribution. I worked through getting rid of one of these bits of magic, converting the back office form to use Order api when setting up a new recurring membership. Getting review on this was slow going so it will take a long time to convert other places. (I have started on the batch membership form & Kevin is going to help with review there).
However, I made a proposal that Kevin agreed with that we simply don't touch ANY of that financial stuff if $params['version'] === 4. The idea is that the handling (which may or may not be right) for apiv3 and for those calls that still call the BAO directly will be unchanged but for v4 callers need to either
a) call the order api (which we will fix to call the v4 membership api internally) or
b) create their own line items. Note that memberships without contributions actually should have line items according to the model.
I will work on this once we have fixed some issues with the order api's integrity - https://github.com/civicrm/civicrm-core/pull/20656 is the most obvious but the intent is to get the extra cover that deprecating our random magic will provide https://github.com/civicrm/civicrm-core/pull/20678 too. (This is not a big piece of work but it requires fairly experienced review )
2) Membership date handling for new memberships is in the v3 api (and the form layer). I did a patch for this. https://github.com/civicrm/civicrm-core/pull/20759 -
3) Membership date handling for renewals. Apiv3 has some magic around this that is not in the BAO. I have come to the conclusion we can handle this by
-- using the Order->payment flow. In other words the dates are calculated at the point when Payment.create is added, using the membership_num_terms as stored in https://github.com/civicrm/civicrm-core/pull/20672
-- OR - if that flow won't work for people for any reason, they can pass in all the date values.5.42.0https://lab.civicrm.org/dev/core/-/issues/3372Event reminder add more than one group2024-01-08T05:03:19ZStefanEvent reminder add more than one groupHello everyone,
so we want to heavily use events and event reminders. Then, we got the event on the website, our members get the reminders and also ppl who register get them.
Thing is, I can choose a role and additionally one group.
B...Hello everyone,
so we want to heavily use events and event reminders. Then, we got the event on the website, our members get the reminders and also ppl who register get them.
Thing is, I can choose a role and additionally one group.
But what is, if this needs to be sent to more than one group?
I then could set up multiple reminders and also - I guess - create a dynamical group which contains other groups. But both seems inpractical compared to that smooth select field when I send regular traditional mails, where I can choose multiple groups.
Wordpress: 5.7.2
Civicrm: 5.37.2https://lab.civicrm.org/dev/core/-/issues/3401Event reminder html mandatory2024-01-15T05:03:29ZStefanEvent reminder html mandatoryHello everyone,
Wordpress: 5.7.2
Civicrm: 5.37.2
When I send scheduled event reminders it says, that html is mandatory.
I wonder why that is, cause I don't have to send html mails in traditional mail sending.
For me that was an issu...Hello everyone,
Wordpress: 5.7.2
Civicrm: 5.37.2
When I send scheduled event reminders it says, that html is mandatory.
I wonder why that is, cause I don't have to send html mails in traditional mail sending.
For me that was an issue, therfore I haven't had an html editor activated and without one it was a mess for my users to send a formatted html mail.
Still I think, if there aren't serious concerns about that, just sending plain mails should be allowed.https://lab.civicrm.org/dev/core/-/issues/2629Participant Status: pending refund can have two conflicting meanings2024-01-17T05:03:29Zmagnolia61Participant Status: pending refund can have two conflicting meaningsOverview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there...Overview
----------------------------------------
With partial payments and partial refunds becoming mainstream in CiviCRM, I think it is time to reconsider the connection between contribution status and participant status. I think there are more than one aspects of this, but I will focus on 'pending refund'
Example use-cases
----------------------------------------
1. change the payment or price-set to make a partial refund necessary
2. cancel the participant to make a (partial) refund necessary
Current behaviour
----------------------------------------
Currently a participant status: Pending Refund defaults as a positive count.
But there are two scenario's that can cause this participant status:
1. there is a contribution total that is higher than the total event fee amount
2. there has been a cancellation for the event and the fee is pending to be refunded
In scenario 1: The participant is still expected to attend the event
In scenario 2: The participant will not attend the event
Proposed behaviour
----------------------------------------
I think it is becoming troublesome to relate the contribution status with the event status.
The default is that 'Pending refund' counts positive towards attendance.
Two proposals could be
a) to remove participant statuses connected with the contribution
- may cause other difficulties, might me the best in the long end
b) to add a new status and to differentiate between two types of pending refund scenarios:
- Pending refund (cancelled)
- Pending refund (attending)
First one would have count status 0, second one count status 1
Comments
----------------------------------------
Any thoughts on this one? Can I find agreement on this proposal?https://lab.civicrm.org/dev/core/-/issues/2624Line items not visible on recurring contribution2021-07-28T14:48:48ZjaapjansmaLine items not visible on recurring contributionWhen creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial t...When creating a new contribution recur with a contribution page and a price set with multiple line items. The line items are not stored within the contribution recur entity.
**Steps to reproduce**
1. Create a new price set (Financial type donation)
2. Create a price set field (Financial type Campaign donation)
3. Create a second price set field (Financial type Products)
4. Create a contribution page:
Financial type: donation
Amounts tab: Payment Processor: test processor
Amounts tab: Contributions amount section enabled: checked
Amounts tab: Price set: _select the created price set_
Amounts tab: Recurring contributions: check
5. Create a new contribution recur through the contribution page
6. Lookup the contribution recur on the Contact Summary
**Expected result**
Showing the line items. The total amount is correct.
**Actual result**
Line items are not visible at the contribution recur.
Below a screenshot of the contribution
![Screenshot_20210520_211830](/uploads/2447b95df431002e4405559a72fec4b5/Screenshot_20210520_211830.png)
And of the recurring contribution
![Screenshot_20210520_211918](/uploads/4036a932904649bbaa7c0d93b13879fb/Screenshot_20210520_211918.png)
**Possible solution**
I have looked up the line items in the database and there are no line items linked to the recurring contribution.
So the possible solution would exists of two steps:
1. Connect the line items to contribution recur
2. Make the line items visible in a similar way as on the contribution.
**Remarks**
Creating a new contribution with the `contribution.repeattransaction` api based on the first contribution and the recurring contribution correctly creates the line items at the contribution level.
**Funding**
I have some funding to work on this. So PR's might follow soon.
**PRs**
* ~~Fix for saving line items at the recurring contribution: https://github.com/civicrm/civicrm-core/pull/20398~~
* Fix for showing the line items from the template contribution: https://github.com/civicrm/civicrm-core/pull/20399
* Fix for excluding template contributions from reports: https://github.com/civicrm/civicrm-core/pull/20450
* Fix for searching template contributions: https://github.com/civicrm/civicrm-core/pull/20451
* Fix for excluding template contributions on the contact summary tab: https://github.com/civicrm/civicrm-core/pull/20452
* Fix for adding a button view template on the recurring contributions tab: https://github.com/civicrm/civicrm-core/pull/20685
* ~~Fix for creation of template contributions: https://github.com/civicrm/civicrm-core/pull/20453~~
**To do**
* Update user documentation
* Make sure an upgrade path exists
See also financial#65.41.0jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/2622APiv4 does not handled display name when only email is provided2021-05-27T22:27:30ZeileenAPiv4 does not handled display name when only email is providedDemonstrated in the test https://github.com/civicrm/civicrm-core/pull/18865
Options are
1) accept that it's OK to pass 'email' to contact.create bao even though it is not a 'contact field' or
2) do an extra check on every primary email...Demonstrated in the test https://github.com/civicrm/civicrm-core/pull/18865
Options are
1) accept that it's OK to pass 'email' to contact.create bao even though it is not a 'contact field' or
2) do an extra check on every primary email save - note that historically parsing the smarty greeting tpl for the display name is expensive so we'd need to only set if empty.
I'm on the fence about the performance of 2 - most of our db locks these days are actually db insert locks on the email table for some reason (now that we have eliminated the acl related locks)
@colemanw - but to gitlab as promisedhttps://lab.civicrm.org/dev/core/-/issues/3361View and Edit links for event participants are inconsistent and in some cases...2023-08-12T00:24:39ZlarsssandergreenView and Edit links for event participants are inconsistent and in some cases do not allow editingWhen using a price set, the View and Edit links for a participants lead to different forms depending on if the registration has an associated contribution. When there is a contribution record, the Edit link does not allow the user to edi...When using a price set, the View and Edit links for a participants lead to different forms depending on if the registration has an associated contribution. When there is a contribution record, the Edit link does not allow the user to edit the price set selections, while it is possible to edit those selection from the View link (with Change Selections). I believe this is a regression.
When there is no contribution record, you cannot edit the price set selections from the View link, but you can from the Edit link. That seems confusing for users and it would be best to make it consistent.
Here are some screenshots:
1) View with a contribution, this makes sense
![image](/uploads/52e7c3a5b96befe0a404f57850cc5bcf/image.png)
2) View without a contribution, seems like it there should be possible to change selections here as well for consistency (or else a user may think they can't edit the price set selections)
![image](/uploads/c93e10bbecf9ae053ea771becb07ac12/image.png)
3) Edit with a contribution, this should be the same as the View with a contribution, i.e. there should be a Change Selections link and the table of selections above it
![image](/uploads/95edcf86ca33d6bcdff302cee619acf8/image.png)
4) Edit without a contribution, this makes sense
![image](/uploads/12e211610125abb94b4f829bca465ebe/image.png)
I believe 3 - Edit with a contribution is a regression. I get his behaviour on dmaster, 5.37 and 5.35.2, but not on 5.24.5, where there is a Change Selections link and the table above.
Changing 2 - View without a contribution may be more complicated. What about adding an Edit Registration link, in the same place where the Change Selections link would otherwise be, that simply takes you to the edit form? As far as I can tell, trying to use Change Selections with a registration that doesn't have a contribution will result in errors. I'm not sure what would be involved in making it possible to use Change Selections in this case, but it seems like adding an edit link would be a simpler solution to keep some consistency between these two cases.https://lab.civicrm.org/dev/core/-/issues/2611Change default_value column for custom fields from varchar to text2023-08-20T02:32:58ZlarsssandergreenChange default_value column for custom fields from varchar to textA custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make se...A custom field can be of many types, including note. For a custom field that is a note, you may want to use a default value that is longer than 255 characters, but currently the default value is stored as a varchar(255). It would make sense to change this column to text, so that longer values can be entered.
In the custom fields UI, this field would be changed to a textarea when note is selected.
For us, the use case would be storing the content of a short waiver, so that the exact value of the waiver at the time of signing can be stored on the participant for an event, but I can imagine there may be other use cases.
Will submit PR if supported.