CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2024-01-16T16:07:07Zhttps://lab.civicrm.org/dev/core/-/issues/2928Expand Gender options?2024-01-16T16:07:07ZJoeMurrayExpand Gender options?Overview
----------------------------------------
Currently core has a Gender field with options in tarball of: Male, Female, Other. There has been a great deal of social change in this area with widespread use of additional terms. In ad...Overview
----------------------------------------
Currently core has a Gender field with options in tarball of: Male, Female, Other. There has been a great deal of social change in this area with widespread use of additional terms. In addition, it might be useful to have default questions and options for whether a contact is transgendered and what pronouns they would like.
Example use-case
----------------------------------------
1. Click on **Contacts -> New Individual**.
1. Enter **First Name** and **Last Name** and click **Save**.
Current behaviour
----------------------------------------
![2021-10-26_11-46-51](/uploads/f5985494ccec6ce0c0c143cc688014b2/2021-10-26_11-46-51.png)
Proposed behaviour
----------------------------------------
I'm going to break up the proposal into several parts that can be discussed and possibly approved separately.
1. Add to the list of gender options after Other: Prefer not to specify.
2. After Male and before Other, insert new gender options: Non-binary, Genderfluid.
2. Change from Female to Female/woman and from Male to Male/man.
3. Change the Gender field from single select to multiselect.
4. Add a new core field under Gender: Are you transgender? Yes, No, Prefer not to specify.
5. Add a new core field under the above: What pronouns do you use? He/him/his, She/her/hers, They/them/theirs, Zie/hir/hirs, Other.
6. Make the field for Pronouns multiselect.
An alternative that might make sense is to do some of this in an extension. Another alternative would be to assist with best practices by providing questions or options but defaulting to disabled.
Comments
----------------------------------------
Here is a note from an organization that works in this area in response to my query on behalf of a client for a longer list of genders:
> Coming up with a universal list of terminology to describe trans people can be difficult, since the exact terms used to describe the concepts involved varies dramatically from language to language and culture to culture. While trans communities in Canada and the US tend to use the same terminology, it can vary even with other majority Anglophone countries, to say nothing of the rest of the world.
>
> There is a lot of discussion out there in the data world about how best to record sexual orientation and gender identity (or “SOGI”) data, and best practices depend on the field in question. That said, a good starting point is to divide things into four questions framed like so:
>
> 1. What is your gender? (select all that apply)
> a. Female/woman
> b. Male/man
> c. Non-binary
> d. Genderfluid
> e. Other
> f. Prefer not to specify
>
> 2. Are you transgender?
> a. Yes
> b. No
> c. Prefer not to specify
>
> 3. What pronouns do you use? (select all that apply)
> a. He/him/his
> b. She/her/hers
> c. They/them/theirs
> d. Zie/hir/hirs
> e. Other
>
> Breaking things out like this has several advantages. First, it recognizes that “transgender” is not itself a gender identity, but is an umbrella category that includes certain men, women, and non-binary and genderfluid people. It simplifies the first question, keeping a shorter list for people to have to scroll through to find the proper term to describe themselves. It also allows organizations to easily modify the list to fit their specific use cases – an organization working in Samoa or with a significant Samoan population could add “fa’afafine” to the list while one dealing with a significant Native/First Nations population could add “two-spirit.”
>
> It also permits trans individuals to interact with the organization without either lying or outing themselves, by not forcing them to select either (for example) “cisgender woman” or “transgender woman.” (If you’re not familiar with the term, ‘cisgender’ is a word indicating a person who is not ‘transgender’.) In fact, it also allows the organization to sort their data in such a way that they don’t unnecessarily out trans people to staff and volunteers, by allowing them to pull a list of all women or all men that doesn’t automatically flag whether or not they are transgender.
>
> In addition, it reflects the fact that not all non-binary and genderfluid people consider themselves to fit under the “transgender” umbrella – this is a complicated issue that’s largely unknown outside of the larger LGBTQ community, and is often disregarded by organizations working with these communities.
>
> Finally, it flags the most useful information – what pronouns to use when referring to the person – into a separate easy to reference field that can be included on a display screen or other record without being specifically tied to someone’s transgender status.
>
> Of course, this is only scratching the surface of the issues that might be relevant to a specific organization’s needs. For instance, they should also consider having a separate “legal name” and “preferred name” field – the former is something that would only be referenced when writing checks or otherwise transacting business in the person’s legal name, but have the “preferred name” be what actually displays for all other interactions with the person. This would also allow cisgender people who primarily go by a short form, initials, or nickname to have that be displayed instead of their full name.
>
> A medical organization, meanwhile, might need to collect information on whether or not someone is intersex, or what their “gender assigned at birth” is, and there can be a lot of ways to capture this information based on how the organization interacts with its staff and patients.
>
> For additional discussion on collecting SOGI data, with multiple examples, please take a look at these resources:
>
> https://www.thetrevorproject.org/wp-content/uploads/2021/07/Measuring-Youth-Sexual-Orientation-and-Gender-Identity.pdf
>
> https://williamsinstitute.law.ucla.edu/quick-facts/survey-measures/JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/544Contact Subtype field at Reports does not support contacts with multiple subt...2024-01-16T05:03:26ZscardiniusContact Subtype field at Reports does not support contacts with multiple subtypesHow to reproduce:
* open "Reports > Contact Reports > Constituent Summary" report
* click "Filters" tab
* select "Is one of" for "Contact Subtype" field
* choose subtype "Student"
* click "Refresh results" button
* look at results: Ther...How to reproduce:
* open "Reports > Contact Reports > Constituent Summary" report
* click "Filters" tab
* select "Is one of" for "Contact Subtype" field
* choose subtype "Student"
* click "Refresh results" button
* look at results: There are contacts which have only one subtype "Student"
* click "Developer" tab
* look at WHERE clause `contact_civireport.contact_sub_type IN ('Student')`
This condition should looks like this:
`contact_civireport.contact_sub_type LIKE '%Student%'`https://lab.civicrm.org/dev/core/-/issues/4895Can't delete unused financial types2024-01-15T11:38:54ZJonGoldCan't delete unused financial typesOverview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial typ...Overview
----------------------------------------
Not a regression!
Financial types associated with quick config price sets can never be deleted.
Reproduction steps
----------------------------------------
1. Create a new financial type.
1. Create a new event.
1. Select the financial type as the default for the event and save.
1. Delete the event.
1. Delete the financial type.
Current behaviour
----------------------------------------
Obtuse error.
```
The following tables have an entry for this financial type: CRM_Price_DAO_PriceSet, CRM_Price_DAO_PriceFieldValue
```
Expected behaviour
----------------------------------------
Financial type should be deletable.
When the warning `Deleting this event will also delete associated Event Registration Page and Event Fee configurations. This action cannot be undone. Do you want to continue?` appears - continuing should delete the price set if it's a quick-config. But since I hope quick config dies a painful death, let's generalize to "deleting an event
Comments
----------------------------------------
Tangentially - you can't delete a price set that has any payments associated with it. This should be doable IMO and I believe is an artifact of pre-CiviAccounts (Civi 4.3) behavior when line items didn't exist.https://lab.civicrm.org/dev/core/-/issues/4908Integrate Angular calendar for better usability2024-01-15T11:36:56ZshaneonabikeIntegrate Angular calendar for better usabilityI don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-...I don't mind the existing calendar date picker, but I was wondering if there are other solutions that might work a bit better for usability. I came across this [Angular version](https://laros.io/using-angular-material-calendar-with-date-ranges-and-range-presets) (maybe there is an alternative)
Since we are already starting to use a lot of Angular I thought it could be something to consider. There is even a date range option, which could be interesting for other areas.
You can spin a demo on this stackblitz https://stackblitz.com/edit/angular-material-calendar-with-date-ranges-and-presets?file=package.json
What I like about it:
* When choosing a different year it automatically prompts to choose the month which is fairly logical and usable
* There is the possibility to set ranges (future integration with Events?)
* There is the option to have quick options like Last 30 days, Last 12 months, etc.
![Angular Material Calendar with Date Range and Range Presets](https://laros.io/images/angular-material-calendar-date-range.png)
Anyway it was just something I wanted to raise but it's not a high priority but could be a great enhancement.https://lab.civicrm.org/dev/core/-/issues/3404Should back-end users be able to add event registration selections for sold o...2024-01-15T05:03:37ZlarsssandergreenShould back-end users be able to add event registration selections for sold out price set items?Currently, if a price set selection is sold out, back-end users can add this selection on Events - Register Event Participant or from search, but if they edit a existing registration (e.g. from the Contact record, Events, View, Change Se...Currently, if a price set selection is sold out, back-end users can add this selection on Events - Register Event Participant or from search, but if they edit a existing registration (e.g. from the Contact record, Events, View, Change Selections) they cannot either add or subtract from sold out selections as these are disabled/frozen.
Obviously, back-end users should be able to remove registrants from sold out selections and both of these forms should work in the same way for adding registrations (i.e. either you should or shouldn't be able to add registrants to sold out items on both).
I think back-end users should also be able to add registrants to sold out price set selections. There could be many reasons for orgs to want to enabled their staff to add event registrants to selections (special treatment for VIPs, entering paper registrations, etc). I propose to unfreeze these fields on the Change Selections form, but keep the "Sold out" text so that back-end users can see these selections are sold out, at the same time adding "Sold out" text on the Events - Register Event Participant form.
With this change, staff will be able to see a selection is sold out, but make the choice to add a registrant nonetheless. The work around we use currently is to temporarily increase the price set selection limit and then decrease it again after adding the selection, but this is awkward and not obvious.
I think this could be accomplished by moving the [check here from the registration form](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/CRM/Event/Form/Registration/Register.php#L764) to [here in the price field](https://github.com/civicrm/civicrm-core/blob/35093fbff08842016c1ef01042e225b9cb5ffec2/CRM/Price/BAO/PriceField.php#L353). I will submit a PR if supported.https://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/3396Provide wysiwyg editor for confirmation email text2024-01-14T05:03:28ZthemakProvide wysiwyg editor for confirmation email textProvide wysiwyg editor for event confirmation emails.
Issue before was that switching to wysiwyg affects previously plain text confirmation emails.
Possible solutions
- Provide the option as a toggle
- develop some sort of translator/...Provide wysiwyg editor for event confirmation emails.
Issue before was that switching to wysiwyg affects previously plain text confirmation emails.
Possible solutions
- Provide the option as a toggle
- develop some sort of translator/convertor for the plain text to wysiwyg transition and make wysiwyg default option.
For reference:
https://github.com/civicrm/civicrm-core/pull/13976
https://civicrm.stackexchange.com/questions/21255/confirmation-email-providing-a-wysiwyg-so-users-can-add-html-ified-contenthttps://lab.civicrm.org/dev/core/-/issues/3389Implement tests for Event Registration pages2024-01-11T05:03:25Zmattwiremjw@mjwconsult.co.ukImplement tests for Event Registration pages`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a n...`CRM/Event/Form/Registration/Register.php` needs to be refactored like `CRM/Contribute/Form/Contribution.php` so that we can implement tests on submit.
`CRM_Event_Form_Registration_Register::postProcess()` needs splitting up to call a new function `CRM_Event_Form_Registration_Register::submit()`.
Then we need to add `CRM_Event_Form_Registration_Register::testSubmit()` and write some tests to call this function.https://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/3358Add option to include guest information in back-office confirmation emails2024-01-07T05:03:23ZJKingsnorthAdd option to include guest information in back-office confirmation emailsProblem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any '...Problem: when you send a confirmation email from the back-end after registering a participant, or editing their booking, it only includes the information for the 'current' participant (ie, just the lead booker). It does not include any 'additional participants' (guests) linked to their registration.
Solution: suggested CiviCRM core patch to add a checkbox to 'include guest information' for confirmation emails for participants that have guests attached to them. This would include the guest information int he email, as though it was from a front-end booking.
ie: IF the booking has additional participants, display a new checkbox:
![image](/uploads/2dbec13b633d9be6e880c2fb255a4b80/image.png)
If the checkbox is ticked, then add in the guest information, in the same way as a 'front-end' registration would add their information.https://lab.civicrm.org/dev/core/-/issues/3345Selections information not visible when editing participant record from find ...2024-01-05T05:03:30ZanilSelections information not visible when editing participant record from find participants searchReproduced on https://dmaster.demo.civicrm.org on 1st March 2021 - Version 5.36.alpha1
To reproduce, register a contact for an event with a fee.
Search for this participant via a find participant search and click on edit from the searc...Reproduced on https://dmaster.demo.civicrm.org on 1st March 2021 - Version 5.36.alpha1
To reproduce, register a contact for an event with a fee.
Search for this participant via a find participant search and click on edit from the search results –
![participant_bug](/uploads/95b9fddc4f3f8f97e77274603361d8a4/participant_bug.png)
Correct info appears when you edit directly from the events tab from the contact record.
![participant_bug2](/uploads/3117ada4a296ec9badc687e951a64f7e/participant_bug2.png)https://lab.civicrm.org/dev/core/-/issues/4251Track Contact `image_URL` files in the `civicrm_file` table2024-01-02T21:02:33ZcolemanwTrack Contact `image_URL` files in the `civicrm_file` table# History
**Note: CiviCRM is a large, old project with many contributors, which makes "big picture" perspectives cumbersome to gather. Often a contributor simply wants to fix a bug or add a small feature, not dive into decades-long hist...# History
**Note: CiviCRM is a large, old project with many contributors, which makes "big picture" perspectives cumbersome to gather. Often a contributor simply wants to fix a bug or add a small feature, not dive into decades-long history and contemplate massive refactoring. The story of the `civicrm_contact.image_URL` field is a microcosm of the complicated world of CiviCRM.**
- The `civicrm_contact.image_URL` field (added v1.1) predates the `civicrm_file` table (added v1.5), which may explain why it was originally designed as a simple textfield with no file-management. It is a simple varchar and can store the url to any image file on the web.
- Originally, the UI allowed contact image files to be uploaded to a publicly-readable directory on the webserver, and `image_URL` stored an absolute url to that file.
- In 2014, [security hardening](https://issues.civicrm.org/jira/browse/CRM-14499) led to the addition of an `.htaccess` rule which blocked the contents of that directory from public visibility.
- This accidentally broke contact images, leading to [a rushed fix](https://github.com/civicrm/civicrm-core/pull/3058) which created `CRM_Contact_Page_ImageFile` at `civicrm/contact/imagefile`. This path allows open access to all contact images, but not other files, by querying `civicrm_contact.image_URL` for a matching filename before outputting the contents. An upgrade script rewrote all local `image_URL` fields to point to this path, using an absolute URL. This solution works but is very slow on big databases due to the unindexed query.
- During this rushed fix, it doesn't appear that consideration was given to html escaping of `&` characters. The default behavior of `CRM_Utils_System::url` is to escape `&` to `&` which is (IMHO) a bad default and certainly a poor choice for storing url strings in the database, but it was the default and no one changed it, and then Tim inadvertently cemented it with 065034510d48b722844b2007f8016ea644bd0cbd so now in order to safely read the urls you must pass them through the aptly-named `CRM_Utils_String::unstupifyUrl()` function.
- In 2016 there was an [attempt to fix the absolute URL and performance issues](https://github.com/civicrm/civicrm-core/pull/9237) which updated all the `image_URL` fields to relative paths.
- But this would have broken Drupal Views and other tools that rely on the convenience of querying the field from the db and outputting the url directly (in the future, SearchKit would rely on this too).
- A [compromise solution was reached](https://github.com/civicrm/civicrm-core/pull/9241) which rewrites the url at runtime on Civi pages. A `image_URL` like `http://wp.demo/civicrm/contact/imagefile/?photo=abc.jpeg` would get rewritten to `http://wp.demo/civicrm/file?reset=1&filename=abc.jpeg&mime-type=image/jpeg`. For reasons not entirely clear, this goes through a different internal path (`civicrm/file` instead of `civicrm/contact/imagefile`).
- In 2019, thinking it was unused, [Eileen removed support](https://github.com/civicrm/civicrm-core/commit/2762985c11e01ede473d86a33af279bc341f9a46) for passing `filename=` into the `civicrm/file` path, since that endpoint is typically supplied with a file id from the `civicrm_file` table plus a security hash.
- This accidentally broke contact images, leading to [a rushed fix](https://github.com/civicrm/civicrm-core/pull/13663) which added back the ability to get files by name from the `civicrm/file` path (since contact images are not tracked in `civicrm_file` and don't have an `id`). With the benefit of the history laid out above, a better fix might have been to switch to using the `civicrm/contact/imagefile` path and keep the `civicrm/file` path secure.
- In 2021 [I proposed adding](https://lab.civicrm.org/dev/core/-/issues/2755) an `image_file_id` FK field to the `civicrm_contact` table to track uploaded files. This proposal was met with approval, but when I recently tried to implement it I realized that the `civicrm_file` table already has an FK to `civicrm_contact` and circular references are not allowed.
- In 2023 [an option group was added](https://github.com/civicrm/civicrm-core/pull/25904) for the previously unused column `civicrm_file.file_type_id`. One possible use for that field would be to designate a file type of `"contact_image"`.
# Current Situation
The `civicrm_contact.image_URL` field can still store any url string pointing to a file on or off the server. It could point to any image on the internet, and would work fine. But if it's a file uploaded via the Civi UI, it will be an absolute link pointing to the `civicrm/contact/imagefile` path with a `photo=filename` argument. If CiviCRM recognizes this pattern it will rewrite it on core pages to the other path at `civicrm/file`, otherwise it will leave it alone.
For the confused, yes contact images are accessible at two paths, and neither is a direct link to the file on disk:
| Path | `civicrm/contact/imagefile` | `civicrm/file` |
| ------ | ------ | ------ |
| Class | `CRM_Contact_Page_ImageFile` | `CRM_Core_Page_File` |
| Permission | _none_ | "access uploaded files" |
| Args | `photo` | `filename`, `mime-type` |
| Uses | Stored in `image_URL` field as absolute URL. Output by Views & SearchKit | `image_URL` rewritten to this path on Civi pages for logged-in users |
**This situation leads to the following quirks and problems**
1. The absolute url to `civicrm/contact/imagefile` works great in Views and SearchKit... as long as the site name never changes! Otherwise, absolute URLs are a pain.
2. The url is still stored with html-escaped `&` characters that must be unstupified.
3. Anyone can access a contact image via the 1st path if they know the filename, however, the 2nd has a permission check which means logged-in users without "access uploaded files" cannot see contact images even though anonymous users can!
4. The security hash usually required by `civicrm/file` can be circumvented if you know the filename and mime-type. But the risk is mitigated by that path requiring "access uploaded files" permission.
5. There is still no file-management of contact images. Deleting a contact does not delete their image file. Deleting or changing a contact image also doesn't delete the old one.
# Proposal for File Management
1. Stop using `civicrm/file` for all contact images and [restore the patch to remove support for `filename`](https://github.com/civicrm/civicrm-core/commit/2762985c11e01ede473d86a33af279bc341f9a46).
2. Include `cid` as an argument to `civicrm/contact/imagefile` (and update stored paths accordingly) to fix the unindexed query. Also add `is_deleted = 0` to the query.
3. Add an option_value `"contact_image"` to the option group for `civicrm_file.file_type_id`.
4. When uploading a new contact image, create a record in `civicrm_file` table, and designate it `file_type_id` = `"contact_image"`.
5. Also create a record in `civicrm_entity_file` for contact images.
6. Add a virtual APIv4 field for the contact entity `image_file_id` which would allow getting/setting the file id. When setting a new file id, regenerate the `image_URL` with a post hook.
# Thoughts on Absolute URLs
All of these changes would result in better file management, but still doesn't solve the absolute url issue. This is tricky to solve because Views and SearchKit still rely on being able to output the image url directly from a query. Here are a few ideas for that one:
1. Bite the bullet and update all `image_URL` fields pointing to a local file to use a relative URL. SearchKit will still work. Views and other SQL-based tools will still work unless embedded on a remote site. Random offsite images will be unaffected.
2. Keep `image_URL` absolute but add an APIv4 virtual field like `Contact.image` which calculates the url at runtime. This satisfies moree use-cases but at the expense of adding complexity to an already overcomplicated situation.https://lab.civicrm.org/dev/core/-/issues/1402Inconsistent behaviour when paying/completing a pending contribution with lin...2023-12-30T05:03:27ZJamie Novick - CompucoInconsistent behaviour when paying/completing a pending contribution with linked membershipOverview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applie...Overview
----------------------------------------
CiviCRM has inconsistent behaviour when completing a pending contribution with linked pending membership either by a) completing the contribution or b) recording a payment.
This applies to both a "new/pending" membership or when renewing an expired membership.
Reproduction steps
----------------------------------------
Scenario 1: New membership
----------------------------------------
Create a membership with start date 1/1/2019 and term 1 year.
Set the membership status to anything.
Set the contribution status to pending.
Save
Scenario 1.1: Record payment
If you completed the payment using “Record Payment” and no matter what you set the receive date to during completing the payment the end date and the start date will remain the same (start date = 1/1/2019 , end date = 31/12/2019).
Scenario 1.2: “Edit Contribution -> change status to completed"
While completing the payment using “Edit Contribution -> change status to completed” will result in changing the membership start date to equal the contribution receive date and the end date to be 1 term away from the receive date, so if you set the receive date for example to 1/3/2019 then the start date will become 1/3/2019 and the end date 29/2/2020
Scenario 2. Renew membership that has expired (end date in the past)
----------------------------------------
Create a membership with start date 1/1/2018 and term 1 year.
Set the membership status to anything. It will be created as an expired membership.
Set the contribution status to completed.
Save
Scenario 2.1: Record payment
If you complete the renewal pending payment using “Record Payment” option, then no matter what you set the payment receive date to, the start date will change to “today's date” and the end date will be one 1 term after the start date
Scenario 2.2: “Edit Contribution -> change status to completed"
If you complete the payment with “edit contribution -> change status to completed” then also here Civi ignores the the receive date and it will always set the start date to “today's date” and the end date to 1 term after the start date.
Expected behaviour
----------------------------------------
Well, they should at least be consistent... but perhaps this is our opportunity to make CiviCRM less opaque and give users control over how the system should work?
| Scenario no | Situation | Recording payment approach | Current behaviour | Suggested behaviour |
| ------ | ------ | ------ | ------ | ------ |
|1.1| New | Record payment | Start date will remain as before | Message 1 below
|1.2| New | Edit Contribution -> change status to completed | Changes the membership start date to equal the contribution receive date | Message 1 below
|2.1| Renew expired | Record payment | The start date will change to “today's date” and the end date will be one 1 term after the start date | Message 2 below
|2.2| Renew expired | Edit Contribution -> change status to completed | Set the start date to “today's date” and the end date to 1 term after the start date. |Message 2 below
Message 1:
Show a message / popup to tell ask the user "The membership payment has been made in full, but the membership's start date is different to the payment date. Would you like to set the membership start date to the payment date?
1. Option 1: Yes - Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 2: No - Do not change the membership start date (**Show the existing start date**)
Message 2:
Show a message / popup to tell ask the user "The membership payment has been made in full. Please select a start date:
1. Option 1: Set Membership Start Date to the previous membership term end date
1. Option 2: Set Membership Start Date to the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
1. Option 3: Create a new membership line with Membership start date on the payment date (**Show the proposed start date if using the payment date**) This would be the date of the last payment if recording the payment OR the contribution received date if completing the contribution by changing the status.
In future we could allow admin to have a setting to set the defaults and hide the message to define the behaviour.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __CiviCRM:__ _Master/5.21 etc
Comments
----------------------------------------
This isn't the place for the long discussion about it but just to reiterate that I think the contribution "received" date field needs the label changed to be something more generic like "contribution date" as the field is used as the invoice date when generating an invoice (and cannot mean received date when the contribution is pending...). It also leads to inconsistencies with the above - the date of the last payment could be different from the contribution received date which is a meaningless statement. We should decouple "payment" from the order or invoice object (the contribution) and make the payments mean what they mean - when we got the payment - and the order/invoice mean what is means - when the contact entered into the obligation to pay from an accounting perspective.
Oh well seems I started a discussion on that here: https://lab.civicrm.org/dev/core/issues/1403#note_27422 and a decision on how the above should work should be done once the contribution date field usage is confirmed.https://lab.civicrm.org/dev/core/-/issues/3212Participant Listing report filters incorrectly on role ID2023-12-24T05:03:20ZJonGoldParticipant Listing report filters incorrectly on role IDThis issue is identical to [CRM-18803](https://issues.civicrm.org/jira/browse/CRM-18803) except that CRM-18803 affected all other CiviReports with fields that stored values separated by `CRM_Core_DAO::VALUE_SEPARATOR`. Those were fixed ...This issue is identical to [CRM-18803](https://issues.civicrm.org/jira/browse/CRM-18803) except that CRM-18803 affected all other CiviReports with fields that stored values separated by `CRM_Core_DAO::VALUE_SEPARATOR`. Those were fixed everywhere else by [this PR](https://github.com/civicrm/civicrm-core/pull/8650). However, since the `where()` in this report is overridden, it has its own copy of the regex which wasn't fixed.
I grepped and confirmed this is the only place where this needs to be fixed, and applied the same regex as the commit above.
To replicate this bug, you need at least ten participant roles. The first one's value should be `1`. Searching on this value will return any participant whose role BEGINS with a `1` (i.e. `10`, `11`, `100`, etc.) rather than just records whose participant role value IS 1.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3209Contribution Details Statistics are multiplied under many circumstances2023-12-22T05:03:25ZJonGoldContribution Details Statistics are multiplied under many circumstancesThis bug was previously identified and fixed as core#655, but the fix only addresses the rows and not the statistics.
In addition to contribution detail rows getting multiplied by soft credits, they can be multipled by any one-to-many `...This bug was previously identified and fixed as core#655, but the fix only addresses the rows and not the statistics.
In addition to contribution detail rows getting multiplied by soft credits, they can be multipled by any one-to-many `JOIN` to the contribution table. Soft credits are one example, but it can also be to a contact's multi-record contact field group, or if you pick a field (like "Credit Card Type") that lives in the financial transaction tables ([first reported on SE](https://civicrm.stackexchange.com/a/28791/12) by @KarinG).
Given that the statistics don't concern itself with any data that's not in `civicrm_contribution`, we can replace the flawed (and potentially CPU-intensive) original query with a list of contribution IDs and only use `FROM civicrm_contribution`.JonGoldJonGoldhttps://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/3203When using the Search Kit and Form Builder to implement a front-end Search Li...2023-12-20T05:03:24Zjustinfreeman (Agileware)When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_1744...When using the Search Kit and Form Builder to implement a front-end Search Listing, how do include a Reset button to clear the search criteria?
Ideally, this button would be displayed AFTER the Search button.
![Screenshot_20211112_174423](/uploads/a065207345c884f41eae014ae25e1a8d/Screenshot_20211112_174423.png)https://lab.civicrm.org/dev/core/-/issues/4813CRM_Report_Form_Activity: Add Employer field, and "contact"-based custom fields2023-12-18T23:06:40ZAllenShawCRM_Report_Form_Activity: Add Employer field, and "contact"-based custom fieldsThis improvement is requested and sponsored by Stuart at Korlon.
We aim to implement the following changes to the CiviCRM core "Activity Detail" report (CRM_Report_Form_Activity):
- add "Current Employer" as an available column (not fi...This improvement is requested and sponsored by Stuart at Korlon.
We aim to implement the following changes to the CiviCRM core "Activity Detail" report (CRM_Report_Form_Activity):
- add "Current Employer" as an available column (not filter), to display with its Display Name, as a link to the employer contact
- auto-include "contact"-based custom fields (currently only "individual"-based custom fields get this treatment)
A PR is forthcoming. If it seems this is not a desirable improvement, please let me know in comments!
(Joinery reference: F#1317)https://lab.civicrm.org/dev/core/-/issues/3193SearchKit: granularity of relative dates2023-12-16T05:03:23ZJonGoldSearchKit: granularity of relative datesConsider the following search:
![Selection_1424](/uploads/5b6824f282ecffd713578876a30e7c3a/Selection_1424.png)
I would expect this, when run on March 14 2022, to find any donations made on or after March 14, 2021.
However, it takes "1 ...Consider the following search:
![Selection_1424](/uploads/5b6824f282ecffd713578876a30e7c3a/Selection_1424.png)
I would expect this, when run on March 14 2022, to find any donations made on or after March 14, 2021.
However, it takes "1 year" rather literally - if I run it at 3pm, it will only catch donations made on March 14, 2021 at or after 3pm. This doesn't match the behavior elsewhere in Civi, where we automatically add a "00:00:00" to the search when setting the beginning date of a search, or "23:59:59" when setting the end date of a search.
**Proposal**: When the interval unit is "Day", "Week", "Month" or "Year" we append the timestamp, much as we do in `CRM_Contact_BAO_Query::dateQueryBuilder()` or `CRM_Report_Form::dateClause()`.https://lab.civicrm.org/dev/core/-/issues/3189Search-kit offer actions when grouped by an entity2023-12-15T05:03:27ZeileenSearch-kit offer actions when grouped by an entityWhen we have a search with an entity as group by we should offer actions for that entity
eg.
```
SELECT contact_id, SUM(total_amount) as totes FROM civicrm_contribution GROUP BY contact_id HAVING totes > 2000;
```
Should have contact...When we have a search with an entity as group by we should offer actions for that entity
eg.
```
SELECT contact_id, SUM(total_amount) as totes FROM civicrm_contribution GROUP BY contact_id HAVING totes > 2000;
```
Should have contact actions & the ability to create a smart groups
See https://github.com/civicrm/civicrm-core/pull/19936
@colemanw