* Fix styling
* Fix dependency with apex-common,
A method that exists in apex-extensions, is now added to the apex-commons.
IMPORTANT: this is introducing a breaking change, as the second paramter of the method is flipped in meaning. From `omitNulls` to `includeNulls`.
* New package version 0.11.0-1-code-reformat created
* New package version 0.11.0-2-code-reformat created
* New package version 0.11.0-3-code-reformat created
---------
Co-authored-by: WimVelzeboer <wvelzeb1@its.jnj.com>
Co-authored-by: github-actions <github-actions@github.com>
* Upgrade API to 67.0
* Remove override due to build failure
* Fix test due to dependency changes
* Fix failing tests due to dependency changes
* New package version 0.10.0-1-api-upgrade-67 created
---------
Co-authored-by: Wim Velzeboer <wvelzeb1@its.jnj.com>
Co-authored-by: github-actions <github-actions@github.com>
* Override getRecordsWithNotBlankFieldValues in fflib_SObjects2
The base fflib_SObjects implementation casts every value to String, which
throws a TypeException on Date/Datetime/Number/Lookup fields. This override
generalises the check to "any non-null value, and for Strings also non-blank"
so the helper works for every field type.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Update fflib_SObjects2.cls
Rename method to getRecordsWithNonBlankFieldValues
* Update fflib_SObjects2Test.cls
Rename method to getRecordsWithNonBlankFieldValues
* Update fflib_SObjects2.cls
Rename variable
Co-authored-by: Robin Weymans <robin.weymans@mylighthouse.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: William Velzeboer <6429417+wimvelzeboer@users.noreply.github.com>
* Add overloads for decimal values in getRecords and getRecordsNotIn
* updated readme file
* Add compatibility for multiselect picklists for the `getRecords` method
The methods are no longer depended on the domain method getRelatedFieldByDomainType, which could only relate a relationship with a single field. This change will allow to build the map with the correct fields when there are multiple relationships to the related SObjectType.
for example if an SObject has two relations to Account; BillingAccountId and AccountId, then we can now specify in the method parameters which relationship should be taken.
Signed-off-by: WimVelzeboer <william@velzeboer.nl>
wim