Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-03-11T00:09:20Zhttps://lab.civicrm.org/dev/financial/-/issues/141Define return parameters for doPayment2023-03-11T00:09:20Zmattwiremjw@mjwconsult.co.ukDefine return parameters for doPaymentSee #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it'...See #135, https://github.com/civicrm/civicrm-core/pull/18150 and https://github.com/civicrm/civicrm-core/pull/18178
We need to clearly define what the return parameters for `doPayment()` should be as it's important, it's unclear and it's not defined anywhere.
My proposal:
* `doPayment($params)` returns an array.
* It must contain:
* **`payment_status_id`**: **(deprecated)** Numeric value of `Contribution Status` option value Completed or Pending. Eg. 1. Must be set but make sure you set `payment_status` as well because this value will be ignored in the future.
* **`payment_status`**: Text field - Either `Completed` or `Pending`.
* It may contain (and the code that calls `doPayment()` will update these values on the contribution/payment:
* **`trxn_id`**: The transaction ID from the payment processor. This will be recorded in the `Contribution.trxn_id` field and the `Payment.trxn_id` field. We do not return `order_reference` here because that is usually filled in by an IPN callback from the payment processor if required.
* **`fee_amount`**: The amount (in same currency as contribution) of the fee taken by the payment processor for processing the payment.
Historically `$params` was passed by reference. This is deprecated and only the return values should be used.
Ping @eileen @artfulrobot @KarinG5.49.0https://lab.civicrm.org/dev/core/-/issues/4105Import contribution note does not accept emtpy string2023-03-10T23:41:49ZmasettoImport contribution note does not accept emtpy stringOverview
----------------------------------------
If in import contributions I map the field 'Note' and if there are rows with an empty value, I get this error:
**`"Mandatory values missing from Api4 Note::save: note"`**
Reproduction s...Overview
----------------------------------------
If in import contributions I map the field 'Note' and if there are rows with an empty value, I get this error:
**`"Mandatory values missing from Api4 Note::save: note"`**
Reproduction steps
----------------------------------------
1. Click on **Contributions -> Import contributions**.
1. Choose a CSV file. There must be a column for 'Notes'.
1. In Match Fields (step 2 of 3) for the column "Notes" choose "Note"
Current behaviour
----------------------------------------
For rows with emtpy notes I have this error:
**`"Mandatory values missing from Api4 Note::save: note"`**
Expected behaviour
----------------------------------------
It must also accept empty notes.
Environment information
----------------------------------------
* __CiviCRM:__ _5.57.3_
* __PHP:__ _8.1_
* __CMS:__ _Drupal 9_
* __Database:__ _MySQL 5.7.7_5.59.2https://lab.civicrm.org/dev/core/-/issues/4135Regression: Fatal errors in IPNs after loadRelatedObjects refactor2023-03-10T14:35:06ZJKingsnorthRegression: Fatal errors in IPNs after loadRelatedObjects refactor@eileen This refactor causes fatal errors with our IPN-based payment processor : https://github.com/civicrm/civicrm-core/commit/d0a93d4dfc2a771b095f26fa33eb5551d6c9dcdb
I still need to do some more investigation, but the error we see is...@eileen This refactor causes fatal errors with our IPN-based payment processor : https://github.com/civicrm/civicrm-core/commit/d0a93d4dfc2a771b095f26fa33eb5551d6c9dcdb
I still need to do some more investigation, but the error we see is:
`TypeError: Illegal offset type in CRM_Financial_BAO_PaymentProcessor::getPayment() (line 222 of .../CRM/Financial/BAO/PaymentProcessor.php).`
Which corresponds to the return in:
![image](/uploads/dd002c8675a668f90d75e6ebb20dc9a1/image.png)
Reverting that refactor fixes the issue for us. I'll do some more digging...https://lab.civicrm.org/dev/core/-/issues/1580Allow to search on contribution id2023-03-10T06:17:56ZyashodhaAllow to search on contribution idAllow to search on contribution idAllow to search on contribution id5.28.1yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1705APIv4 - how do I interact with option values???2023-03-10T05:03:23ZeileenAPIv4 - how do I interact with option values???In apiv3 I can filter on an option value by passing in the name. So
```
civicrm_api3('Contribution', 'get', ['contribution_status_id' => 'Pending'])
```
will retrieve me Pending contributions. By the same token the v3 api returns me t...In apiv3 I can filter on an option value by passing in the name. So
```
civicrm_api3('Contribution', 'get', ['contribution_status_id' => 'Pending'])
```
will retrieve me Pending contributions. By the same token the v3 api returns me the status of the contributions.
In the api explorer I don't see a way to do that. I DO see a way to JOIN the optionValue table in - but that literally joins the table in from the looks of so I would wind up with an unindexed join in my query
![Screen_Shot_2020-04-15_at_1.57.36_PM](/uploads/449ed24187e3fbdd5f0bcfdd9c2efc18/Screen_Shot_2020-04-15_at_1.57.36_PM.png)
@colemanw I know you hate the apiv3 double loading but what is the apiv4 expectation here? I really don't want to have to do endless CRM_Core_PseudoConstant::getKey() calls on every line....https://lab.civicrm.org/dev/core/-/issues/4165Basic Auth does not work when AuthX is activated2023-03-09T10:10:55ZMariaVBasic Auth does not work when AuthX is activatedI have found this issue and it seems that this problem occurred again: https://lab.civicrm.org/dev/core/-/issues/3416
It describes the current behavior: All CiviCRM pages error out with "401 Invalid Credential".
When AuthX disabled it w...I have found this issue and it seems that this problem occurred again: https://lab.civicrm.org/dev/core/-/issues/3416
It describes the current behavior: All CiviCRM pages error out with "401 Invalid Credential".
When AuthX disabled it works fine.
CiviCRM Version: 5.58.1 on Wordpress 6.1.1https://lab.civicrm.org/dev/core/-/issues/1727Allow sites to not have Billing Address Location Type2023-03-09T05:03:25ZJoeMurrayAllow sites to not have Billing Address Location TypeOverview
----------------------------------------
Currently CiviCRM has a confusing array of default location types and flags. This issue proposes changes that would allow the Is Billing flag to be the only indication that a location is ...Overview
----------------------------------------
Currently CiviCRM has a confusing array of default location types and flags. This issue proposes changes that would allow the Is Billing flag to be the only indication that a location is the billing location rather than also having a Location Type of Billing. The intent is to allow instances to experiment with simpler approaches to Location Types in order to improve the usability of the product.
Example use-case
Add a hook to allow billing location to be determined by an alternative implementation. Sample LExIM extension approach would return the address which has isBilling==True if there is no LocationType of 'Billing' or if there is no address passed to function with LocationType of 'Billing' from https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Payment/BaseIPN.php#L491
In current places where code creates a 'Billing' type address one potential approach would assume it should be home location type for individual and household contacts and work for organizational contacts. In all cases the Is Billing would still be set. The objective of this proposal is to refactor and introduce hooks in order to allow a LExIM extension to work. More details about specific places in code that need to be changed and ideas on what exactly to do in a simpler approach to be provided if there is potential for this proposal to go forward.
Comments
----------------------------------------
Just testing water for potential support before developing more detailed proposal. Otherwise we'll likely just override core for this particular client.JoeMurrayJoeMurrayhttps://lab.civicrm.org/dev/core/-/issues/1179Default Contact Search Profile should be respected for contact searches2023-03-09T05:03:24ZyashodhaDefault Contact Search Profile should be respected for contact searches*Default Contact Search* Profile should be respected for contact searches including *Edit Smart Group Criteria*.
Steps to replicate :
* Create a profile configured to be used in *Search Views*.
* Make this profile as *Default Contact S...*Default Contact Search* Profile should be respected for contact searches including *Edit Smart Group Criteria*.
Steps to replicate :
* Create a profile configured to be used in *Search Views*.
* Make this profile as *Default Contact Search Profile*.
* Go to Basic, Advanced Search/Builer, all the results have profile fields listed as column headers if use force=1.
![adv_force](/uploads/278a0cbf0c9107c3ea326218821b36da/adv_force.png)
* Create a smart search and go to Contacts and use force=1. Profile fields not shown.
![smart_group](/uploads/9f76dc3c1d961181bd713624392dcc9d/smart_group.png)yashodhayashodhahttps://lab.civicrm.org/dev/core/-/issues/1460How best to handle Event Dispatchers during upgrade2023-03-08T05:03:30ZseamusleeHow best to handle Event Dispatchers during upgradeAs shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discu...As shown by #1449 and in PRs https://github.com/civicrm/civicrm-core/pull/13551 and https://github.com/civicrm/civicrm-core/pull/16034 there have been shown issues with dispatching most hooks when in upgrade mode, this ticket is to discuss the best ways forward and if we need to move the whitelisting or similar to the dispatcher or elsewhere ping @eileen @tottenhttps://lab.civicrm.org/dev/core/-/issues/1734Remove `profile listings and forms` permission2023-03-08T05:03:29ZwmortadaRemove `profile listings and forms` permissionOverview
----------------------------------------
The `profile listings and forms` permission is shorthand for four other permissions relating to profiles - `profile create`, `profile edit`, `profile listings`, `profile view`.
I'm guess...Overview
----------------------------------------
The `profile listings and forms` permission is shorthand for four other permissions relating to profiles - `profile create`, `profile edit`, `profile listings`, `profile view`.
I'm guessing that there was a historic reason for this but I think it is confusing and potentially leaves sites less secure as a result. I propose that it is removed. Instead each of the four permissions are set individually as required.
Current behaviour
----------------------------------------
There are five permissions relating to profiles:
* `profile create`
* `profile edit`
* `profile listings`
* `profile view`
* `profile listings and forms`
The latter is a catch all for the other four.
Proposed behaviour
----------------------------------------
There are four permissions relating to profiles:
* `profile create`
* `profile edit`
* `profile listings`
* `profile view`
As part of the upgrade process the user is prompted to review permissions and ensure that any user roles that currently have the `profile listings and forms` permission are given each of the above permissions.
Comments
----------------------------------------
The reason I have raised this issue is that it was unclear to me what each of these permissions were four. Following some discussion, I have made [some](https://github.com/civicrm/civicrm-user-guide/issues/355) [proposals](https://github.com/civicrm/civicrm-user-guide/pull/441) to improve the documentation but think it would be better if this permission were just removed.
The permissions are defined in [CRM/Core/Permission.php](https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/Permission.php#L289-L326).
I've found two uses of this permission in core:
* [CRM/Contact/BAO/Contact.php](https://github.com/civicrm/civicrm-core/blob/363ce69adee8c277d94d9b31ef3ca8782db9394f/CRM/Contact/BAO/Contact.php#L3672)
* [CRM/Core/BAO/UFGroup.php](https://github.com/civicrm/civicrm-core/blob/4cef91ce8a2df4c34ac30fc05a61900ffb046e6f/CRM/Core/BAO/UFGroup.php#L1290)
And one in CiviVolunteer:
* [api/v3/VolunteerUtil.php](https://github.com/civicrm/org.civicrm.volunteer/blob/master/api/v3/VolunteerUtil.php#L176)
(There may be more, but these are the ones I've spotted.)https://lab.civicrm.org/dev/core/-/issues/4150Formbuilder: Contact Reference doesn't respect the Filter options and exposes...2023-03-07T19:59:37ZshaneonabikeFormbuilder: Contact Reference doesn't respect the Filter options and exposes all Contacts## Problem
Creating a Form (via Formbuilder) that uses a Contact Reference exposes all Contacts in the search field rather than respecting the Filter conditions.
## How to reproduce
1. Create a set of Custom Fields one of which that h...## Problem
Creating a Form (via Formbuilder) that uses a Contact Reference exposes all Contacts in the search field rather than respecting the Filter conditions.
## How to reproduce
1. Create a set of Custom Fields one of which that has a Contact Reference with a Filter by a Group
2. Create a Formbuilder Form and add the Contact Reference field
3. Test the form, and see that all Contacts are searchable
## Expected Result
Formbuilder should use the appropriate filters set by the Contact Reference rather than exposing all users.https://lab.civicrm.org/dev/core/-/issues/4163FormBuildeR: Can't set participant status type2023-03-07T18:51:22ZJonGoldFormBuildeR: Can't set participant status typeSee screenshot. When you try to use this field, you get the error "API (ParticipantStatusType, autocomplete) does not exist (join the API team and implement it!)".
![Selection_1801](/uploads/34d14ba7259e8878f93a910627b2c151/Selection_1...See screenshot. When you try to use this field, you get the error "API (ParticipantStatusType, autocomplete) does not exist (join the API team and implement it!)".
![Selection_1801](/uploads/34d14ba7259e8878f93a910627b2c151/Selection_1801.png)
I've seen other "Loading failed" errors handled like in https://github.com/civicrm/civicrm-core/pull/25598 but I suspect we might actually want to create the API here?https://lab.civicrm.org/dev/core/-/issues/4161Regression: Visiting contribution page while logged in and CiviMember is disa...2023-03-07T05:54:51ZJonGoldRegression: Visiting contribution page while logged in and CiviMember is disabled causes a fatal error.Overview
----------------------------------------
This one is my fault. PR is https://github.com/civicrm/civicrm-core/pull/25729.
Reproduction steps
----------------------------------------
1. Disable CiviMember.
1. Visit a contributio...Overview
----------------------------------------
This one is my fault. PR is https://github.com/civicrm/civicrm-core/pull/25729.
Reproduction steps
----------------------------------------
1. Disable CiviMember.
1. Visit a contribution page whilel logged in.
Current behaviour
----------------------------------------
```
Civi\API\Exception\NotImplementedException: Membership API is not available because CiviMember component is disabled in /home/jon/local/mysite/web/wp-content/plugins/civicrm/civicrm/Civi/Api4/Generic/AbstractAction.php on line 454
```
Expected behaviour
----------------------------------------
No fatal error.
Comments
----------------------------------------
I replaced code that used the BAO to look up membership info with a call to a shared function that uses API4. However, API4 will throw an error if you access a disabled entity.5.59.1JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/41555.59 upgrade brings down entire site if multilingual is enabled2023-03-07T05:52:57ZJonGold5.59 upgrade brings down entire site if multilingual is enabledTo replicate, have a Civi 5.58 site, enable multilingual, and upgrade to 5.59.
You'll start seeing WSODs with `DB Error: -32`. My further research found `ERROR 1054 (42S22): Unknown column 'nasco_dev_civi.civicrm_custom_field.mask' in '...To replicate, have a Civi 5.58 site, enable multilingual, and upgrade to 5.59.
You'll start seeing WSODs with `DB Error: -32`. My further research found `ERROR 1054 (42S22): Unknown column 'nasco_dev_civi.civicrm_custom_field.mask' in 'field list'`.
Because the custom field table is multilingual-enabled, and the multilingual views seem to not be rebuilt (or rebuilt after the `mask` column is dropped), the views reference a non-existent field and everything stops working.
For folks who already upgraded and are in this situation, you have some options:
If you can run API commands from the command line, you can run `System.rebuildmultilingualschema`, e.g.:
```
cv api System.rebuildmultilingualschema
drush cvapi System.rebuildmultilingualschema
wp civicrm api System.rebuildmultilingualschema
```
NOTE: The above approach worked temporarily for me, but then stopped working. However, I'm not sure if my further testing affected this.
This second approach is less well-tested, but you made a backup before you upgraded...right? If not, back up now:
* Identify the views associated with `civicrm_custom_field` - e.g. `civicrm_custom_field_en_US`, `civicrm_custom_field_es_MX`, etc.
* Run the following commands once per language you have installed. In this command, I'm fixing `_en_US`. Run this once per language, doing a search/replace on the text below to change out `en_US` for your languages. E.g. I have `en_US` and `es_MX`, so I ran this once unmodified, then did a search/replace for `en_US` to `es_MX`.
```
DROP VIEW civicrm_custom_field_en_US;
CREATE VIEW `civicrm_custom_field_en_US` AS select `civicrm_custom_field`.`id` AS `id`,`civicrm_custom_field`.`custom_group_id` AS `custom_group_id`,`civicrm_custom_field`.`name` AS `name`,`civicrm_custom_field`.`data_type` AS `data_type`,`civicrm_custom_field`.`html_type` AS `html_type`,`civicrm_custom_field`.`default_value` AS `default_value`,`civicrm_custom_field`.`is_required` AS `is_required`,`civicrm_custom_field`.`is_searchable` AS `is_searchable`,`civicrm_custom_field`.`is_search_range` AS `is_search_range`,`civicrm_custom_field`.`weight` AS `weight`,`civicrm_custom_field`.`attributes` AS `attributes`,`civicrm_custom_field`.`javascript` AS `javascript`,`civicrm_custom_field`.`is_active` AS `is_active`,`civicrm_custom_field`.`is_view` AS `is_view`,`civicrm_custom_field`.`options_per_line` AS `options_per_line`,`civicrm_custom_field`.`text_length` AS `text_length`,`civicrm_custom_field`.`start_date_years` AS `start_date_years`,`civicrm_custom_field`.`end_date_years` AS `end_date_years`,`civicrm_custom_field`.`date_format` AS `date_format`,`civicrm_custom_field`.`time_format` AS `time_format`,`civicrm_custom_field`.`note_columns` AS `note_columns`,`civicrm_custom_field`.`note_rows` AS `note_rows`,`civicrm_custom_field`.`column_name` AS `column_name`,`civicrm_custom_field`.`option_group_id` AS `option_group_id`,`civicrm_custom_field`.`filter` AS `filter`,`civicrm_custom_field`.`in_selector` AS `in_selector`,`civicrm_custom_field`.`serialize` AS `serialize`,`civicrm_custom_field`.`label_en_US` AS `label`,`civicrm_custom_field`.`help_pre_en_US` AS `help_pre`,`civicrm_custom_field`.`help_post_en_US` AS `help_post` from `civicrm_custom_field`
```5.59.1https://lab.civicrm.org/dev/core/-/issues/1733CiviCRM: access CiviCRM backend and API does not appear to be sufficient to c...2023-03-07T05:03:25ZspalmstromCiviCRM: access CiviCRM backend and API does not appear to be sufficient to call API4Overview
----------------------------------------
Code calling API4 appears to fail with 'Authorization Failure' though the user has CiviCRM: access CiviCRM backend and API privileges. Replacing the call with one to API3 resolves the pr...Overview
----------------------------------------
Code calling API4 appears to fail with 'Authorization Failure' though the user has CiviCRM: access CiviCRM backend and API privileges. Replacing the call with one to API3 resolves the problem.
Reproduction steps
----------------------------------------
1. Create code calling API4.
1. Log in as a user with CiviCRM: access CiviCRM backend and API privileges but no more.
1. Got 'Authorization failed'.
Current behaviour
----------------------------------------
See above.
```
Expected behaviour
----------------------------------------
Successful call
Environment information
----------------------------------------
Joomla 3.9.18, but I don't think this is relevant.
CiviCRM 5.24.5
Comments
----------------------------------------
We noticed this when we created some custom tokens in CiviMail using hooks and discovered that administrators could send the mail but non-administrators could not. There could, of course, be coding issues in the hook, but the API experts would be better at checking the API code than I am.https://lab.civicrm.org/dev/core/-/issues/1736Contribution Pay Later Invoice sent "To:" On-Behalf-Of Organization rather th...2023-03-07T05:03:23ZelilisseckContribution Pay Later Invoice sent "To:" On-Behalf-Of Organization rather than ContributorOverview
----------------------------------------
When a contributor makes a "pay later" donation "On Behalf Of" an organization (for example, they need an invoice sent to generate funds, they need to send a physical check, etc), the "re...Overview
----------------------------------------
When a contributor makes a "pay later" donation "On Behalf Of" an organization (for example, they need an invoice sent to generate funds, they need to send a physical check, etc), the "receipt/invoice" email is sent "To:" the Organization's email address instead of the contributor.
The contributor is CC'd, but plenty of times the organization is new (being created in that form with no email address in the on-behalf-of profile), or the organization selected has no email address recorded... so no receipt/invoice email is sent at all.
This is problematic because the thank-you page states the email confirmation goes to the contributor, and the contributor will not receive essential information to complete the on-behalf-of donation.
Reproduction steps
----------------------------------------
Reproduced on 5.26.alpha1
1. Create a donation page with "on behalf of" and "pay later" both enabled
2. Disable the email field in the default "on behalf of" profile
3. Go through an "on behalf of" form submit with "pay later"
4. Observe statement that instructions will be sent to the contributors email address
5. Observe no receipt/invoice email sent
Current behaviour
----------------------------------------
Currently, on-behalf-of receipts are sent "To:" the organization email address, and CC'd to the contributor email address. If there is no organization email address for whatever reason, no invoice is sent.
Expected behaviour
----------------------------------------
I would expect the receipt/invoice to be sent to the contributor no matter what. We could get at this in a variety of ways:
1) Switch the targets around so "To:" is always the contributor and "CC" is the on-behalf-of organization
2) Switch the target so "To:" is the contributor only if "To:" is empty
3) Fire off two emails, one "To:" each contact involved if there is a "related_contact" in the form, getting rid of the CC all together
I would probably opt for 3 - but I don't know all of the context of the CC here.
**EDIT**: Here is an example of what option 3 might look like: https://github.com/civicrm/civicrm-core/pull/17185https://lab.civicrm.org/dev/core/-/issues/1730Allow extensions to skip entity operations by catching exceptions thrown in p...2023-03-06T05:03:25ZjensschuppeAllow extensions to skip entity operations by catching exceptions thrown in pre and post hooksOverview
----------------------------------------
Extensions should be able to skip actions performed on entities with a warning/error message. `hook_civicrm_pre()` and `hook_civicrm_post()` implementations do not allow for skipping alto...Overview
----------------------------------------
Extensions should be able to skip actions performed on entities with a warning/error message. `hook_civicrm_pre()` and `hook_civicrm_post()` implementations do not allow for skipping altogether, but only for altering parameters.
Example use-case
----------------------------------------
The [de.systopia.donrec](https://github.com/systopia/de.systopia.donrec) extension forbids contributions be deleted when they have been legally receipted, since allowing deletion of such contributions would be considered fraudulent behavior by tax authorities.
Current behaviour
----------------------------------------
Currently, exceptions thrown in implementations of those hooks produce fatal errors, which, when run via Ajax, appear to "hang the system", because the XHR returns a 500. There is no way for extensions to skip such an action in a way that would be handeled by the UI.
Proposed behaviour
----------------------------------------
`hook_civicrm_pre()` and `hook_civicrm_post()` implementations should be able to skip execution of the current action (e.g. deleting an entity). The invoking code should therefore catch exceptions thrown by those implementations. This would allow for displaying exception messages as error message popups in the UI.
Comments
----------------------------------------
I'm not sure whether this can be done generically or would have to be implemented separately for each caller. I guess it's the latter. In that case, consider this issue as a discussion starter for whether this is desirable to include in CiviCRM Core.https://lab.civicrm.org/dev/core/-/issues/1732Anonymous user given different permissions depending on CMS2023-03-06T05:03:24ZwmortadaAnonymous user given different permissions depending on CMSOverview
----------------------------------------
The initial set of permissions given to the anonymous user appears to be inconsistent across CMSs. I discovered this when trying to [update the documentation on permissions](https://githu...Overview
----------------------------------------
The initial set of permissions given to the anonymous user appears to be inconsistent across CMSs. I discovered this when trying to [update the documentation on permissions](https://github.com/civicrm/civicrm-user-guide/pull/441) in the user guide.
I think it would be better if there were a consistent set of permissions that were set regardless of CMS. This would make it clearer for users when they first install CiviCRM and look at the documentation on permissions.
Current behaviour
----------------------------------------
The initial permissions for the anonymous user are different depending on which CMS you use.
These are the permissions on a site freshly created via `buildkit`. These permissions vary if the site is installed in a different way (see discussion below).
Permission | Drupal 7 | Drupal 8 | WordPress | Backdrop | Joomla
-- | -- | -- | -- | -- | --
CiviCRM: access all custom data | Yes | Yes | Yes | Yes | Yes
CiviCRM: access uploaded files | Yes | Yes | Yes | Yes | Yes
CiviCRM: profile create | Yes | Yes | Yes | Yes | **No**
CiviCRM: profile edit | **No** | Yes | Yes | **No** | **No**
CiviCRM: profile view | Yes | Yes | Yes | Yes | **No** | **No**
CiviCRM: profile listings and forms | **No** | **No** | **No** | **No** | Yes
CiviEvent: register for events | Yes | Yes | Yes | Yes | Yes
CiviEvent: view event info | **No** | Yes | Yes | **No** | Yes
CiviEvent: view event participants | **No** | Yes | **No** | **No** | Yes
CiviContribute: make online contributions | Yes | Yes | Yes | Yes | Yes
CiviMail: access CiviMail subscribe/unsubscribe pages | Yes | Yes | Yes | Yes | Yes
CiviMail: view public CiviMail content | **No** | **No** | Yes | **No** | **No**
CiviCampaign: sign CiviCRM Petition | **No** | **No** | Yes | **No** | **No**
Proposed behaviour
----------------------------------------
The permissions should be the same regardless of CMS and the way that CiviCRM is installed.
Comments
----------------------------------------
I guess this probably relates to #1615.
I've tracked down the following files that set permissions for the anonymous user.
WordPress and Joomla seem to be the most consistent in that the permissions are only defined in one place:
* [WordPress](https://github.com/civicrm/civicrm-wordpress/blob/145e98bb647122e66a6a624ed17f58846319e7e7/includes/civicrm.users.php#L248-L268)
* [Joomla](https://github.com/civicrm/civicrm-joomla/blob/master/script.civicrm.php#L188-L211)
Drupal and Backdrop permissions are defined in multiple locations:
* In `install/index.php`
* [Drupal 6](https://github.com/civicrm/civicrm-core/blob/master/install/index.php#L1804)
* [Drupal 7](https://github.com/civicrm/civicrm-core/blob/master/install/index.php#L1839-L1855)
* [Backdrop](https://github.com/civicrm/civicrm-core/blob/master/install/index.php#L1874-L1886)
* In the new `civicrm-setup` files
* [Drupal 7](https://github.com/civicrm/civicrm-core/blob/master/setup/plugins/installDatabase/FlushDrupal.civi-setup.php#L26-L42)
* [Drupal 8](https://github.com/civicrm/civicrm-core/blob/master/setup/plugins/installDatabase/FlushDrupal8.civi-setup.php#L26-L38)
* [Backdrop](https://github.com/civicrm/civicrm-core/blob/master/setup/plugins/installDatabase/FlushBackdrop.civi-setup.php#L25-L37)
* In the `civicrm_webtest` module
* [Drupal 7 and Backdrop](https://github.com/civicrm/civicrm-core/blob/master/tools/drupal/modules/civicrm_webtest/civicrm_webtest.install#L14-L22)
Finally CiviCRM's ACL permissions are set here:
* [xml/templates/civicrm_acl.tpl](https://github.com/civicrm/civicrm-core/blob/master/xml/templates/civicrm_acl.tpl)
Needless to say, each sets a slightly different set of permissions.https://lab.civicrm.org/dev/financial/-/issues/63Something wrong when a pending contribution is changed manually to completed2023-03-05T19:42:49ZfrancescbassasSomething wrong when a pending contribution is changed manually to completedWe usually offer the possibility to pay with credit card or with pay later via cash or EFT.
Pay later contributions are registered as pending. Then when we receive the payment in some cases we modify the status of the payment to complet...We usually offer the possibility to pay with credit card or with pay later via cash or EFT.
Pay later contributions are registered as pending. Then when we receive the payment in some cases we modify the status of the payment to completed (also date received). This creates a payment with the amount of the contribution but without the payment method. Then if we try to update the payment method the process crashes with a 500 (the update screen remains with the logo of CiviCRM turning indefinitely).
```
Sorry, due to an error, we are unable to fulfill your request at the moment.
You may want to contact your administrator or service provider with more details
about what action you were performing when this occurred.
Mandatory key(s) missing from params array: payment_instrument_id
Return to home page.
```
The error can be reproduced at dmaster.
![edit-contribution](/uploads/86f4e384800d6ac895cca6fb33ecdc80/edit-contribution.gif)
Note that if instead of changing contribution status we record the payment, this works well.
![record-payment](/uploads/8a59f82b67f434bb5737dcf3fb9e13ee/record-payment.gif)5.18.2https://lab.civicrm.org/dev/core/-/issues/732Parsing of addresses in the format of different countries2023-03-05T05:03:27ZjaapjansmaParsing of addresses in the format of different countriesCiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street n...CiviCRM has the ability to parse addresses into a street name, house number and street unit.
This parsing is based on I assume US address formats.
E.g. an address like _799 E DRAGRAM SUITE 5A_ is parsed into house number: 799, street name: E Dragram, and Street unit Suite 5a.
In the Netherlands and Belgium the adresses are formatted in a different way, first it is the street name, then the house number and then the street unit.
Some examples:
* _Grote straat 1a_, which should be parsed to Street name: Grote straat, house number 1, and street unit a
* _Grote straat 2-3_, which should be parsed to Street name: Grote straat, House number 2, and street unit 3
* _Plein 40-45 60-II_, which should be parsed to Street name: Plein 40-45, house number 60 and street unit II
**What I think CiviCRM should be capable of (either with an extension or in core):**
1. Parse addresses based on the country of the address
2. Format addresses based on the country of the address, meaning glue the individual address (Street name, house number, street unit) parts into one address
**How does it work currently?**
When I enable Address Parsing I can enther a full address into CiviCRM.
If I enter _Grote straat 1a_ it gets parsed into Address name: Grote straat 1a, House number: _empty_ and street unit _empty_
If I enter _Plein 40-45 60-II_ it gets parsed into Address name: Plein 40-45 60-II, House number: _empty_ and street unit _empty_
If I enter the individual parts, street name: Grote straat, house number: 1 and street unit a, it gets formatted to 1 Grote straat a
As you can see the formatting and parsing of Dutch and Belgium addresses does not work.
**Proposed solution**
I do think it will be good when the address parsing functionality could be made in such way that extensions could hook into it.
I am thinking of a hook which provides callback functions for address parsing based on the country ID of the address.
Example code
```php
$callbacks[1020] = array('CRM_Address_BAO_Address', 'parseBelgiumAddress');
$callbacks['default'] = array('CRM_Address_BAO_Address', 'parseAddress');
/**
* Alter the callbacks for address parsing
*
* @param array $callbacks
*/
hook_civicrm_alter_address_parser_callbacks(&$callbacks) {
// Add a custom address parser
// For example the dutch one:
$callbakcs[1152] = array('CRM_MyExtension_DutchAddressParser', 'parseDutchAddress');
}
```
This way CiviCRM core could provide a default address parser, and a set of address parser for certain countries and if one is missing an extension developer could write the missing parser.
What do you think of this? If everyone is happy I am happy to implement this.jaapjansmajaapjansma