Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-01-31T10:18:23Zhttps://lab.civicrm.org/dev/core/-/issues/3462Event location search2024-01-31T10:18:23Zaydunsaidan.saunders@squiffle.ukEvent location searchOverview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It w...Overview
----------------------------------------
Following on from #2103 - when configuring an event and reusing a location, Civi shows a message like 'This location is used by 2 other events' but does not indicate which events.
It would be useful to show a list of those locations, or include a link to search for them.
Note that SearchKit displays now handle LocBlocks (see #2676)https://lab.civicrm.org/dev/core/-/issues/3461ACL for Group Nesting2022-05-19T16:14:30ZGuillaumeSorelACL for Group NestingOverview
----------------------------------------
Improve ACL for Nested (child) groups to set a parent group.
Example use-case
----------------------------------------
On a single instance, you might need to have 2 groups that are comp...Overview
----------------------------------------
Improve ACL for Nested (child) groups to set a parent group.
Example use-case
----------------------------------------
On a single instance, you might need to have 2 groups that are completely independent, say Group A and Group B, with Admin A having ACL permissions on Group A and Admin B having ACL permissions on Group B. This is important because Admin A shouldn't have CRED permissions over contacts in Group B (for example Donors) and same for Admin B over contacts in Group A.
Admin A or B might also need to create sub-groups A1 & A2 or B1 & B2 to send different newsletters (A1 for Donators and A2 for Volunteers) and manage subscription, preventing contact Ax from being removed from Group A but not from Newsletter Group A2.
Admin A or B will want to CRED their 'own' contacts and add/remove them to the sub-groups they manage.
Current behaviour
----------------------------------------
Admin A can create groups but they won't be considered as nested groups (child or sub-groups) and s.he won't be allowed to see them as nested groups don't inherit ACL.
What shows up right now in the 'Groups Screen':
- Group A (seen by Admin A)
- Sub-group A (not seen by Admin A)
The super Admin has to manually change the ACL to add Sub-group A as a child group for Group A which is not a durable process.
Proposed behaviour
----------------------------------------
If Admin A has CRED ACL permission over Group A, s.he should be able to CRED sub-groups and manage contacts inside these sub-groups.
Sub-groups should be automatically defined as child groups of the group the admin has ACL permission over. Other way round, a new group should get the parent group set when it's being created
When Admin A has multiple ACL permission, s.he should be able to choose which parent group the new child group has.
What will show up in the 'Groups Screen':
- Group A (seen by Admin A)
- Sub-group A (seen by Admin A)https://lab.civicrm.org/dev/core/-/issues/3460AuthX breaks Contribution Batch functionality (and more)2022-12-21T16:04:08ZJonGoldAuthX breaks Contribution Batch functionality (and more)A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't n...A number of core CiviCRM pages call the `civicrm/ajax/rest` endpoint. When AuthX is enabled, these functions fail with an "Invalid Credential" error.
### Steps to replicate
* enable AuthX.
* Create a new Contribution Batch (you don't need to add anything to it).
* Go to **Contributions » Accounting Batches » Open Batches**.
* Select **more » Delete**.
### Expected Result
Batch is deleted (which is what happens when AuthX is disabled)
### Actual Result
"An error occurred while processing your request.". Dev tools show `FATAL: Invalid credential`.
A search of the codebase shows several references to `civicrm/ajax/rest` - mostly in out-of-the-way areas like Premiums or Accounting Batches.
I'm not sure what the correct approach is - my sense from my reading was that @totten had accounted for this, so I'd appreciate his eyes on this. I assume creating a second endpoint that replicates the original behavior defeats the purpose here. I also see that `CRM_Utils_REST::ajax()` has `self::isWebServiceRequest()` which does its own AuthX checking, but the request never reaches `CRM_Utils_REST::ajax()` because the request is denied when `CRM_Core_Invoke::_invoke()` calls `civi.invoke.auth`.5.56.1https://lab.civicrm.org/dev/core/-/issues/3458CiviCRM 5.49.1 - CiviCRM Event, Scheduled Reminders that are created with rep...2024-02-02T05:03:22Zjustinfreeman (Agileware)CiviCRM 5.49.1 - CiviCRM Event, Scheduled Reminders that are created with repetition and "also Include" criteria crash the database during cron run, with error: "Not unique table/alias: 'r'"CiviCRM Event, Scheduled Reminders that are created with repetition and "also Include" criteria crash the database during cron run, with error: "Not unique table/alias: 'r'"
This stems from the CRM_Event_ActionMapping class, which speci...CiviCRM Event, Scheduled Reminders that are created with repetition and "also Include" criteria crash the database during cron run, with error: "Not unique table/alias: 'r'"
This stems from the CRM_Event_ActionMapping class, which specifies a base table as "civicrm_event r" when it probably should be "civicrm_participant e", and a query is generated in the repetition check phase like
"INSERT into civicrm_event r INNER JOIN civicrm_event r ..."
This only seems to apply to Scheduled Reminders created for the Event ("Event Reminders"?).
This is initially evidenced by Scheduled Reminders job failure as follows:
```
Entity: Job Action: send_reminder
Summary
Finished execution of Send Scheduled Reminders with result: Failure, Error message: DB Error: unknown error
Details
Parameters parsed (and passed to API method):
a:1:{s:7:"version";i:3;}
Full message:
Finished execution of Send Scheduled Reminders with result: Failure, Error message: DB Error: unknown error
```
It looks like this problem has been around since 2015.
As observed on CiviCRM 5.49.1
Agileware Ref: CIVICRM-1981https://lab.civicrm.org/dev/translation/-/issues/76Add support for extension .mo in [civicrm.l10n]2023-01-28T19:10:09ZbgmAdd support for extension .mo in [civicrm.l10n]#30 added support for translation "mo" files in a custom resource directory (such as `files/civicrm/l10n`). This makes it easier to update files regularly, such as with the l10nupdate extension, which must be able to write to disk.
Howe...#30 added support for translation "mo" files in a custom resource directory (such as `files/civicrm/l10n`). This makes it easier to update files regularly, such as with the l10nupdate extension, which must be able to write to disk.
However currently extensions must still have their "mo" files in their own directory. This causes challenges with the distribution of mo files for core extensions, but it is also annoying for non-core extensions that are available for automatic distribution (i.e. on Transifex).
Proposal: support both, as a transitional measure.
Eventually, I think we should deprecate the old behaviour, and always have a process such as l10nupdate which will fetch translations. That way we can also deprecate `civicrm-l10n-xx.tar.gz`.5.59.0https://lab.civicrm.org/dev/core/-/issues/3457Make SearchKit available to non-admin users2022-06-04T04:07:12ZcolemanwMake SearchKit available to non-admin usersThis is a sponsored issue to make SearchKit available to non-admins by adding a new permission.This is a sponsored issue to make SearchKit available to non-admins by adding a new permission.colemanwcolemanwhttps://lab.civicrm.org/dev/wordpress/-/issues/126CRM_Core_Permission_WordPress check function does not get all WP User capabil...2022-05-17T12:05:03ZkcristianoCRM_Core_Permission_WordPress check function does not get all WP User capabilities after IPN returnTracking at [Core Issue 3456](https://lab.civicrm.org/dev/core/-/issues/3456)Tracking at [Core Issue 3456](https://lab.civicrm.org/dev/core/-/issues/3456)https://lab.civicrm.org/dev/core/-/issues/3456CRM_Core_Permission_WordPress check function does not get all WP User capabil...2024-01-28T05:03:33ZapbrooksCRM_Core_Permission_WordPress check function does not get all WP User capabilities after IPN returnI have been getting the following error when trying to load the thank you page after a Stripe payment contribution:
CRM_Contribute_Form_Contribution_Confirm::completeTransaction CiviCRM_API3_Exception: The requested Profile (gid= ) is d...I have been getting the following error when trying to load the thank you page after a Stripe payment contribution:
CRM_Contribute_Form_Contribution_Confirm::completeTransaction CiviCRM_API3_Exception: The requested Profile (gid= ) is disabled OR it is not configured to be used for 'Profile' listings in its Settings OR there is no Profile with that ID OR you do not have permission to access this profile. Please contact the site administrator if you need assistance.
All user roles have the correct Civicrm Capabilities to view the profile. After a lot of debugging I discovered that the CRM_Core_Permission_WordPress check function was not loading all the user's role capabilities. The function calls get_userdata or wp_get_current_user to get the user object:
`$user = $userId ? get_userdata($userId) : wp_get_current_user();`
In certain cases (i.e. the user not previously cached). These methods may not return all the capabilities of the user. They only load the basic user capabilities but may not include their role based capabilities.
The method WP_User::get_role_caps() should also be called to get the role base capabilities.
[WP_User::get_role_caps()](https://developer.wordpress.org/reference/classes/wp_user/get_role_caps/)
Here is an example user capabilities before get_role_caps() is called. As you can see none of the CiviCRM capabilities are listed:
<details><summary>Click to expand</summary>
```log
[allcaps] => Array
(
[activate_plugins] => 1
[add_users] => 1
[create_users] => 1
[customize] => 1
[delete_others_pages] => 1
[delete_others_posts] => 1
[delete_pages] => 1
[delete_plugins] => 1
[delete_posts] => 1
[delete_private_pages] => 1
[delete_private_posts] => 1
[delete_published_pages] => 1
[delete_published_posts] => 1
[delete_themes] => 1
[delete_users] => 1
[edit_dashboard] => 1
[edit_files] => 1
[edit_others_pages] => 1
[edit_others_posts] => 1
[edit_pages] => 1
[edit_plugins] => 1
[edit_posts] => 1
[edit_private_pages] => 1
[edit_private_posts] => 1
[edit_published_pages] => 1
[edit_published_posts] => 1
[edit_theme_options] => 1
[edit_themes] => 1
[edit_users] => 1
[export] => 1
[import] => 1
[install_plugins] => 1
[install_themes] => 1
[list_users] => 1
[manage_categories] => 1
[manage_options] => 1
[moderate_comments] => 1
[promote_users] => 1
[publish_pages] => 1
[publish_posts] => 1
[read] => 1
[read_private_pages] => 1
[read_private_posts] => 1
[remove_users] => 1
[switch_themes] => 1
[unfiltered_html] => 1
[update_core] => 1
[update_plugins] => 1
[update_themes] => 1
[upload_files] => 1
[upload_plugins] => 1
[upload_themes] => 1
)
```
</details>
Here is the list of capabilities after get_role_caps() is called:
<details><summary>Click to expand</summary>
```log
[allcaps] => Array
(
[0] => 1
[activate_plugins] => 1
[create_blocks] => 1
[create_posts] => 1
[create_users] => 1
[delete_blocks] => 1
[delete_others_blocks] => 1
[delete_others_pages] => 1
[delete_others_posts] => 1
[delete_pages] => 1
[delete_plugins] => 1
[delete_posts] => 1
[delete_private_blocks] => 1
[delete_private_pages] => 1
[delete_private_posts] => 1
[delete_published_blocks] => 1
[delete_published_pages] => 1
[delete_published_posts] => 1
[delete_themes] => 1
[delete_users] => 1
[edit_blocks] => 1
[edit_dashboard] => 1
[edit_files] => 1
[edit_manage_optionss] => 1
[edit_others_blocks] => 1
[edit_others_manage_optionss] => 1
[edit_others_pages] => 1
[edit_others_posts] => 1
[edit_pages] => 1
[edit_plugins] => 1
[edit_posts] => 1
[edit_private_blocks] => 1
[edit_private_pages] => 1
[edit_private_posts] => 1
[edit_published_blocks] => 1
[edit_published_pages] => 1
[edit_published_posts] => 1
[edit_theme_options] => 1
[edit_themes] => 1
[edit_users] => 1
[export] => 1
[import] => 1
[install_plugins] => 1
[install_themes] => 1
[list_users] => 1
[manage_categories] => 1
[manage_links] => 1
[manage_options] => 1
[moderate_comments] => 1
[promote_users] => 1
[publish_blocks] => 1
[publish_manage_optionss] => 1
[publish_pages] => 1
[publish_posts] => 1
[read] => 1
[read_blocks] => 1
[read_private_blocks] => 1
[read_private_manage_optionss] => 1
[read_private_pages] => 1
[read_private_posts] => 1
[remove_users] => 1
[switch_themes] => 1
[unfiltered_html] => 1
[unfiltered_upload] => 1
[update_core] => 1
[update_plugins] => 1
[update_themes] => 1
[upload_files] => 1
[access_civicrm] => 1
[access_ajax_api] => 1
[access_all_custom_data] => 1
[access_civicontribute] => 1
[access_civimail_subscribe_unsubscribe_pages] => 1
[access_civimember] => 1
[access_civireport] => 1
[access_contact_dashboard] => 1
[access_contact_reference_fields] => 1
[access_report_criteria] => 1
[access_uploaded_files] => 1
[add_contact_notes] => 1
[add_contacts] => 1
[delete_contacts] => 1
[delete_in_civicontribute] => 1
[delete_in_civimember] => 1
[edit_all_contacts] => 1
[edit_contributions] => 1
[edit_groups] => 1
[edit_inbound_email_basic_information] => 1
[edit_inbound_email_basic_information_and_content] => 1
[edit_memberships] => 1
[edit_my_contact] => 1
[make_online_contributions] => 1
[merge_duplicate_contacts] => 1
[profile_create] => 1
[profile_edit] => 1
[profile_listings] => 1
[profile_listings_and_forms] => 1
[profile_view] => 1
[register_for_events] => 1
[save_report_criteria] => 1
[view_all_activities] => 1
[view_all_contacts] => 1
[view_all_notes] => 1
[view_event_info] => 1
[view_my_contact] => 1
[view_my_invoices] => 1
[view_public_civimail_content] => 1
[administrator] => 1
[member] => 1
)
```
</details>
Thank You.https://lab.civicrm.org/dev/core/-/issues/3455Contact import - do we need a separate 'no match' type of error?2023-01-31T04:27:52ZeileenContact import - do we need a separate 'no match' type of error?Can we fold tracking of 'no_match' contacts into general 'invalid/error' contacts during import - ie in terms of how they are reported on the contact summary screen.
During contact validation (ie when MapField is submitted & Preview for...Can we fold tracking of 'no_match' contacts into general 'invalid/error' contacts during import - ie in terms of how they are reported on the contact summary screen.
During contact validation (ie when MapField is submitted & Preview form is presented the following outcomes are possible:
- Valid = imported / will attempt to import
- Invalid = failed to import
During the contact import the following outcomes are possible...
- Valid = imported / will attempt to import
- Invalid = failed to import
- No match = failed to import in a way that relates to contact types or something
- Unparsed warning = imported but didn't succeed with USPS parsing (does that even work?)
- Duplicates - updated/skipped depending on the option
No Match is returned in a handful of cases which mostly seem to be around contact subtype - although it could be the type of an existing contact doesn't match the relationship or something.
These are in a separate csv which can be downloaded - the text on the summary screen is
"CiviCRM has detected mismatched contact IDs. These records have not been updated"
"You may then correct them, and import the new file with the corrected data"
- which is clear as mud to me.
Is there any advantage to tracking these separately to the main 'invalid/error' rows outputhttps://lab.civicrm.org/dev/core/-/issues/3454Migrate hook_civicrm_caseTypes to hook_civicrm_managed2024-01-26T05:03:29ZtottenMigrate hook_civicrm_caseTypes to hook_civicrm_managedOverview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a s...Overview
---------
Since v4.x, `hook_civicrm_caseTypes` has provided a way to register a case-type using a stored file from an extension. `hook_civicrm_managed` was recently expanded (#3429 for 5.50) in a way that appears to provide a superset of the functionality. During review of @herbdool's https://github.com/civicrm/civicrm-core/pull/23313, @colemanw suggested deprecating `hook_caseTypes` in favor of `hook_managed`.
This issue is to identify the steps/phases of a migration.
Pro/Con
---------
* Reasons to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* They support the same use-case. Having more than one way to do the same thing can be confusing.
* `hook_managed` is more generic. You get more utility/leverage from understanding it.
* `hook_managed` has more options vis-a-vis lifecycle, cleanup, etc.
* Reasons not to transition `hook_civicrm_caseTypes` => `hook_civicrm_managed`
* If it ain't broke, don't fix it.
* `hook_caseTypes` has multiple mappings which appear to work together (ie `CRM_Case_ManagedEntities`: `CaseTypes`,`ActivityTypes`,`RelationshipTypes`).
* This specific application of `hook_managed` is new. Needs more usage to see if it's fit-to-purpose.
Transition Path
---------------
IMHO, the transition would look something like this:
* Near term / Phase 1
* Do some testing around extension lifecycle/upgrades - eg if you upgrade an extension (*getting a new CaseType `definition` that adds, edits, removes some ActivityType*), then... do the interdependent things update properly? What happens if you've edited the `ActivityType` locally or added another `ActivityType`? Do policies like `cleanup=>unmodified` or `cleanup=>unused` actually work? (*I expect these to be somewhat sensible, since each part seems to have satisfactory precedent; but I encourage playing with it during QA, since this is a bit unusual and it's important to the story of "managed CaseType".*) Perhaps publish an example extension that shows that the technique is fit-for-purpose.
* Mid-term / Phase 2
* Add some docs which tell the story of exporting via `civicrm/api4` -- eg an alternative to https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type
* Try doing a conversion from `xml/case/*.xml` to `*.mgd.php`. Make sure that IDs/FKs (`case_type_id`, `activity_type_id`, etc) are stable.
* Remove https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-case-type and maybe `civix generate:case-type` (Leave a pointer to the new docs.)
* Update `CRM_Case_ManagedEntities` and/or `mixins/case-xml` to emit a warning. Encourage folks to convert to `mgd`.
* (*Stretch goal*) Add a step to `civix upgrade` to auto-convert `*.xml` to `*.mgd.php` (or at least show a warning about the XML files). (See also: https://github.com/totten/civix/tree/master/upgrades)
* Long-term / Phase 3
* Remove `hook_caseTypes` aka `mixins/case-xml` from core
* Remove `hook_caseTypes` aka `mixins/case-xml` from civixhttps://lab.civicrm.org/dev/wordpress/-/issues/125CRM_Core_Permission_WordPress check function does not get all WP User capabil...2022-05-10T10:59:15ZapbrooksCRM_Core_Permission_WordPress check function does not get all WP User capabilities after IPN returnI have been getting the following error when trying to load the thank you page after a Stripe payment contribution:
CRM_Contribute_Form_Contribution_Confirm::completeTransaction CiviCRM_API3_Exception: The requested Profile (gid= ) is d...I have been getting the following error when trying to load the thank you page after a Stripe payment contribution:
CRM_Contribute_Form_Contribution_Confirm::completeTransaction CiviCRM_API3_Exception: The requested Profile (gid= ) is disabled OR it is not configured to be used for 'Profile' listings in its Settings OR there is no Profile with that ID OR you do not have permission to access this profile. Please contact the site administrator if you need assistance.
All user roles have the correct Civicrm Capabilities to view the profile. After a lot of debugging I discovered that the CRM_Core_Permission_WordPress check function was not loading all the user's role capabilities. The function calls get_userdata or wp_get_current_user to get the user object:
`$user = $userId ? get_userdata($userId) : wp_get_current_user();`
In certain cases (i.e. the user not previously cached). These methods may not return all the capabilities of the user. They only load the basic user capabilities but may not include their role based capabilities.
The method WP_User::get_role_caps() should also be called to get the role base capabilities.
[WP_User::get_role_caps()](https://developer.wordpress.org/reference/classes/wp_user/get_role_caps/)
Here is an example user capabilities before get_role_caps() is called. As you can see none of the CiviCRM capabilities are listed:
<details><summary>Click to expand</summary>
```log
[allcaps] => Array
(
[activate_plugins] => 1
[add_users] => 1
[create_users] => 1
[customize] => 1
[delete_others_pages] => 1
[delete_others_posts] => 1
[delete_pages] => 1
[delete_plugins] => 1
[delete_posts] => 1
[delete_private_pages] => 1
[delete_private_posts] => 1
[delete_published_pages] => 1
[delete_published_posts] => 1
[delete_themes] => 1
[delete_users] => 1
[edit_dashboard] => 1
[edit_files] => 1
[edit_others_pages] => 1
[edit_others_posts] => 1
[edit_pages] => 1
[edit_plugins] => 1
[edit_posts] => 1
[edit_private_pages] => 1
[edit_private_posts] => 1
[edit_published_pages] => 1
[edit_published_posts] => 1
[edit_theme_options] => 1
[edit_themes] => 1
[edit_users] => 1
[export] => 1
[import] => 1
[install_plugins] => 1
[install_themes] => 1
[list_users] => 1
[manage_categories] => 1
[manage_options] => 1
[moderate_comments] => 1
[promote_users] => 1
[publish_pages] => 1
[publish_posts] => 1
[read] => 1
[read_private_pages] => 1
[read_private_posts] => 1
[remove_users] => 1
[switch_themes] => 1
[unfiltered_html] => 1
[update_core] => 1
[update_plugins] => 1
[update_themes] => 1
[upload_files] => 1
[upload_plugins] => 1
[upload_themes] => 1
)
```
</details>
Here is the list of capabilities after get_role_caps() is called:
<details><summary>Click to expand</summary>
```log
[allcaps] => Array
(
[0] => 1
[activate_plugins] => 1
[create_blocks] => 1
[create_posts] => 1
[create_users] => 1
[delete_blocks] => 1
[delete_others_blocks] => 1
[delete_others_pages] => 1
[delete_others_posts] => 1
[delete_pages] => 1
[delete_plugins] => 1
[delete_posts] => 1
[delete_private_blocks] => 1
[delete_private_pages] => 1
[delete_private_posts] => 1
[delete_published_blocks] => 1
[delete_published_pages] => 1
[delete_published_posts] => 1
[delete_themes] => 1
[delete_users] => 1
[edit_blocks] => 1
[edit_dashboard] => 1
[edit_files] => 1
[edit_manage_optionss] => 1
[edit_others_blocks] => 1
[edit_others_manage_optionss] => 1
[edit_others_pages] => 1
[edit_others_posts] => 1
[edit_pages] => 1
[edit_plugins] => 1
[edit_posts] => 1
[edit_private_blocks] => 1
[edit_private_pages] => 1
[edit_private_posts] => 1
[edit_published_blocks] => 1
[edit_published_pages] => 1
[edit_published_posts] => 1
[edit_theme_options] => 1
[edit_themes] => 1
[edit_users] => 1
[export] => 1
[import] => 1
[install_plugins] => 1
[install_themes] => 1
[list_users] => 1
[manage_categories] => 1
[manage_links] => 1
[manage_options] => 1
[moderate_comments] => 1
[promote_users] => 1
[publish_blocks] => 1
[publish_manage_optionss] => 1
[publish_pages] => 1
[publish_posts] => 1
[read] => 1
[read_blocks] => 1
[read_private_blocks] => 1
[read_private_manage_optionss] => 1
[read_private_pages] => 1
[read_private_posts] => 1
[remove_users] => 1
[switch_themes] => 1
[unfiltered_html] => 1
[unfiltered_upload] => 1
[update_core] => 1
[update_plugins] => 1
[update_themes] => 1
[upload_files] => 1
[access_civicrm] => 1
[access_ajax_api] => 1
[access_all_custom_data] => 1
[access_civicontribute] => 1
[access_civimail_subscribe_unsubscribe_pages] => 1
[access_civimember] => 1
[access_civireport] => 1
[access_contact_dashboard] => 1
[access_contact_reference_fields] => 1
[access_report_criteria] => 1
[access_uploaded_files] => 1
[add_contact_notes] => 1
[add_contacts] => 1
[delete_contacts] => 1
[delete_in_civicontribute] => 1
[delete_in_civimember] => 1
[edit_all_contacts] => 1
[edit_contributions] => 1
[edit_groups] => 1
[edit_inbound_email_basic_information] => 1
[edit_inbound_email_basic_information_and_content] => 1
[edit_memberships] => 1
[edit_my_contact] => 1
[make_online_contributions] => 1
[merge_duplicate_contacts] => 1
[profile_create] => 1
[profile_edit] => 1
[profile_listings] => 1
[profile_listings_and_forms] => 1
[profile_view] => 1
[register_for_events] => 1
[save_report_criteria] => 1
[view_all_activities] => 1
[view_all_contacts] => 1
[view_all_notes] => 1
[view_event_info] => 1
[view_my_contact] => 1
[view_my_invoices] => 1
[view_public_civimail_content] => 1
[administrator] => 1
[member] => 1
)
```
</details>
Thank You.https://lab.civicrm.org/dev/core/-/issues/3453Afform - relationships fill from other entity2022-12-07T01:43:54ZsamuelsovAfform - relationships fill from other entityFollow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab....Follow-up from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
Let say we want to do a form that allow an employer to update :
- the main contact of the organization
- all the employees
Thanks to https://lab.civicrm.org/dev/core/-/issues/3117 it's now possible to do a form that will allow to create in one step :
- the organization
- the main contact as Individual 1 with a relationship between the organization and Individual 1
- the employees as Individual 2 with a relationship between the organization and Invividual 2 (which is multiple)
However, there is no way to have an edit mode for such a form. It's possible to add the organization id as an argument but we also need a way to pre-populate the main contacts / list of employees as an option based on the relationships definition.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3452Afform - relationships should work both ways or be blocked in the UI2024-01-26T05:03:27ZsamuelsovAfform - relationships should work both ways or be blocked in the UITaken from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
I get this error in the console if the relationship definition is not in the same way as the relationship type definition: Possibly unhandled rejectio...Taken from https://github.com/civicrm/civicrm-core/pull/23296#issuecomment-1119014194
I get this error in the console if the relationship definition is not in the same way as the relationship type definition: Possibly unhandled rejection: {"error_code":0,"error_message":"Invalid Relationship"}
This works:
![Screenshot_2022-05-05_at_15-53-15_Form_Builder_Form_with_multiple_relationship_core-23296-1wh93](/uploads/64359e09b0e0ff638a95b882a677bbc0/Screenshot_2022-05-05_at_15-53-15_Form_Builder_Form_with_multiple_relationship_core-23296-1wh93.png)
But not this:
![Screenshot_2022-05-05_at_15-52-55_Form_Builder_Form_with_multiple_relationship_core-23296-1wh93](/uploads/caa09753c2513be46eb5b2d1a6c928cb/Screenshot_2022-05-05_at_15-52-55_Form_Builder_Form_with_multiple_relationship_core-23296-1wh93.png)
Seems logical but we should add a validator in the afform editor to either forbid the second or only allow for the other way `Employer is` relationship.colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3451Afform: Select element does not seem to properly pass filter values2023-10-27T07:18:39ZRichAfform: Select element does not seem to properly pass filter valuesOverview
----------------------------------------
When a select element is used for a boolean field (e.g. `contribution.is_test`) the value(s) are not passed and result in empty results.
https://chat.civicrm.org/civicrm/pl/9613mtpi6j8y...Overview
----------------------------------------
When a select element is used for a boolean field (e.g. `contribution.is_test`) the value(s) are not passed and result in empty results.
https://chat.civicrm.org/civicrm/pl/9613mtpi6j8ypxf879p7eyyz5a
Possibly related https://lab.civicrm.org/dev/core/-/issues/3449 and https://lab.civicrm.org/dev/core/-/issues/3450
Reproduction steps
----------------------------------------
See chat link ↑
Current behaviour
----------------------------------------
Looking at the browser requests, it seems that when select is used it passes filter data like:
```
filters: { is_test: [ "false" ] }
```
Correct filter should be:
```
filters: { is_test: [ false ] }
```
----------------------------------------
<!-- 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:__ 5.47.4, 5.48.2
* __CMS:__ D7https://lab.civicrm.org/dev/core/-/issues/3450Afform: non-required radios should include a "clear" button.2022-08-04T17:46:31ZRichAfform: non-required radios should include a "clear" button.Overview
----------------------------------------
Radios (without a default value set) come up both un-selected, but once one has been selected there is no way to de-select the options.
Proposed behaviour
-----------------------------...Overview
----------------------------------------
Radios (without a default value set) come up both un-selected, but once one has been selected there is no way to de-select the options.
Proposed behaviour
----------------------------------------
Radios for fields whose value is not required should include a clear button.
Comments
----------------------------------------
Related: https://lab.civicrm.org/dev/core/-/issues/3449https://lab.civicrm.org/dev/core/-/issues/3449Afform: checkboxes should have default false value2024-03-21T05:03:28ZRichAfform: checkboxes should have default false valueOverview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *shou...Overview
----------------------------------------
If you have a checkbox used, for example, for "is_test" on a contribution search table but without explictly configuring a default value, the UI shows an un-checked checkbox, which *should* be the visual representation of "is_test = 0" but is actually representing *no filter on is_test*.
After operating the checkbox the UI and the meaning are in-sync.
While this can be solved by the form builder designer setting an explicit default value, there is no logical sense to *not* having a default value when the form element is binary.
Current behaviour
----------------------------------------
If person who built the form forgets / does not know to include a default value on a checkbox, the UI is initially broken, results are misleading.
Proposed behaviour
----------------------------------------
A checkbox should insist on a default value, defaulting to false, so that the UI and the meaning of the filter are always in sync.
Comments
----------------------------------------
https://chat.civicrm.org/civicrm/pl/9613mtpi6j8ypxf879p7eyyz5ahttps://lab.civicrm.org/dev/core/-/issues/3448Deletion of Files on Custom FIelds doesn't delete file if entity is deleted.2024-01-25T05:03:24Zluke.stewartDeletion of Files on Custom FIelds doesn't delete file if entity is deleted.Tested on master and 5.48
Create a custom field for a file on a contact - or activity (haven't tested elsewhere)
Create a new entity with a file on that contact.
Identify uploaded file name in civicrm_file
Find location of the file on t...Tested on master and 5.48
Create a custom field for a file on a contact - or activity (haven't tested elsewhere)
Create a new entity with a file on that contact.
Identify uploaded file name in civicrm_file
Find location of the file on the server.
Copy the url to download the file.
Delete the entity - then Delete from Trash. See notification about all related data being deleted.
Check the civicrm_file table. Row is still present.
Check the file on the file system - file is still present.
Attempt to download the file - it will still download.
Deleting the file via the edit custom field click the trash item does delete the file.
Deleting an activity with an attachment does work.
It looks like rows are not removed from civcirm_entity_file either. However it looks like perhaps they are not added when the custom field is on an individual?
I think it's reasonable for a user to consider that deleting an Activity Attachment and deleting a file attached via a custom field should function the same way.
Additionally by not deleting these files you run into issues with GDPR.https://lab.civicrm.org/dev/core/-/issues/3446Please include Contributors and Reviewers website address in the CiviCRM Rele...2024-01-25T05:03:22Zjustinfreeman (Agileware)Please include Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog PostThis is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profi...This is a request to please include the Contributors and Reviewers website address in the CiviCRM Release Notes and CiviCRM Blog Post. Currently, no link to their website is shown at all. And there are only links to CiviCRM Partner Profiles.
It would be a nice way of giving credit to all people involved by including a link to their website.
Appreciate this requires some changes to how the release notes and blog posts are compiled, happy to help make this happen.https://lab.civicrm.org/dev/wordpress/-/issues/124nested conditional shortcode causes exception "You must be logged in to view ...2023-12-06T21:58:33ZAllenShawnested conditional shortcode causes exception "You must be logged in to view this page"The below-described bad behavior was not happening in CiviCRM 5.35.2 but does happen after upgrading to 5.47.4. Can someone suggest what might have changed that would cause this?
**Setup:**
- The custom WordPress theme on this site prov...The below-described bad behavior was not happening in CiviCRM 5.35.2 but does happen after upgrading to 5.47.4. Can someone suggest what might have changed that would cause this?
**Setup:**
- The custom WordPress theme on this site provides an [enclosing-content shortcode](https://developer.wordpress.org/plugins/shortcodes/enclosing-shortcodes/#enclosing-content) `[member_short_code]` which will only display its content if the user is logged in. E.g. `[member_short_code]Only logged in users see this[/member_short_code]`.
- On a given post, the [member_short_code] shortcode is used, and its contents contain is an instance of `[civicrm component="user-dashboard" hijack="0"]`, with the intention that this page will display the user dashboard only if the user is logged in.
**Previous behavior under CiviCRM 5.35.2:**
- When viewing the given post, logged-in users see the civiCRM user dashboard; anonymous users see nothing.
**New & undesirable behavior under CiviCRM 5.47.4:**
- When viewing the given post, logged-in users see the civiCRM user dashboard; anonymous users get a CiviCRM fatal error with the message "You must be logged in to view this page".
**Why this fatal error happens under CiviCRM 5.47.4?**
- WordPress is processing the contents of the `[member_short_code]` shortcode, even when its contents will not be displayed; I believe that's just how WordPress works, and it's not a problem _per se_.
- When that content includes `[civicrm component="user-dashboard" hijack="0"]`, CiviCRM is testing whether the user has a ContactID, and if not it throws the above-mentioned exception. Reference [UserDashBoard.php line 79](https://github.com/civicrm/civicrm-core/blob/master/CRM/Contact/Page/View/UserDashBoard.php#L79).
**Why this fatal error didn't happen under CiviCRM 5.35.2?**
- I don't know. Any ideas?
- Was the civicrm WordPress plugin doing something to catch such exceptions and handle them more elegangly?
- Worth noting, I've compared the civicrm codebase from pre-upgrade backups and github master, and don't see any core hacks that would have accounted for this.
**Workaround in CiviCRM 5.47.4:**
Naturally this is not ideal, but this changes addresses the problem behavior:
```
diff --git a/CRM/Contact/Page/View/UserDashBoard.php b/CRM/Contact/Page/View/UserDashBoard.php
index 9cb559bf47..0a1af9751b 100644
--- a/CRM/Contact/Page/View/UserDashBoard.php
+++ b/CRM/Contact/Page/View/UserDashBoard.php
@@ -77,7 +77,7 @@ class CRM_Contact_Page_View_UserDashBoard extends CRM_Core_Page {
*/
public function preProcess() {
if (!$this->_contactId) {
- throw new CRM_Core_Exception(ts('You must be logged in to view this page.'));
+ return '';
}
list($displayName, $contactImage) = CRM_Contact_BAO_Contact::getDisplayAndImage($this->_contactId);
```
_{Joinery internal reference: F#724)_https://lab.civicrm.org/dev/core/-/issues/3445Error messages under ui-dialog2022-05-05T14:20:10ZsamuelsovError messages under ui-dialogWhen filling a form in a ui-dialog popup, if any error, it will display the message in a popup under the ui-dialog like so :
![ksnip_20220505-094119](/uploads/c7413e162ada8f9b2597f224aa9a6833/ksnip_20220505-094119.png)
Most of the time...When filling a form in a ui-dialog popup, if any error, it will display the message in a popup under the ui-dialog like so :
![ksnip_20220505-094119](/uploads/c7413e162ada8f9b2597f224aa9a6833/ksnip_20220505-094119.png)
Most of the time, there is a message in the form itself so it's not so bad but I noticed that it's not always the case (for example on a required custom fields with checkboxes, there is no highligh).
Manipuling z-index is not enough because ui-dialog and crm-notification-container is not at the same level in the html. I was able to solve the problem by moving crm-notification-container at the same level as ui-dialog (just under body) like so :
```js
(function($) {
$(document).ajaxComplete(function( event, xhr, settings ) {
// move to body so that it goes on top of the ui-dialog
$('#crm-notification-container').appendTo('body');
});
})(CRM.$);
```
With the fix, it works although the css (shoreditch) is lost :
![Screenshot_2022-05-05_at_09-46-31_Liste_des_rencontres_individuelles___Maison_Plein_Coeur___WordPress](/uploads/eb85b592fae0c612a5e4b41cad9bbc9f/Screenshot_2022-05-05_at_09-46-31_Liste_des_rencontres_individuelles___Maison_Plein_Coeur___WordPress.png)
There might be a better way than doing this through javascript...