Development issueshttps://lab.civicrm.org/groups/dev/-/issues2019-10-20T20:04:13Zhttps://lab.civicrm.org/dev/core/-/issues/1335Saving a case type can give a php warning, but the warning is more hidden tha...2019-10-20T20:04:13ZDaveDSaving a case type can give a php warning, but the warning is more hidden than usual so it seems like everything is okIgnoring for the moment the part about the hidden warning, what's happening is:
When you retrieve a case type, e.g. via the api or lower level functions, [this line](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseT...Ignoring for the moment the part about the hidden warning, what's happening is:
When you retrieve a case type, e.g. via the api or lower level functions, [this line](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseType.php#L283) is doing this:
`$activityType = json_decode(json_encode($activityTypeXML), TRUE);`
which seems to be a quickie way of converting the whole object and its children to an array. This works fine when none of the children have blank node text, and you get `$caseType[...intermediate keys...]['default_assignee_contact'] = '203'` or whatever. If they are blank, like `<default_assignee_contact></default_assignee_contact>`, then the blank node text is actually treated as an empty object, and so gets converted to an empty array and you get `$caseType[...intermediate keys...]['default_assignee_contact'] = []`. By itself not too bad.
Now when you convert back to xml, either by saving or calling api.create or a lower level function, [these lines](https://github.com/civicrm/civicrm-core/blob/5.18.3/CRM/Case/BAO/CaseType.php#L152-L156) do this:
```
$xmlFile .= "<ActivityType>\n";
foreach ($values as $key => $value) {
$xmlFile .= "<{$key}>" . self::encodeXmlString($value) . "</{$key}>\n";
}
$xmlFile .= "</ActivityType>\n";
```
The encodeXmlString function just calls htmlspecialchars. But if you pass an array to htmlspecialchars it gives a warning.
So at least two possibilities for how to fix:
1. Alter encodeXmlString to return the empty string if it's not passed a string to begin with.
2. Don't return mixed data types for elements and instead either return an empty string if it's an empty array, or omit the xml element completely. I'd hesitate a little because technically it would change for example what the api returns for CaseType.get for something like default_assignee_contact when it's blank.
Sample steps to reproduce:
1. Create a new case type.
1. Add a timeline.
1. Add a followup activity to the timeline and for default assignee select By Relationship, and pick a relationship type.
1. Click Save.
1. Now go back and edit the case type and don't change anything just click save.
1. Check drupal watchdog and you'll see the warning listed.
1. At this point you can also do something further like this using cv, but you first have to edit CRM_Case_BAO_CaseType::convertDefinitionToXML() because for some reason when run through cv error_reporting gets set to E_ERROR only, so add a line at the top of that function `error_reporting(E_ALL);`. Yet another weirdness.
1. Then you can do this, but replace '3' with the case type id. `cv php:eval "$id = 3; $x = civicrm_api3('CaseType', 'get', ['id' => $id]); $y = CRM_Case_BAO_CaseType::convertDefinitionToXML($x['values'][$id]['name'], $x['values'][$id]['definition']);"`
1. Check drupal watchdog and you'll see the same warning.
Another way to think of this is that api.get followed directly by api.create without touching the data gives a warning.
Why this doesn't pop up a warning on the screen, or output anything during `cv` calls, is a little bit of a mystery. What I can see is that drupal's error_handler is logging it to drupal watchdog, but in other places throughout civi warnings that get logged to drupal watchdog usually show up on the screen, if not on the same page then when you go to another page. I'd be curious if running this through cv in joomla or wordpress does output the warning.5.20.0https://lab.civicrm.org/dev/core/-/issues/1334Cannot submit event registration for free ticket2019-10-20T23:06:09ZiamandanycCannot submit event registration for free ticket**Overview**
My event registration and payment form suddenly stopped working for the complimentary/free ticket option. Users cannot press "continue" to submit the form if they chose complimentary ticket.
Event registration page: [click ...**Overview**
My event registration and payment form suddenly stopped working for the complimentary/free ticket option. Users cannot press "continue" to submit the form if they chose complimentary ticket.
Event registration page: [click here](https://apprenticelearning.org/civicrm/?page=CiviCRM&q=civicrm%2Fevent%2Fregister&reset=1&id=7)
**Before**
It was working fine and we registered a bunch of complimentary ticket users until it suddenly stopped working.
**After**
When you click the submit button, the next page does not load and it stays on the current page, i.e. folks cannot register.https://lab.civicrm.org/dev/financial/-/issues/80Noisily deprecate transact api2019-10-24T21:16:11ZeileenNoisily deprecate transact apiWe should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/79We should add in deprecation warnings using CRM_Core_Error::deprecatedFunctionWarning - these show on dev sites but not live
First step is https://lab.civicrm.org/dev/financial/issues/795.20.0https://lab.civicrm.org/dev/financial/-/issues/79Deprecate Contribute.transact api2019-10-24T21:15:57ZeileenDeprecate Contribute.transact apiThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussionThe minimum we should do is deprecate from api explorer & I will do that in this PR. (Agreed in Barcelona)
I think we probably should do a noisier deprecation than that but that will stale-out some PRs currently under discussion5.20.0https://lab.civicrm.org/dev/financial/-/issues/77PaymentProcessor.pay should handle 'invoice_id' & map it to a getter so pro...2019-11-04T23:47:09ZeileenPaymentProcessor.pay should handle 'invoice_id' & map it to a getter so processors can retrieve it5.20.0https://lab.civicrm.org/dev/core/-/issues/1333Balance Due of completed contribution does not show as 0 but full amount in p...2019-10-22T00:07:05Zmagnolia61Balance Due of completed contribution does not show as 0 but full amount in payment receiptUsing 5.18.3 with patch https://github.com/civicrm/civicrm-core/pull/15545 (to be able to send the payment receipt at all)
I noticed that in different scenarios's (A. Pay the contribution in one payment & B. Pay it in a few payments)
the...Using 5.18.3 with patch https://github.com/civicrm/civicrm-core/pull/15545 (to be able to send the payment receipt at all)
I noticed that in different scenarios's (A. Pay the contribution in one payment & B. Pay it in a few payments)
the payment notification email shows the wrong amount for the Balance Due.
Interestingly it show the proper Balance Due when doing partial payments
```
Total Amount : 100
This Payment Amount : 60
Balance Due: 40
```
But at the final payment to full fill the contribution it shows the same as the full amount
```
Total Amount : 100
This Payment Amount : 100
Balance Due: 100
```5.18.4https://lab.civicrm.org/dev/core/-/issues/1332Payment details not saved correctly from Additional payment form2019-10-22T00:06:56ZeileenPayment details not saved correctly from Additional payment formDetail is https://github.com/civicrm/civicrm-core/pull/15537Detail is https://github.com/civicrm/civicrm-core/pull/155375.18.4https://lab.civicrm.org/dev/core/-/issues/1331Don't freeze fields for auto-renew memberships2020-03-30T14:18:17ZwmortadaDon't freeze fields for auto-renew membershipsIf a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* M...If a membership is linked to a recurring payment some of the fields are frozen, which means that a user is unable to edit them when they visit the edit membership screen.
This affects the following fields:
* Membership organisation
* Membership type
* ~~Membership end date~~ [no longer frozen]
* Membership status
![image](/uploads/2ac776a76bf0a662e89f6426604da0ce/image.png)
This issue is split out from https://lab.civicrm.org/dev/core/issues/1126 which looked specifically at the end_date field. This fix has now been merged into core ([PR #15540](https://github.com/civicrm/civicrm-core/pull/15540)).
I've created this ticket to look at the other fields that are also frozen following discussion in my [original PR](https://github.com/civicrm/civicrm-core/pull/15505).
# Issue
The ability to edit the membership type is an issue for our organisation because sometimes people sign up for the wrong membership type and we need to change this. For non-recurring payments this is no problem, we can just change it manually and if necessary take additional payment or make a refund. But for recurring payments we are unable to do this because the field is frozen. We are then stuck and have no way of changing the membership type in CiviCRM through the UI.
The ability to edit the membership organisation isn't an issue for us as we only have one membership organisation. However, other organisations may want to be able to do this for the same reason as above.
The ability to edit the membership status also isn't an issue for us, but I don't really understand the logic of freezing it for auto-renew memberships and so I'm also including it here for consistency.
# Proposal
My proposal is that CiviCRM core shouldn't freeze any of these fields. If required they can be frozen by an individual payment processor or other extension.
My feeling was that the logic about whether the fields should be editable or not will vary from organisation to organisation depending on the business processes of the organisation and the payment processor that they use. So, I don't feel that CiviCRM core should be imposing this. It should be down to each organisation to make their own customisations as required. If and where appropriate it could be included in the logic for an individual payment processor.
This involves removing the relevant code as per [PR #15505](https://github.com/civicrm/civicrm-core/pull/15505).
# Summary of changes
*This summary is for the benefit of those who don't want to read the lengthy discussions below. It can also be used in the release notes.*
This change fixes an issue which meant that it wasn't possible to edit some membership fields when a membership was set to auto-renew. Following the change it is now possible to edit all of the fields on the edit membership form.
* These fields are no longer frozen:
* Membership Organisation
* Membership Type
* Membership Status
* A warning is displayed to alert users that any changes they make to the membership may not be reflected in the payment processor
* The Membership Organisation/Type field is initially uneditable but there is a link to make it editable
If the membership is *not* set to auto-renew there is no change to the edit membership form. So this change will have no effect on organisations that don't offer recurring payments for membership.
If your organisation *does* offer recurring payments for membership you should make staff aware of these changes. In particular you should make them aware that changes they make to the membership may not be reflected in the payment processor. This means that if you make a change you may also need to update the corresponding record in the payment processor. This depends on the particular payment processor that your organisation uses so you will need to check the functionality that your payment processor supports.
If you would like to restore the previous functionality so that these fields are frozen and uneditable you can install this extension: [Freeze Membership Fields](https://lab.civicrm.org/extensions/freeze-membership-fields).
The change will be included in CiviCRM version 5.25 which is due for release in May 2020. See [PR #16609](https://github.com/civicrm/civicrm-core/pull/16609) for more details on the change.
https://lab.civicrm.org/dev/core/-/issues/1330Too many custom fields2022-06-29T04:32:32ZkristinecToo many custom fieldsAdding 93+ custom fields within a custom_group seems to cause a DB Constraint error and gives an error when clicking manage cases (for some cases). To replicate:
1. Create a custom group
2. Add 93 custom fields
3. Once you pass 93, the ...Adding 93+ custom fields within a custom_group seems to cause a DB Constraint error and gives an error when clicking manage cases (for some cases). To replicate:
1. Create a custom group
2. Add 93 custom fields
3. Once you pass 93, the error "DB Constraint Violation - custom_group_id should possibly be marked as mandatory for CustomField,create API. If so, please raise a bug report" appears when saving a new custom field.
4. Find several cases and when trying to access their case page, I get an error: "case_id is not valid : 1."
5. Disable the custom group. Error #4 disappears.
This can be marked as a paid-issue-queue.https://lab.civicrm.org/dev/core/-/issues/1329Too many dead people in sample data2019-11-27T02:16:43Zjustinfreeman (Agileware)Too many dead people in sample dataCiviCRM sample data contains too many dead people (Contact, Individual, Deceased = True) - there's a total of 27 dead contacts. Can we bring these people back to life please?
The number of dead people that you actually want in your CRM ...CiviCRM sample data contains too many dead people (Contact, Individual, Deceased = True) - there's a total of 27 dead contacts. Can we bring these people back to life please?
The number of dead people that you actually want in your CRM data should be a very small percentage, unfortunately this state of being seems to be over-represented in the sample data.
Let's breathe some life back into the sample data!
Agileware Ref: CIVICRM-13775.20.0https://lab.civicrm.org/dev/core/-/issues/1327Address 'noise' (& performance) of status checks2023-03-17T05:03:25ZeileenAddress 'noise' (& performance) of status checksAt the New York sprint improving status checks was discussed with a view to addressing concerns that:
* Some system status messages are slow in some cases (large Dbs, connectivity issues) in an unresolvable way & sysadmins want to be ab...At the New York sprint improving status checks was discussed with a view to addressing concerns that:
* Some system status messages are slow in some cases (large Dbs, connectivity issues) in an unresolvable way & sysadmins want to be able to just stop the pain for some or all alerts
* Message is overly & inappropriately alarming for some users - e.g a manager might see a ‘warning’ and think it’s a bug.
We agreed to do the following
1. ~~Add is_active to civicrm_status_pref to disable individual status checks - this would be exposed via api but not UI. (we want it to be possible to disable them but not ‘easy’ as it needs to be very deliberate & done with clear understanding.~~
This was done in 5.19 - https://lab.civicrm.org/dev/core/issues/1295
1. Add new granular ‘view status checks permission’ - github here https://github.com/civicrm/civicrm-core/pull/14521 under discussion
1. Prototype less aggressive notification for alerts - e.g ‘you have 7 todo items’ or red (beige) ‘7’ in menu rather than an alert popups - do we still do ‘error’ as a popup?
1. Not in the sprint doc but I believed we agreed that the checks should run by cron & be displayed at user login rather than running on user login - we should add al issue when someone is ready to work on that.
The less aggressive notifications are more of a wishlist item at this stage. It would be good to fund Coleman to do it - otherwise it might flounder a bit.
Regarding the new granular status permission check - we discussed this again in Barcelona as the intent was unclear. @totten clarified his permission is that once we add ‘view status checks' permission then people with 'Administer CiviCRM' OR ‘view status checks' would see the checks. This doesn't immediately mitigate the issue as it would generally not be possible to remove Administer CiviCRM so it doesn't achieve much.
However, along with this @totten mooted the idea of adding 2 new permissions that are actually roles -
- Administer CiviCRM System
- Administer CiviCRM Data
The latter would have implicit permissions like Administering option values whereas the former would have things like view status checks by default. The main goal here would be to make it possible for sites to remove 'Administer CiviCRM' and leave most admins with just 'Administer CiviCRM Data'.
The idea was that if we have a call CRM_Core_Permission::check('view status checks') then it would return TRUE if the person has the 'view status checks' permission OR the 'Administer CiviCRM Data' permission
The issue is that the 'devil is in the detail' - for example we have a bunch of permissions jammed under 'Administer CiviCRM' that would need putting into one role or the other. We could mature this permission in an extension if we want as there is a usable hook
Related issue
https://lab.civicrm.org/dev/core/issues/1041
https://docs.google.com/document/d/1z1Lm-DUrri6xPzGXU37nLk5SfRjo4i9Elvx-lfbmK24/edit#heading=h.164d9ulc2oa3https://lab.civicrm.org/dev/core/-/issues/1326when filing on case, original activity not retained2023-09-08T20:15:55Zlcdwebwhen filing on case, original activity not retainedIn previous versions, when an activity was filed to a case, the activity remained on the contact record with the text "Filed on case..." prepended to the subject. That changed with this commit:
https://github.com/civicrm/civicrm-core/com...In previous versions, when an activity was filed to a case, the activity remained on the contact record with the text "Filed on case..." prepended to the subject. That changed with this commit:
https://github.com/civicrm/civicrm-core/commit/9a30d940eee1d62e57d1a5db7a8651b46cc7a674
The activity still has the text prepended to the subject, but because the activity is marked as not a current revision, it doesn't appear on the contact record's activity listing.
I think the activity should be marked as not a current revision if the activity is moved, but not if filed on a case. Looking for feedback on the concept before I file a PR. @mattwire can you chime in, as that was your PR.lcdweblcdwebhttps://lab.civicrm.org/dev/core/-/issues/1325Autoassignees on case activities might assign the wrong person if client has ...2020-07-06T23:21:37ZDaveDAutoassignees on case activities might assign the wrong person if client has another case with that role assigned thereIn a case type timeline you can configure autoassignees for activities based on a role in the case. To reproduce:
1. In the case type edit screen configure a role like "Benefits Specialist is".
2. Add another timeline (you can use the s...In a case type timeline you can configure autoassignees for activities based on a role in the case. To reproduce:
1. In the case type edit screen configure a role like "Benefits Specialist is".
2. Add another timeline (you can use the standard one but it's easier to see with a new one).
3. In that timeline add a followup activity and set the autoassignee to be by relationship and to "Benefits Specialist is".
4. Save the case type.
5. Create a case of that type.
6. Assign the role of "Benefits Specialist is" to someone.
7. Add the other timeline via the Add Timeline dropdown on manage case. So far ok.
8. Create another case for the *same client*.
9. Don't assign the role of "Benefits Specialist is".
10. Add the other timeline again to this case.
11. The Benefits Specialist from the OTHER CASE gets assigned here.
**Note that this happens even if you close the first case before the second.**
I think there's two things going on. One is a variation of issues with closed cases and relationships noted elsewhere, and the other is that the lookup for who to assign doesn't take case_id into account. The first part though would be made irrelevant here if the case_id is taken into account.
There is a little gotcha for relationships that can and usually do exist outside the case, like spouse. If you assign the relationship outside the case, then you might actually expect it to be assigned to the activity without having to assign it specifically as a role on every case.
TBD
And this isn't a recent issue I'm thinking it's always been independent of case_id since introduced.5.29.0https://lab.civicrm.org/dev/core/-/issues/1324Customfields attached to addresses break the profile page2019-10-28T08:08:37ZVangelisPCustomfields attached to addresses break the profile page## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm...## General
When we set an address customfield on an address and then we add that field into a profile, the profile page breaks on edit mode.
Returning error: `DB Error: no such field`
## How to reproduce
On https://dmaster.demo.civicrm.org (CiviCRM 5.20.alpha1) :
* Create a new CustomGroup and assign it to the entity 'Address'
* Create a new customfield (for example of type textfield)
* Populate the field with some dummy information
* Create a new profile and add 2 fields:
* Street Address
* Your newly created customfield
* Click on 'More -> Use edit mode'
* The page should break with error `DB Error: no such field`
## Background
It seems that the issue starts here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Contact.php#L1784
and then goes here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1036
and the actual join should take place somewhere here: https://lab.civicrm.org/dev/core/blob/master/CRM/Contact/BAO/Query.php#L1307
In short: There is an additional field, the id of the customtable that is holding the customfield in the select query that is not being joined properly (join is actually missing) from the constructed query.5.20.0https://lab.civicrm.org/dev/core/-/issues/1323Can't use "Add Activity" task from Search Builder2019-10-16T20:33:23ZJonGoldCan't use "Add Activity" task from Search BuilderSteps to replicate:
* Do a search from Search Builder.
* Select *Add Activity* as your task.
* Submit the activity.
Observe your yellow screen of death.
It's a one-line fix, the wrong user context is passed to the state machine.Steps to replicate:
* Do a search from Search Builder.
* Select *Add Activity* as your task.
* Submit the activity.
Observe your yellow screen of death.
It's a one-line fix, the wrong user context is passed to the state machine.5.19.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/1322payment_or_refund_notification 'FROM' address is missing2019-10-21T05:19:37Zmagnolia61payment_or_refund_notification 'FROM' address is missingThe Payment_or_refund mail (send when recording a payment) does not get send with us.
We get the message that the "FROM" address is missing. All other mails get send perfectly.
```
The mail library returned the following error message:
N...The Payment_or_refund mail (send when recording a payment) does not get send with us.
We get the message that the "FROM" address is missing. All other mails get send perfectly.
```
The mail library returned the following error message:
No From: address has been provided
```
When I change our outbound mail settings to database, I can see indeed the from address is missing from the headers.
The following header is from the add payment mail. This fails to send, lacks the 'From' field and is also missing the return path.
```
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_a5d5e8e8a2563fab89e0f4ae653c0aee"
To: Testuser
Subject: Payment Receipt -
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Date: Wed, 16 Oct 2019 12:52:43 +0200
```
The following mail is the contribution receipt. This gets send and has the From field in the header
```
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_76561187d0121e320a4a0d0fdb8432cb"
From: "Testuser"
To: Testleid Groepsleiding
Subject: Contribution Receipt - Testleid Groepsleiding
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Return-Path: testuser@gmail.com
Date: Wed, 16 Oct 2019 12:52:16 +0200
```5.18.4https://lab.civicrm.org/dev/core/-/issues/1320Workflow templates - Include displayname in subject2019-10-26T20:33:11Zmagnolia61Workflow templates - Include displayname in subjectMany email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it mak...Many email providers group emails with the same subject which leads to time-consuming processes for many organisations, and many additional unnecessary clicks.
Some system workflow template subjects include the display name.
Also it makes the email more personal as it is clear who it is addressed to.
This is proven to be beneficial for open-rates of transactional mails.
The messages will be upgraded in 5.20alpha1 by #15491
https://github.com/civicrm/civicrm-core/pull/155135.20.0magnolia61magnolia61https://lab.civicrm.org/dev/core/-/issues/1319No Household Member Relationship Created when an Individual shares a relation...2020-02-19T20:48:07ZalicefruminNo Household Member Relationship Created when an Individual shares a relationship with a householdWhen editing a Contacts Address:
IF one clicks "Use another contact's address"
AND then selects a HOUSEHOLD contact to share an address with
THEN the address is shared BUT a **household member relationship is NOT created**.
The S...When editing a Contacts Address:
IF one clicks "Use another contact's address"
AND then selects a HOUSEHOLD contact to share an address with
THEN the address is shared BUT a **household member relationship is NOT created**.
The Shared Address help text says: "If you link an individual's address to an organization, an employee-employer relationship will be automatically created. **If you link an individual's address to a household, a household member relationship is created.**"
Which leads me to believe this is a regression. It seems the functionality for linking an individual's address to an organization has been enhanced specifically:
When one clicks "Use another contact's address"
AND then selects a ORGANIZATION contact to share an address with
THEN a "Set this organization as current employer" checkbox appears
IF checked then a relationship is created... if not no relationship is created
as discussed [here](https://github.com/civicrm/civicrm-core/pull/12574)
Perhaps a similar checkbox should appear when sharing a household address.
![sharedAddressHelpText](/uploads/9800c3df1b22b02f4342ccf05fb141cc/sharedAddressHelpText.png)5.23.0https://lab.civicrm.org/dev/user-interface/-/issues/11Remove CiviCRM install count from dashboard2023-12-02T18:42:58ZnicolRemove CiviCRM install count from dashboardIt was said at the 2019 Summit/Sprint that a requirement to get CiviCRM listed in the Wordpress plugins directory was to turn off statistics pingback on new installs by default - and this happened a few months ago (can anyone confirm? @c...It was said at the 2019 Summit/Sprint that a requirement to get CiviCRM listed in the Wordpress plugins directory was to turn off statistics pingback on new installs by default - and this happened a few months ago (can anyone confirm? @cividesk?). As a result all new installs of CiviCRM are not pinging stats collection so the total site count appears to have fallen in the same period from near 11,000 six months ago to around 10,000 today:
![image](/uploads/0630494d9e7df38a00001212afca3d9e/image.png)
Perhaps there is is another cause, but is it time to just remove this stat from the main CiviCRM dashboard? This was a post-it proposal put to the UX/UI group during the sprint as the notice seems to be giving a false impression of the project being in decline. Not sure what this would entail but it appears linked to this template: [templates/CRM/Dashlet/Page/GettingStarted.tpl](https://github.com/civicrm/civicrm-core/blob/8b9a8f4abb25cfa7a498eaaa3e459e4d313e350a/templates/CRM/Dashlet/Page/GettingStarted.tpl) & this file: [CRM/Dashlet/Page/GettingStarted.php](https://github.com/civicrm/civicrm-core/blob/bdeb5d154507df2dc913fc1ee9aaedfaa4721c04/CRM/Dashlet/Page/GettingStarted.php).bgmbgmhttps://lab.civicrm.org/dev/core/-/issues/1318Import Activity with custom field fails2021-01-28T23:07:08ZPradeep Nayakpradpnayak@gmail.comImport Activity with custom field failsWhen trying to import activity with custom field(type:checkbx) it fails with error '1' is not a valid option for field custom_XX.
To replicate:
1. Create custom field for Activity of type checkbox with Label and value as string.
2. Impo...When trying to import activity with custom field(type:checkbx) it fails with error '1' is not a valid option for field custom_XX.
To replicate:
1. Create custom field for Activity of type checkbox with Label and value as string.
2. Import Activity with Label of custom field.5.35.0