fix: use loose type comparison for list__in and list__not_in #1326
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All Submissions:
Changes proposed in this Pull Request:
Currently
list__in
andlist__not_in
criteria matching functions useincludes
(which enforces strict type comparison) to compare segmentation criteria values with reader data values. However, we've seen varying behavior across different sites where IDs get stored in reader data as strings instead of integers, which causes these matching functions to fail.This change allows the type comparison to be loose using
==
, which should solve the issue.How to test the changes in this Pull Request:
Unit tests should prove this, but to test functionally:
release
, create a segment and choose a product in the "Does not have active subscription" option. Publish a prompt to that segment.np_reader_1_active_subscriptions
value. If it's an array containing an integer click the value to edit it to a string with the same number, like so:"275"
and the segment expects275
).Other information: