-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/pt bdi support checkbox fields #4105
Conversation
// This allows for mapping checkboxes to a tri-state picklist - None, True, False - or a text with either | ||
// blank, "True", or "False" | ||
String destinationSObjectname = destinationRecord.getSObjectType().getDescribe().getName(); | ||
if ((UTIL_Describe.getFieldDisplayType(destinationSObjectname, destinationField) == |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Field name must be LOWERCASE. Also namespace support.
…alesforceFoundation/Cumulus into feature/pt-bdi-support-checkbox-fields
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few stylistic comments is all from me! Looks great.
// This allows for mapping checkboxes to a tri-state picklist - None, True, False - or a text with either | ||
// blank, "True", or "False" | ||
String destinationSObjectname = destinationRecord.getSObjectType().getDescribe().getName(); | ||
if (!(value instanceof Boolean) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know were nesting a few ifs here, but I might consider adding one more and putting the destinationSObjectname
var inside the first value instanceof Boolean
if block, since we don't need to get the SObject name to inspect this unless the field is Boolean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another option could be to extract the comparison to a little utility method, for readability - something like if(booleanMappingIsValid(value, destinationSObjectname)
. This is good - I'm just trying to think through it if it could be a little more readable what with multiple calls to those UTIL classes here.
@@ -878,6 +878,18 @@ global with sharing class BDI_DataImportService { | |||
return false; | |||
} | |||
|
|||
// If the destination field is a Boolean and the DI field intermediate requires interpretation to Boolean | |||
// This allows for mapping checkboxes to a tri-state picklist - None, True, False - or a text with either |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this allow for mapping from picklists with any values? if so we might not want to specifify "None" here, since admins can configure whatever PL values they want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None just means null or no value ... it's important for the behavior but I've been struggling with how to type that to make it clear that it's not an actual picklist option with text "none" but that there IS a valid option in the picklist that is neither true or false and evaluates to null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should just say "null" ... 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if the PL values aren't parse-able to a boolean value with Boolean.valueOf() it will fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see! Ok, yeah, very cool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more little idea, but all up to you of course - this is super cool and exciting to add into bdi!
@@ -878,6 +878,18 @@ global with sharing class BDI_DataImportService { | |||
return false; | |||
} | |||
|
|||
// If the destination field is a Boolean and the DI field intermediate requires interpretation to Boolean | |||
// This allows for mapping checkboxes to a tri-state picklist - None, True, False - or a text with either |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see! Ok, yeah, very cool.
// This allows for mapping checkboxes to a tri-state picklist - None, True, False - or a text with either | ||
// blank, "True", or "False" | ||
String destinationSObjectname = destinationRecord.getSObjectType().getDescribe().getName(); | ||
if (!(value instanceof Boolean) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another option could be to extract the comparison to a little utility method, for readability - something like if(booleanMappingIsValid(value, destinationSObjectname)
. This is good - I'm just trying to think through it if it could be a little more readable what with multiple calls to those UTIL classes here.
**lurch: attach W-031084 |
…alesforceFoundation/Cumulus into feature/pt-bdi-support-checkbox-fields
// null, "True", or "False" | ||
if (!(value instanceof Boolean) && | ||
fieldIsBooleanDisplayType(destinationRecord, destinationField)) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 much easier to read!!
Bring more responsible support for mapping to checkbox fields to BDI/BGE. Mapped field on
Data Import must be picklist with None/True/False or text field for full support, but current user processes that use checkbox-to-checkbox mappings will be unaffected by this change.
Critical Changes
Changes
Batch Gift Entry Enhancements
Issues Closed
New Metadata
Deleted Metadata