Found while adding the skill filter for issue 905 pr 936 That PR needs a skill branch added togetOpportunityWhere, and while writing it I hit a bug already on develop.
The bug
Filtering opportunities by two of language, district or activity at the same time silently drops one of them. No error, just wrong results.
Reproduce: tick one activity and note the count, then also tick a language that does not apply to it. Expected 0, actual is the same count as the activity alone. Measured locally: activity alone 1, activity plus a non-matching language still 1.
Cause
src/server/utils/data/get-opportunity-where.ts builds the where-clause from
separate spreads, and three of them write the same deal key:
...(filter?.language ? { deal: { dealLanguage: ... } } : {}),
...(filter?.district ? { deal: { dealDistrict: ... } } : {}),
...(filter?.activity ? { deal: { dealActivity: ... } } : {}),
Object spread merges the top level and replaces everything below it, so when two
are set the later one wins outright and the earlier constraint never reaches the
query. Activity is last, so it beats both.
Fix
One shared deal object with the constraints as optional properties inside, so they accumulate. Adding the skill branch fe#936 needs is then one more propert in the same object rather than a fourth competing spread.
Blocks 936
Found while adding the skill filter for issue 905 pr 936 That PR needs a
skillbranch added togetOpportunityWhere, and while writing it I hit a bug already ondevelop.The bug
Filtering opportunities by two of language, district or activity at the same time silently drops one of them. No error, just wrong results.
Reproduce: tick one activity and note the count, then also tick a language that does not apply to it. Expected 0, actual is the same count as the activity alone. Measured locally: activity alone 1, activity plus a non-matching language still 1.
Cause
src/server/utils/data/get-opportunity-where.tsbuilds the where-clause fromseparate spreads, and three of them write the same
dealkey:Object spread merges the top level and replaces everything below it, so when two
are set the later one wins outright and the earlier constraint never reaches the
query. Activity is last, so it beats both.
Fix
One shared deal object with the constraints as optional properties inside, so they accumulate. Adding the skill branch fe#936 needs is then one more propert in the same object rather than a fourth competing spread.
Blocks 936