Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-07-29T05:03:23Zhttps://lab.civicrm.org/dev/core/-/issues/2551Proposal - add support for defining 'fields' within json blobs2023-07-29T05:03:23ZeileenProposal - add support for defining 'fields' within json blobsThis covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_pro...This covers a discussion at https://chat.civicrm.org/civicrm/pl/pt4nizctz7db8xecrq1triy38e
whereby we have a few entities with configuration options that can't be adequately captured in fields. We sort of make this work with payment_processor by having fields that we kinda rename via the payment_processor_type table and as long as there are only 4 fields it's fine. However, it's not a great structure.
I'm working on a monolog extension and like payment processor and geocoders the configuration options desired by the service varies - but it's not 100% open ended - ie we don't want to just pass through 'whatever'. The best data model to store this is a json blob- however, we then have no UI knowledge of what would go in there and afform is unable to present this field in a UI-friendly way
We looked at the idea of having something like
```
<field>
<name>contact_type</name>
</field>
<field>
<name>contact_sub_type</name>
</field>
<field>
<name>options</name>
<type>text</type>
<serialize>json</serialize>
<schema-callback>CRM_My_Schema::getFields</schema-callback>
<schema-watch>contact_type,contact_sub_type</schema-watch>
</field>
```
Where the UI layer would need to implement the ability to watch the fields defined as schema-watch and update the UI based on it (presumably only for fields that are ALSO already displayed)
A simple xml definition of subfields might look like https://gist.github.com/totten/84c140310d4adc9b5d3842b5d3364a9e - which could be rendered by a generic function.
@totten @seamuslee - anything else you think is important to transfer over here?https://lab.civicrm.org/dev/core/-/issues/2550DB upgrade fails for 5.15->5.362021-11-08T04:30:25ZMartinDB upgrade fails for 5.15->5.36Overview
----------------------------------------
When upgrading the DB from this large jump (on drupal 7) the upgrade fails on 5.16.alpha1:
```
CiviCRM Upgrade Tasks
[Error: Update smart groups to rename filters on contribution_date to...Overview
----------------------------------------
When upgrading the DB from this large jump (on drupal 7) the upgrade fails on 5.16.alpha1:
```
CiviCRM Upgrade Tasks
[Error: Update smart groups to rename filters on contribution_date to receive_date]
CiviCRM_API3_Exception: "DB Error: no such field"
#0 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Upgrade/Incremental/SmartGroups.php(206): civicrm_api3("SavedSearch", "create", (Array:3))
#1 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Upgrade/Incremental/SmartGroups.php(27): CRM_Upgrade_Incremental_SmartGroups->renameField("contribution_date_low", "receive_date_low")
#2 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Upgrade/Incremental/Base.php(222): CRM_Upgrade_Incremental_SmartGroups->updateGroups((Array:1))
#3 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Queue/Task.php(74): CRM_Upgrade_Incremental_Base::updateSmartGroups(Object(CRM_Queue_TaskContext), (Array:1))
#4 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Queue/Runner.php(201): CRM_Queue_Task->run(Object(CRM_Queue_TaskContext))
#5 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(36): CRM_Queue_Runner->runNext(TRUE)
#6 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Queue/ErrorPolicy.php(89): CRM_Queue_Page_AJAX::{closure}()
#7 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Queue/Page/AJAX.php(38): CRM_Queue_ErrorPolicy->call(Object(Closure))
#8 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(279): CRM_Queue_Page_AJAX::runNext()
#9 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(69): CRM_Core_Invoke::runItem((Array:13))
#10 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/CRM/Core/Invoke.php(36): CRM_Core_Invoke::_invoke((Array:5))
#11 /var/www/crm.clgw.ca/html/sites/all/modules/civicrm/drupal/civicrm.module(458): CRM_Core_Invoke::invoke((Array:5))
#12 /var/www/crm.clgw.ca/html/includes/menu.inc(527): civicrm_invoke("upgrade", "queue", "ajax", "runNext")
#13 /var/www/crm.clgw.ca/html/index.php(21): menu_execute_active_handler()
#14 {main}
```
The civi log shows:
```
UPDATE `civicrm_saved_search`
SET `form_values` = 'my_serialized_data_here' ,
`modified_id` = 1284
WHERE ( `civicrm_saved_search`.`id` = 10 )
[nativecode=1054 ** Unknown column 'modified_id' in 'field list']
```
Workaround
----------------------------------------
Searching around I found this which looks related:
- https://lab.civicrm.org/dev/core/-/issues/2422
- https://github.com/civicrm/civicrm-core/pull/19709
So I downgraded my civi files from 5.36 to 5.34 and the db upgrade then worked. My assumption is that code changes in 5.36 modified some dependencies in the API for the SavedSearch object, which then caused earlier db updates on that object to fail.
I don't know if this is easily fixable, but if nothing else maybe this post will help others in my situation.
TLDR: Update your civi files (and then the db) to 5.34 first, then make the jump to a later version after that.5.43.1https://lab.civicrm.org/dev/core/-/issues/2549Errors on merging contacts with websites2023-07-21T15:50:43ZJKingsnorthErrors on merging contacts with websites1: Websites are 'taken across' during merge even if you don't tick to migrate them. eg:
![z5-dont-copy](/uploads/ff258d2ff513cf400bd7f763750fd664/z5-dont-copy.PNG)
![z5-there-anyway](/uploads/a447e19a4b3f7ca9dd7888f11ca15b6c/z5-there-a...1: Websites are 'taken across' during merge even if you don't tick to migrate them. eg:
![z5-dont-copy](/uploads/ff258d2ff513cf400bd7f763750fd664/z5-dont-copy.PNG)
![z5-there-anyway](/uploads/a447e19a4b3f7ca9dd7888f11ca15b6c/z5-there-anyway.PNG)
2: `Notice: Undefined index: is_primary in CRM_Dedupe_Merger::addLocationFieldInfo() (line 2548 of .../CRM/Dedupe/Merger.php).` - this error presumably ocurs because there's no such this as a primary webiste, which the code is expecting here:
```
// Set this value as the default against the 'other' contact value
$rows["move_location_{$blockName}_{$count}"]['main'] = $mainValueCheck[$blockInfo['displayField']];
$rows["move_location_{$blockName}_{$count}"]['main_is_primary'] = $mainValueCheck['is_primary'];
$rows["move_location_{$blockName}_{$count}"]['location_entity'] = $blockName;
$mainContactBlockId = $mainValueCheck['id'];
break;
```
Ping @eileenhttps://lab.civicrm.org/dev/core/-/issues/2548Improvements to the extensions UI and update notifications.2023-11-12T05:03:27ZhomotechsualImprovements to the extensions UI and update notifications.Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into c...Overview
----------------------------------------
_Following a post on MatterMost from @DaveD we discussed how valuable the extension he wrote about and posted here: https://civicrm.org/node/11234 is and I think it's worth working into core. @KarinG then raised a related and equally valuable point that extensions managed outside of CiviCRM e.g. with Git or just existing on the filesystem are marked Green like up-to-date extensions when actually we lack enough data to determine if these extensions are, in fact, up-to-date._
_Therefore I would like to fold Dave's extension's functionality into CiviCRM core and make changes to the extensions UI to remove the green highlight and possibly at a notice to extensions that don't exist on CiviCRM.org to indicate that we cannot determine whether these are up-to-date and extension authors should check manually._
In the discussion I proposed the following:
**Core:**
* Checks for extension updates if extension is on `c.o/extensions` but only updates those approved for in-app (at the moment at least!)
* Displays a message on extensions it doesn't manage (that don't exist on `c.o`) to the effect of "We can't check for updates for this extension." - similar to how Drupal displays a notice on git-managed or custom extensions.
**Contrib:**
* Could provide for update checking for git-managed and possibly custom extensions.
I have time available to work on this last week of April.homotechsualhomotechsualhttps://lab.civicrm.org/dev/core/-/issues/2547Import the base upgrader2021-04-23T22:10:52ZtottenImport the base upgraderOverview
----------------------------------------
Many extensions include an "upgrader", "base upgrader" class, and wiring to support them. This patch migrates a lot of that boilerplate to core and does some cleanup in the process.
Cur...Overview
----------------------------------------
Many extensions include an "upgrader", "base upgrader" class, and wiring to support them. This patch migrates a lot of that boilerplate to core and does some cleanup in the process.
Current behavior
----------------------------------------
Most extensions which define schema rely on `civix`'s upgrader template. It defines these four elements:
* `myext.php`: This has stubs for `hook_install`, `hook_uninstall`, `hook_upgrade`, etc -- each delegates to `myext.civix.php`.
* `myext.civix.php`: This has stubs for `hook_install`, `hook_uninstall`, `hook_upgrade`, etc -- each delegates to `CRM/Myext/Upgrader.php`.
* `CRM/Myext/Upgrader.php`: This is the customizable list of install/uninstall/upgrade steps.
* `CRM/Myext/Upgrader/Base.php`: This is a large boilerplate file. It has a library of helpers+adapters.
Proposed behavior
----------------------------------------
Going forward, core extensions (and future civix-based extensions) will only define two elements:
* `info.xml`: Declare `<upgrader>CRM_Myext_Upgrader</upgrader>`.
* `CRM/Myext/Upgrader.php`: As before, this is the customizable list of install/uninstall/upgrade steps. It implements an interface (`CRM_Extension_Upgrader_Interface`). For convenience, it can extend the base implementation (`CRM_Extension_Upgrader_Base`) which matches the old boilerplate.
Comments
----------------------------------------
This is not an end in itself -- it is a step toward a few other things:
* For #2518 - We'd like to enqueue upgrade tasks in topological order. One way to do that is to control the order of dispatch for `hook_upgrade`. But in the current regime, we don't have enough control over the order in which `hook_upgrade` fires.
* For https://github.com/totten/civix/issues/175 - We'd like to dedupe some of the civix boilerplate. https://github.com/civicrm/civicrm-core/pull/19865/ gets a long way there -- but only for runtime hooks (`hook_xmlMenu`, `hook_managed`, ad nauseum). Lifecycle hooks (`hook_install`, `hook_uninstall`, etc) are special/non-standard.
There's a common theme in those -- *the old way of wiring-up lifecycle-hooks is problematic, and making a direct change is also problematic*. This approach will provide alternate wiring for the lifecycle-hooks.
Note that this change does not require any hard-breaks:
* Existing extensions can still use all the same boilerplate and wiring, and they will behave the same way.
* The new arrangement only takes effect when you define the `<upgrader>` tag. (`civix` will be responsible for encouraging a transition.)
* When you do add the `<upgrader>` tag, you can remove a bunch of boilerplate, but the main substance (`CRM_Myext_Upgrader`) does not need any change. It supports the same methods as before (e.g. `upgrade_NNNN()`, `executeSql()`, `addTask()`, etc).
And a few final tidbits:
* This gives an opportunity to do a bit of cleanup in the upgrader code (e.g. extracting logical `trait`s).
* As before, it is still possible for an extension to completely reorganize its upgrade functionality (e.g. splitting out steps as separate files or using named-steps instead of numbered-steps).5.38.0https://lab.civicrm.org/dev/core/-/issues/2545Free memberschip sign up (eg. prayerteam) assumes contribution involved2023-07-29T05:03:22Zmagnolia61Free memberschip sign up (eg. prayerteam) assumes contribution involvedOverview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membersh...Overview
----------------------------------------
Managing memberships in civicrm currently pretty much assumes a contribution is involved. Which is not the case for many forms of memberships. It is even not possible to create a membership sign up page without using a contribution page!
Right now for our summercamps it's pretty strange for people to sign up to become a member of the prayerteam to "review their contribution". Although technically they give their contribution in the form of prayer one could argue.
Example use-case
----------------------------------------
1. Create a membership sign up page in CiviCRM for a free membership
2. Look at the wording of the sign-up button
Current behaviour
----------------------------------------
The current button to sign up for a membership says 'review your contribution'.
Proposed behaviour
----------------------------------------
The button text here should be editable, or for signing up for free memberships a different default wording should be used.
Comments
----------------------------------------
Consistent UI would be I guess to be able to create a membership sign up page from the membership menu. Underwater this could be a contribution page with or without fees involved.https://lab.civicrm.org/dev/core/-/issues/2544Move Contact Layout Editor to a core extension2023-07-27T05:03:20ZcolemanwMove Contact Layout Editor to a core extensionAt some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core...At some point, it would be good to get rid of the hard-coded contact summary screen, and just let the Contact Layout Editor manage the display.
As an intermediary step, it probably makes sense to move Contact Layout Editor into the core tarball (via distmaker import), or the `ext/` directory of the core repo.
Today might not be the day for that, but logging some notes on it anyway:
- Today, the only benefit of moving the extension into core is it would be more visible to end-users.
However, in the future, benefits might include:
- Easier simultaneous development of extension & core with no version conflicts.
- Possible to enable the extension by default.
- Possible to rip out redundant functionality from core.
Challenges
- There isn't an easy upgrade path when an extension is moved into core; you end up with 2 copies of the extension
- Currently, the extension scanner does not give the core `ext/` directory top priority, which means older versions of the extension outside core would take precedence.
Considerations
- As handy as it is, Contact Layout Editor still uses smarty to render the page.
- Maybe the end-game is to make that page an Afform instead. However, that day is a long way off given Afform's current capabilities.https://lab.civicrm.org/dev/core/-/issues/2542Manage Events - Configure options have class disabled if no settings entered ...2023-05-30T22:24:47ZlarsssandergreenManage Events - Configure options have class disabled if no settings entered - causes Bootstrap issuesOn the Manage Events page, the Configure drop down options have class .disabled or .enabled depending on if any settings have been set for the specific option. Normally, all this does is make the option grey, but still clickable. But if ...On the Manage Events page, the Configure drop down options have class .disabled or .enabled depending on if any settings have been set for the specific option. Normally, all this does is make the option grey, but still clickable. But if Bootstrap is in play (i.e. using Shoreditch), then .disabled makes the link unclickable with no cursor change on hover. I looked at changing this in Shoreditch, but I wonder if it makes more sense to change in Core. After all, the link is not actually disabled, so maybe the disabled class is not appropriate here. Is there another class already in use that might make sense or is would it make sense to add a new class that just makes these links grey? Is disabled in use elsewhere for the same purpose?https://lab.civicrm.org/dev/core/-/issues/2541Clarify scheduled reminder options: Event Start Date -> Event Start, etc2021-04-28T04:27:09ZlarsssandergreenClarify scheduled reminder options: Event Start Date -> Event Start, etcSmall detail, but the options to send a scheduled reminder relative to an event are a little confusing.
![image](/uploads/5841527fcac9d04f62ea81190743bf99/image.png)
If you set a reminder for 4 hours before the "Event Start Date", does...Small detail, but the options to send a scheduled reminder relative to an event are a little confusing.
![image](/uploads/5841527fcac9d04f62ea81190743bf99/image.png)
If you set a reminder for 4 hours before the "Event Start Date", does that mean it is sent four hours before the start of the event (this is what happens) or 4 hours before 12:00am on the day of the event start?
I propose removing Date from all of these, so Event Start, Event End, Registration Start, Registration End.
[Pull request.](https://github.com/civicrm/civicrm-core/pull/20070)5.38.0https://lab.civicrm.org/dev/wordpress/-/issues/98Clash with MiniOrange OAuth plugin breaks CiviCRM Admin menu2021-04-19T09:27:59ZmarshClash with MiniOrange OAuth plugin breaks CiviCRM Admin menuCiviCRM uses a $_REQUEST['code'] parameter when building the CiviCRM navigation menu in wordpress. Unfortunately, so does the MiniOrange OAuth plugin for MS Azure integration, and the clash means that the Civi menu loses out and the menu...CiviCRM uses a $_REQUEST['code'] parameter when building the CiviCRM navigation menu in wordpress. Unfortunately, so does the MiniOrange OAuth plugin for MS Azure integration, and the clash means that the Civi menu loses out and the menu doesn't get rendered.
This could be fixed in Civi core, or in the MiniOrange plugin, but both of these are resource hungry in both locating and fixing and the processes to get it integrated.
A civi extension, however, can unset[$_REQUEST['code']; in hook_civicrm_config().
Many thanks go to @pradeep :)https://lab.civicrm.org/dev/core/-/issues/2540Print report permissions2022-06-02T18:01:45ZDevAppPrint report permissionshttps://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions...https://civicrm.stackexchange.com/questions/22261/how-to-hide-configuration-tabs-of-a-report-with-the-print-to-pdf-action-remain
But when disabling the “access Report Criteria” permission, the "Print report" and "Print to PDF" functions on a report appear, but do not function.
The user is just redirected back to the same report.
The functionality appears broken, as the report gives the option to print but it does not work without the additional permission.
Possible solutions:
- Give permissions to print if access report permissions are already granted and the user can view a report
- Add a new print permission and only show the print option if enabled for user
- Hide existing print options if view report criteria not selected, as the user can't print5.51.0Monish DebMonish Debhttps://lab.civicrm.org/dev/core/-/issues/2539If the number of groups and mailings for recipients is greater than 25, the l...2021-04-15T09:06:42ZlarsssandergreenIf the number of groups and mailings for recipients is greater than 25, the list is silently truncatedIf you enter more than 25 groups or past mailing recipients in a mailing and then save it, the list of groups is truncated to 25 without any warning. [Past issue on Mosaico for this.](https://github.com/veda-consulting-company/uk.co.veda...If you enter more than 25 groups or past mailing recipients in a mailing and then save it, the list of groups is truncated to 25 without any warning. [Past issue on Mosaico for this.](https://github.com/veda-consulting-company/uk.co.vedaconsulting.mosaico/issues/428)
[Here's a pull request.](https://github.com/civicrm/civicrm-core/pull/20069) Thanks to bhahumanists for pointing me to the fix.https://lab.civicrm.org/dev/core/-/issues/2538APiv4 fk vs pseudoconstant2023-07-26T05:03:25ZeileenAPiv4 fk vs pseudoconstant@colemanw we recently removed the pseudoconstant for campaign_id from a bunch of fields but there is a benefit to the pseudoconstants I didn't realise - with both declared I can use
```
CRM.api4({participants: ['Participant', 'get', {
...@colemanw we recently removed the pseudoconstant for campaign_id from a bunch of fields but there is a benefit to the pseudoconstants I didn't realise - with both declared I can use
```
CRM.api4({participants: ['Participant', 'get', {
where: [["status_id:name", "=", 'Attended']],
limit: 25
}]}).then(function(batch) {
// do something with batch.participants array
}, function(failure) {
// handle failure
});
```
<field>
<name>status_id</name>
<uniqueName>participant_status_id</uniqueName>
<title>Status ID</title>
<headerPattern>/(participant.)?(status)$/i</headerPattern>
<import>true</import>
<type>int unsigned</type>
<export>true</export>
<required>true</required>
<default>1</default>
<comment>Participant status ID. FK to civicrm_participant_status_type. Default of 1 should map to status = Registered.</comment>
<add>1.7</add>
<pseudoconstant>
<table>civicrm_participant_status_type</table>
<keyColumn>id</keyColumn>
<labelColumn>label</labelColumn>
</pseudoconstant>
<html>
<type>Select</type>
<label>Status</label>
</html>
</field>
But the same doesn't work on campaign anymore
```
CRM.api4('Participant', 'get', {
where: [["campaign_id:name", "IS NULL"]],
limit: 25
}).then(function(participants) {
// do something with participants array
}, function(failure) {
// handle failure
});
```
I think this is a bigger issue on create where you might want to pass a machine name to a required FK field - in my case it looks like (
```
civicrm_api4('SearchDisplay', 'create', [
'values' => [
'name' => 'Equivalent_names',
'label' => 'Equivalent names',
'saved_search_id:name' => 'Equivalent_names',
'type' => 'table',
'settings' => '{"limit":20,"pager":true,"columns":[{"key":"name_a","label".....}'
]
]);
```https://lab.civicrm.org/dev/core/-/issues/2537CiviCRM alert, Disabled/Deleted fields on Smart Groups cannot be actioned. Sa...2021-04-15T22:30:27Zjustinfreeman (Agileware)CiviCRM alert, Disabled/Deleted fields on Smart Groups cannot be actioned. Saved Search exists, but the related Group has been deletedCiviCRM alert, Disabled/Deleted fields on Smart Groups **cannot be actioned**. Saved Search exists, but the related Group has been deleted. The end user is presented with this status alert and has no way to action it. The link to "View d...CiviCRM alert, Disabled/Deleted fields on Smart Groups **cannot be actioned**. Saved Search exists, but the related Group has been deleted. The end user is presented with this status alert and has no way to action it. The link to "View details and manage alerts" is **not** a clear action to resolve the issue so is not checked at all.
> Disabled/Deleted fields on Smart Groups
> The following smart groups include custom fields which are disabled/deleted from the database. This may cause errors on group page. You might need to edit their search criteria and update them to clean outdated fields from saved search OR disable them in order to fix the error.
The two links provided:
1. Link to the Group - /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fgroup&?reset=1&action=update&id
2. Link to the Search - /wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fcontact%2Fsearch%2Fadvanced&?reset=1&ssID=102
![civicrm-is-trying-to-tell-me-something-but-no-idea-what-exactly-needs-to-be-done](/uploads/c3c32b2ce71791eb2e1ff3db6f5f8d1c/civicrm-is-trying-to-tell-me-something-but-no-idea-what-exactly-needs-to-be-done.png)
![Screenshot_20210415_114820](/uploads/d5df2334030350641568796797048274/Screenshot_20210415_114820.png)
![Screenshot_20210415_114833](/uploads/25d5d61c9c082acd2deda01b5543a469/Screenshot_20210415_114833.png)
Workaround is to use the API explorer to delete the Saved Search in the back-end.
![Screenshot_20210415_115437](/uploads/742d66ad3c3c35dc56c4fee5e7191a4e/Screenshot_20210415_115437.png)
Agileware Ref: CIVICRM-1701
Version: CiviCRM 5.33.1
Related discussion on MM, https://chat.civicrm.org/civicrm/pl/bnnsex7tzpgdjdaqiok5pwwree5.37.0https://lab.civicrm.org/dev/core/-/issues/2536Empty extension requires tag misevaluated2023-07-26T05:03:26ZeileenEmpty extension requires tag misevaluatedI'm seeing
![image](/uploads/9ca2d57e51026f71ccf522fc6a6d55cc/image.png)
In the UI it seems to be the carriage return in the tag causing the issue
![image](/uploads/19c9c8f5e5fb469af62f846a747b9180/image.png)
But contactlayoutedit xm...I'm seeing
![image](/uploads/9ca2d57e51026f71ccf522fc6a6d55cc/image.png)
In the UI it seems to be the carriage return in the tag causing the issue
![image](/uploads/19c9c8f5e5fb469af62f846a747b9180/image.png)
But contactlayoutedit xml is unchangedhttps://lab.civicrm.org/dev/core/-/issues/2535Improve scheduled reminder UI for selection of event specific date or time be...2022-10-01T14:07:07ZlarsssandergreenImprove scheduled reminder UI for selection of event specific date or time before eventTo set a scheduled reminder for an event, you can either set it to a specific date or n hours, days, etc before the event. However, the UI to set these two options is confusing. If you set a date and n hours before, the n hours before is...To set a scheduled reminder for an event, you can either set it to a specific date or n hours, days, etc before the event. However, the UI to set these two options is confusing. If you set a date and n hours before, the n hours before is ignored. The user must click the X beside the date to remove it in order to make the second option work, which is non-standard and confusing (I had a staff member save a reminder multiple times who couldn't figure out why the n hours before option was disappearing).
![image](/uploads/860d004144b394d04c3d68bd92287ef6/image.png)
To make this clearer to users, I suggest adding radio buttons in front of the two options and only using the selected option.5.55.0https://lab.civicrm.org/dev/core/-/issues/2534ugly error message - what does it mean (apiv4 ++)2023-07-22T05:03:29Zeileenugly error message - what does it mean (apiv4 ++)@totten @colemanw I've seen this before but it wasn't replicable - however I now can.
I was trying to replicate the api call in https://github.com/eileenmcnaughton/deduper/pull/11 to figure out the error 'API error: No option list found...@totten @colemanw I've seen this before but it wasn't replicable - however I now can.
I was trying to replicate the api call in https://github.com/eileenmcnaughton/deduper/pull/11 to figure out the error 'API error: No option list found for 'saved_search_id'
However, I get a new and also ugly error in the api explorer
![image](/uploads/d1f87f1b3cfbe4ac39d94796cf883dfa/image.png)
![image](/uploads/6fdaed4b9b5f58c1862e9519ccc76d52/image.png)
Note that I did the following
1) opened search kit & created a search
2) attempted to create a search display in api explorer with JUST the search ID
I assume the underlying error is that I failed to provide all the mandatory fields - but the error just looks nasty
https://dmaster.demo.civicrm.org/civicrm/api4#/explorer/SearchDisplay/create?values=%5B%5B%22saved_search_id%22,%221%22%5D%5Dhttps://lab.civicrm.org/dev/core/-/issues/2533Afform - include Generic.html by default2021-04-25T21:00:40ZeileenAfform - include Generic.html by defaultI had a go at adding an afform in an extension today for a simple entity in the extension. I had to do 2 things to expose it
1) Add this file
https://github.com/eileenmcnaughton/deduper/commit/2ca0de29f66401584b966dcf42cd299b98af09a7
2...I had a go at adding an afform in an extension today for a simple entity in the extension. I had to do 2 things to expose it
1) Add this file
https://github.com/eileenmcnaughton/deduper/commit/2ca0de29f66401584b966dcf42cd299b98af09a7
2) hack a file similar to this one into core
https://github.com/civicrm/civicrm-core/compare/master...eileenmcnaughton:grantaff?expand=1#diff-e15ef3dc8f2633f790b8b2b34384aba83b9b5114e01a8f851e9e059273ae42d1
I think 2 could be addressed by fixing this line
https://github.com/civicrm/civicrm-core/blob/a191be25440e213fc29679584d2b62f5076369c2/ext/afform/admin/ang/afGuiEditor/afGuiEntity.html#L59 to include the specified file if exists else Generic.html
Note that simply downloading & enabling the master version of deduper if enough to get to the point where you can attempt to create the afform for ContactNamePair. It DOES work but the options section doesn't render
![image](/uploads/0a862ce216ac61045e9ef180d376abf6/image.png)
As a secondary issue, I couldn't figure out how to construct an edit url for ithttps://lab.civicrm.org/dev/core/-/issues/2531Tag(s) field from profile is not editable on Update multiple contacts action2023-08-02T05:03:26ZscardiniusTag(s) field from profile is not editable on Update multiple contacts actionOverview
----------------------------------------
Support adding tags during multiple updating contacts.
Example use-case
----------------------------------------
1. Create any profile with Tag(s) field
1. Search for any contacts
1. Sel...Overview
----------------------------------------
Support adding tags during multiple updating contacts.
Example use-case
----------------------------------------
1. Create any profile with Tag(s) field
1. Search for any contacts
1. Select several contacts and choose action "Update multiple contacts"
1. Choose newly created profile with Tag(s) field
Current behaviour
----------------------------------------
Opened list contains column Tag(s) but without any field, it is empty
Proposed behaviour
----------------------------------------
Tag(s) field has to be editable.scardiniusscardiniushttps://lab.civicrm.org/dev/core/-/issues/2530WordPress fresh install, civicrm.settings.php set the variable CIVICRM_UF_BAS...2023-07-25T05:03:18Zjustinfreeman (Agileware)WordPress fresh install, civicrm.settings.php set the variable CIVICRM_UF_BASEURL without a trailing slash http://localhost/wordpress and not http://localhost/wordpress/ which caused resource URLs to be wrongWordPress fresh install, civicrm.settings.php set the variable CIVICRM_UF_BASEURL without a trailing slash http://localhost/wordpress and not http://localhost/wordpress/ which caused resource URLs to be wrong. CiviCRM 5.36.0WordPress fresh install, civicrm.settings.php set the variable CIVICRM_UF_BASEURL without a trailing slash http://localhost/wordpress and not http://localhost/wordpress/ which caused resource URLs to be wrong. CiviCRM 5.36.0