CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2023-07-20T05:03:21Zhttps://lab.civicrm.org/dev/core/-/issues/2402Proposed Updated Phone Types2023-07-20T05:03:21ZcolemanwProposed Updated Phone TypesMotivation/Background
---------
The phone_type option list is somewhat dated and presents options that don't always make sense to modern users. The first two options are "Phone" and "Mobile". Twenty years ago there might have been a mor...Motivation/Background
---------
The phone_type option list is somewhat dated and presents options that don't always make sense to modern users. The first two options are "Phone" and "Mobile". Twenty years ago there might have been a more obvious distinction between the two, but today they are basically synonyms. We should re-label them so that it's clear that the first option means "Landline phone" and the second option means "Phone that can receive SMS". And while we're at it, let's also change their weights since mobile phones are now more common than landlines and should be presented as the first option.
Current Options
--------------
| weight | name | label (EN) |
| ------ | ---------- | ---------- |
| 1 | Phone | Phone |
| 2 | Mobile | Mobile |
| 3 | Fax | Fax |
| 4 | Pager | Pager |
| 5 | Voicemail | Voicemail |
Proposed Options (New Installs)
----------------
_This reverses the order and relabels the first two options, while deleting the last two, as "Pager" and "Voicemail" numbers are rarely used these days (it's an option list so specialized organizations can always add them in)._
| weight | name | label (EN) |
| ------ | ---------- | ----------- |
| 1 | Mobile | Voice & SMS |
| 2 | Phone | Voice Only |
| 3 | Fax | Fax |
Proposed Upgrade
-------------------
DB upgrade would update labels and weights of the first two options. Functionality will not be impacted as the machine names remain the same. The "Pager" and "Voicemail" options will be deleted _only if they are not in use._https://lab.civicrm.org/dev/core/-/issues/2401Unable to include seconds in date format for display2023-06-28T05:03:20Zfreeform.stephUnable to include seconds in date format for displayWe would like to include seconds when viewing date fields in reports, the option "%S" does not work (displays "%S" instead of the seconds value).
Reproduce: on Localization > Date format, change the value of "Date Format: Complete Date ...We would like to include seconds when viewing date fields in reports, the option "%S" does not work (displays "%S" instead of the seconds value).
Reproduce: on Localization > Date format, change the value of "Date Format: Complete Date and Time" from the default "%B %E%f, %Y %l:%M %P" to "%B %E%f, %Y %l:%M:%S %P" and load a report displaying a date column, you'll see something like "January 4th, 2021 3:28:%S PM".
First reported on stack exchange: https://civicrm.stackexchange.com/questions/38869/date-and-hour-format-with-secondshttps://lab.civicrm.org/dev/core/-/issues/2399Add new property to Phone entity to mark a number as a mobile phone or the pr...2023-06-28T05:03:19ZhomotechsualAdd new property to Phone entity to mark a number as a mobile phone or the primary SMS number.Overview
----------------------------------------
_Currently we don't have a straightforward way to say "this is a mobile phone/cell phone number" we have the `phone_type` property but being an option group it's inherently unreliable and...Overview
----------------------------------------
_Currently we don't have a straightforward way to say "this is a mobile phone/cell phone number" we have the `phone_type` property but being an option group it's inherently unreliable and subject to change. If we were looking for a way to say "this phone number is a mobile phone - use it for sending SMS" we're kinda out of luck!_
Current behaviour
----------------------------------------
_We can try to infer whether a phone number is for a cell phone by checking for phone_type but it's unreliable and we can't reliably rely on a single ID designating a mobile phone number (or that any of them do!)_
Proposed behaviour
----------------------------------------
_An explicit property that denotes that a number is a cellphone/mobile number or alternatively a property that denotes that that number is the preferred for SMS e.g `is_smsprimary`._https://lab.civicrm.org/dev/core/-/issues/2397Add 'readonly' attribute to fields in schema2021-07-19T17:19:26ZcolemanwAdd 'readonly' attribute to fields in schemaThis is needed by Afform and SearchKit to know whether a field is appropriate to show to the user.
The goal here is to add 'readonly' to all fields that should *not* be presented as editable on user-facing forms.
Examples of fields tha...This is needed by Afform and SearchKit to know whether a field is appropriate to show to the user.
The goal here is to add 'readonly' to all fields that should *not* be presented as editable on user-facing forms.
Examples of fields that should be considered "readonly"
----
- [x] Contact type (theoretically could be changed, but only under special circumstances and there's an extension for that)
- [x] ID fields
- [x] Contact Hash
- [x] Custom fields marked `"is_view"`
- [ ] FK fields that are not meant to change, e.g. Email.contact_id or Participant.contact_id. (in rare circumstances this field gets updated e.g. during deduping, but it's still not something to present on a typical user-facing form, so I'd consider them `'readonly'`).
- [ ] Any auto-increment fields or autopopulated fields e.g. `'creation_date'`.
- [ ] Any other fields that are typically written to programatically and not shown on forms.seamusleeseamusleehttps://lab.civicrm.org/dev/core/-/issues/2393Settings metadata help_text parameter doesn't work and causes errors if you s...2023-06-27T05:03:25ZDaveDSettings metadata help_text parameter doesn't work and causes errors if you specify it but there's no .hlp fileNot sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting ...Not sure if I'm going to follow this thru but am recording some findings. There's at least 3 things to deal with:
1. There's no facility to specify the title of the help box. This is the easiest since it can compute it from the setting label.
2. CRM.help _does_ support passing a single string as the help content, but you get into quote-hell pretty quickly.
3. The `{help}` plugin which is what generates the `<a>` link that calls CRM.help doesn't have a way to accept a string as the help content, and `{help}` is what SettingForm.tpl uses. \
3.b Related note: the `{help}` plugin behaves differently whether you pass it a title parameter or not. If there's no parameter it expects to find it inside an associated .hlp file.
Earlier related issue: https://lab.civicrm.org/dev/core/-/issues/1920https://lab.civicrm.org/dev/core/-/issues/2390Add hook support for Activity Contact2021-03-21T21:40:18ZyashodhaAdd hook support for Activity ContactCurrently, there is no hook support for Activity Contact.Currently, there is no hook support for Activity Contact.5.37.0yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/2386Support chain-select elements in .setting.php files2023-07-01T05:03:24ZJonGoldSupport chain-select elements in .setting.php filesOverview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Local...Overview
----------------------------------------
As we move to metadata-based settings, we need to support existing use cases such as chain-select.
Example use-case
----------------------------------------
1. Go to **Administer » Localization » Languages, Currencies, Locations**.
1. The `defaultContactStateProvince` setting can't be represented accurately via metadata.
Current behaviour
----------------------------------------
No way to define either an `onclick` value or a chain-select.
Proposed behaviour
----------------------------------------
A new property `chain_select_settings` contains properties that are passed to the `addChainSelect` method.
Comments
----------------------------------------
There's partial support, and I suspect work on this stopped because `addChainSelect` has a syntax that's tangled up in Smarty. I'll submit a PR to be a conversation piece.
This will also need documentation.JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/2385Investigate replacing civicase views with something that is not views2021-12-08T09:00:21ZDaveDInvestigate replacing civicase views with something that is not viewsRelated to https://lab.civicrm.org/dev/core/-/issues/2262.
CiviCase uses mysql views (as opposed to drupal views) and is the only component that does so. I'm not sure if they're still truly needed the way they originally were. In additi...Related to https://lab.civicrm.org/dev/core/-/issues/2262.
CiviCase uses mysql views (as opposed to drupal views) and is the only component that does so. I'm not sure if they're still truly needed the way they originally were. In addition to the issue above, they hardcode activity status id and the number 14 (nothing against the number 14, but hey) making it difficult to override those.
I haven't looked at the full query lately but at one time it had a self-join on the view which was where it was convenient to have the view since at the time you couldn't self-join to temporary tables, which might still be true.5.37.0https://lab.civicrm.org/dev/core/-/issues/2382Allow disabling of confirmation page for paid events2022-10-16T01:24:38ZlarsssandergreenAllow disabling of confirmation page for paid eventsCurrently, a paid event must have a confirmation page. In simple paid event registration cases, it would be sometimes be preferable to skip the confirmation page (and potential drop-off of registrants or confusion from those who don't re...Currently, a paid event must have a confirmation page. In simple paid event registration cases, it would be sometimes be preferable to skip the confirmation page (and potential drop-off of registrants or confusion from those who don't realize that the confirmation page wasn't the end of the process) and simply register the participant directly.
Note that you can skip the confirmation page on a contribution page and this is a very similar situation (people are making a selection and filling in their payment details). We find our supporters are likely to be confused by multiple, verbose pages and the confirmation page definitely adds complexity that isn't needed in some cases. Are there any downsides to giving users the option to set up events without a confirmation page?https://lab.civicrm.org/dev/core/-/issues/2378Status of relationships is not under the control of administrators2023-06-24T05:03:19ZUpperholmeStatus of relationships is not under the control of administratorsOverview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control...Overview
----------------------------------------
As set out in the question below, and the linked comments and answers in the CiviCRM Stack exchange, it is apparent that the status of relationship records is not always under the control of administrators, and nor is it explicit under what circumstances the nature of a given relationship might change.
https://civicrm.stackexchange.com/questions/28465/how-do-relationships-become-disabled
I raised the question nearly two years ago, and since that time there have been a number of responses on the SE site, some of which I find quite surprising. What is evident is that there are circumstances where a given relationship becomes disabled without the explicit knowledge or consent of administrators. As far as I'm aware there are no settings to control these behaviours.
In my own case I look after a site where memberships are a key driver. The members are organisations, and the memberships are configured such than individuals with an employee/employer relationship have the benefit of membership. This includes inclusion on mailing lists which are driven by smart groups, access to member-only content, event discounts, etc.
What I'm seeing is that employee/employer relationships are often disabled, despite the fact that the team that manages the CRM very rarely uses start or end dates for relationships (we rarely have this information). So, when a relationship is created it should stay enabled until such time as it is manually disabled. We'll manually disable a relationship relatively rarely, when we get information that a person has changed jobs or retired, but this is really very infrequent.
What does happen a lot with our system is that records get merged. People register on the site for events, or sign up for a mailing list, etc., and provide inaccurate information which often leads to duplicate records getting created. So there is a regular day to day activity of spotting and merging duplicates. It is therefore my guess - and it is purely guesswork - that it is this act of merging which is leading to relationship records getting disabled.
What should happen:
-------------------------
If there are rules that are working in the background that are leading to relationships getting disabled, and the information in the Stack Exchange post suggests that there are, then these should be:
1. Made explicit in the documentation, and
1. Controls should be provided either in the UI (preferably), or via the civicrm.settings.php file, whereby site administrators can enable or disable these rules of behaviour.
1. Where a suitably privileged user carries out an action that results in a relationship being disabled an on-screen alert should be displayed, with a link to enable the user to override that disablement.
If there are no rules or background systems that are driving these silent disablements, then there's a nasty bug.https://lab.civicrm.org/dev/core/-/issues/2375Feature request, De-duplicate rules for Organisations would be more useful if...2023-06-23T05:03:20Zjustinfreeman (Agileware)Feature request, De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value fieldDe-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Orga...De-duplicate rules for Organisations would be more useful if Organisation Nickname was a multi-value field. Thereby allowing multiple Nicknames (or aliases) for the same organisation to be recorded.
Currently de-duplicate rules for Organisations are limited by up to 5 fields. So if you have Organisation Name, Nickname and Email then there are only two fields remaining to compare, which could be used for two custom (Organisation) Nickname fields. You could possibly have a multi-valued custom field for Nickname 2 - have not confirmed if that works at all for de-duplication.
However, it is more commonplace for Organisations to have multiple different abbreviations and shortened versions, not by some "official" naming standard, but simply because people refer to the Organisation differently with varying spelling and abbreviations. eg. IBM, I.B.M, IBM Inc. IBM Intl.
This is a feature request. Open for discussion about other solutions or implementation.
Agileware Ref: CIVICRM-1666https://lab.civicrm.org/dev/core/-/issues/2372Prevent double clicking submit button2021-03-21T21:41:08Zahed_compucorpPrevent double clicking submit buttonOverview
----------------------------------------
A typical problem with HTML forms that if you click fast enough, you can submit the form twice - or more, mostly if the server response was slow. CiviCRM is no exception.
Reproduction st...Overview
----------------------------------------
A typical problem with HTML forms that if you click fast enough, you can submit the form twice - or more, mostly if the server response was slow. CiviCRM is no exception.
Reproduction steps
----------------------------------------
- Any page that has a standard form - without Ajax. (e.g. Find Contributions or New Contribution or Some of the result actions).
- Click submit button fast enough.
![2021-02-08_16-26](/uploads/4b85a3b6e4b4fd659955b4e61ab267d7/2021-02-08_16-26.png)
Current behaviour
----------------------------------------
Find Contributions
![Peek_2021-02-08_16-06](/uploads/f552cc398264ba3ffc28de6eee7a1ea7/Peek_2021-02-08_16-06.gif)
New Contribution
![Peek_2021-02-08_16-10](/uploads/fe4c0118c1cba067fab6192c9c78000c/Peek_2021-02-08_16-10.gif)
Send Invoice - Search Action
Will send multiple emails.
![Peek_2021-02-08_16-40](/uploads/7020983f5986408972ea564f53f14e48/Peek_2021-02-08_16-40.gif)
Expected behaviour
----------------------------------------
Disable button during submission. Maybe something like Record Contribution (Ajax form Using the jQuery BlockUI Plugin)
![Peek_2021-02-08_16-14](/uploads/24c71d97550650e78b6629e249f9df76/Peek_2021-02-08_16-14.gif)
Any thoughts on this?
PR: https://github.com/civicrm/civicrm-core/pull/196105.36.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2369Fatal error reported when photo cannot be found2021-05-31T15:47:08Zmagnolia61Fatal error reported when photo cannot be foundI use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of cor...I use a profile for people to update their profile picture.
For some reason when their photo is not available anymore the error log logs a fatal error.
Also the reporterror extension sends an email on this but of course that's out of core scope (reported it [there](https://lab.civicrm.org/extensions/reporterror/-/issues/3#note_53134) also)
I have been experiencing this since quite a few versions of CiviCRM back. Currently running 5.34 (Drupal 7.78)
Could it be that the code for this in core is a bit too harsh?
```
[error]
$Fatal Error Details = array:3 [
"message" => "Photo does not exist"
"code" => null
"exception" => CRM_Core_Exception {#3616
-errorData: array:1 [
"error_code" => 0
]
#cause: null
-_trace: null
#message: "Photo does not exist"
#code: 0
#file: "/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php"
#line: 58
trace: {
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Contact/Page/ImageFile.php:58 {
› else {
› throw new CRM_Core_Exception(ts('Photo does not exist'));
› }
}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:312 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:68 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/CRM/Core/Invoke.php:36 { …}
/var/www/vhosts/xyz/web/sites/all/modules/civicrm/drupal/civicrm.module:458 { …}
/var/www/vhosts/xyz/web/includes/menu.inc:527 { …}
/var/www/vhosts/xyz/web/index.php:21 { …}
}
}
]
```5.39.0https://lab.civicrm.org/dev/core/-/issues/2366php 7.4 - get_magic_quotes_gpc() deprecated in IDS_Monitor2021-04-13T00:10:20ZDaveDphp 7.4 - get_magic_quotes_gpc() deprecated in IDS_Monitor`Deprecated function: Function get_magic_quotes_gpc() is deprecated in IDS_Monitor->_detect() (line 338 of ...\vendor\civicrm\civicrm-packages\IDS\Monitor.php).`
Also line 342.
Function will be removed in php 8.
Hmm. This package is v...`Deprecated function: Function get_magic_quotes_gpc() is deprecated in IDS_Monitor->_detect() (line 338 of ...\vendor\civicrm\civicrm-packages\IDS\Monitor.php).`
Also line 342.
Function will be removed in php 8.
Hmm. This package is very old.5.37.0https://lab.civicrm.org/dev/core/-/issues/2258Re-Thinking our Crypto implementation2023-07-09T05:03:24ZseamusleeRe-Thinking our Crypto implementation_Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted wit..._Motivation_:
We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted within the database e.g. Payment Processor Passwords.
_Problems_:
1. Not easily able to determine what Crypto method has been used (Mcrypt or Base64 encoded only) to save the SMTP password.
2. Not easily to assess which extensions have had fields encrypted (e.g. know that Sparkpost has encrypted their API key but other than that unsure)
3. Relies on CIVICRM_SITE_KEY (which is maybe over-using that value).
4. Linked to Item 2, is there is no way for the API/DAO/Extensions to know what fields have been encrypted so to decrypt code appropriately.
_Potential ideas_:
1. Create a setting which stores the encryption class and use a factory / hooks to allow for extensions to customise which crypto library to use within CiviCRM
2. Have a hook / use some level of meta data to determine if a field is to be encrypted
_Discussion Questions_:
1. Should we completely break CRM_Utils_Crypt class as we re-work the encryption within the app
2. How should we handle switching between Crypto libraries?
3. Should extensions be able to use their own Crypto Library whilst leaving rest of the App to use a system specific Crypto?
4. Do we want to allow for civicrm.settings.php defines / environment variable overrides for encrypted fields / data points?https://lab.civicrm.org/dev/core/-/issues/2256create contact: subtype retained after removal2024-02-29T05:03:24Zlcdwebcreate contact: subtype retained after removalTo recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype i...To recreate:
1. create a new contact via the subtype menu (i.e. Contact > New Individual > New Student)
2. fill in the first/last name. deselect the subtype (remove Student)
3. save the form
Expected result: a contact with no subtype is created.
Actual result: the student subtype is retained.
I suspect what's happening is that on form submission the subtype field is getting reset via the URL param.
But it poses a question, as I think there are two ways we could approach this:
1. fix the form per the above. on submission, ensure we process the form field value and don't allow the URL param to reset it.
2. freeze the subtype field. one could argue that if I'm choosing to create a New Student I should be locked into that path. we could check to see if a URL param for subtype was passed and then freeze that field. the downside is that it would prevent you from setting multiple subtypes for the contact.
Would like to get some opinions/thoughts from the community before I work on a patch.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/2208Enforce default country setting globally2023-06-26T05:03:15ZandyburnsEnforce default country setting globallyIf you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used...If you set it here https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 it does set the country field correctly if used in create mode form e.g. within a contribution page but not if used in listings mode.
Noting @JonGold made an extension that solves this: https://civicrm.stackexchange.com/questions/20986/show-default-country-and-state-for-public-proximity-searchhttps://lab.civicrm.org/dev/core/-/issues/2207Allow default fields per profile2023-06-12T05:03:16ZandyburnsAllow default fields per profileFeature request: Allow profiles to set a default form field value at the form level.
One example is I'd like to set the default country to United States. Note that setting your default country under https://example.org/wp-admin/admin.p...Feature request: Allow profiles to set a default form field value at the form level.
One example is I'd like to set the default country to United States. Note that setting your default country under https://example.org/wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin%2Fsetting%2Flocalization&reset=1 does not default it in the profile listings.https://lab.civicrm.org/dev/core/-/issues/2202Confusing note regarding ACLs for events2023-06-03T05:03:28ZfkohrtConfusing note regarding ACLs for eventsOverview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event A...Overview
----------------------------------------
When managing ACLs for Events, users are presented with the following [note](https://lab.civicrm.org/dev/core/-/blob/34d6cec4/templates/CRM/ACL/Form/ACL.tpl#L90-94):
> NOTE: For Event ACLs, the 'View' operation allows access to the event information screen. "Edit" allows users to register for the event if online registration is enabled.
Please remember that Drupal's "register for events" permission overrides CiviCRM's control over event information access.
I find this wording highly confusing for several reasons.
Current behaviour
----------------------------------------
1. Reading `event information screen` I thought only page visits of `/civicrm/event/info` are affected, when in fact, this also concerns the events I see in the backend's event dashboard at `/civicrm/event`. I think I would have correctly guessed what the _View_ permission does without this note.
2. Reading `"Edit" allows users to register for the event if online registration is enabled.`...
1. I thought this has nothing to do with configuring events in the backend, when in fact, this is just exactly that. Again, I find this note more confusing than helpful.
2. I am additionally confused as a user of the [Webform CiviCRM Integration](https://www.drupal.org/project/webform_civicrm) because my participants never use CiviCRM's online registration feature. So I am asking myself “Does this cover my use case as well?” and “Who actually needs the permission to edit in my case?”
3. If I allow anonymous users to access all events on Drupal's permission page and also grant _Edit_ permissions via CiviCRM's ACLs, then those users granted edit rights __do not__ have the right to _View_ other events anymore. The UI does not inform me about this behaviour.
4. Reading `View` and `Edit` I wonder whether the latter includes the former. Would make sense, but I don't know from the UI.
Proposed behaviour
----------------------------------------
1. Maybe this should read `[...] allows access to the event's information.`
2. (see the suggestions below)
1. Maybe add a clause that the _Edit_ permission also allows configuring the event in the backend. But isn't this even more confusing then, because the _Edit_ permission allows event configuration __and__ event registration (two rights that most would think are different)?
2. Maybe add an explanation for those who register their participants through Drupal's Webform module.
3. Maybe add a clause that explains that once any of the _View_ or _Edit_ permissions is given through the ACLs, Drupal's CiviEvent permissions _view event info_ is overriden, even granted for anonymous users (at least that's how I understand it).
4. Maybe add a clause that _Edit_ includes the right to _View_ (if this is the case),
Comments
----------------------------------------
I am using CiviCRM 5.31 on Drupal 8https://lab.civicrm.org/dev/core/-/issues/2189Activity Type cleanup2023-06-15T05:03:16ZJonGoldActivity Type cleanupCurrently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed...Currently, activity types can have a `component_id`, so they're not displayed unless that component is enabled. However, 4 activities definitively tied to components ("Bulk Email", "Mass SMS" for CiviMail; "Downloaded Invoice", "Emailed Invoice" for CiviContribute) don't have a `component_id` assigned.
It also seems that "Meeting" and "Phone Call" are set as `is_reserved`, but there aren't any references to those in the codebase such that disabling or deleting them should affect a Civi install.JonGoldJonGold