apps/web/app/lib/surveys/surveys.ts (3)

538-566: ⚠️ Potential issue | 🔴 Critical

Critical: META_OP_MAP is undefined at module scope, causing runtime error.

processMetaFilters references META_OP_MAP at line 551, but META_OP_MAP is now only defined inside generateElementAndFilterOptions (line 157). This will cause a ReferenceError at runtime when any meta filter is applied.

Proposed fix: Define META_OP_MAP at module scope or pass it as parameter

Option 1: Keep a module-level map for logic comparisons (using English keys for internal logic):

+// Internal operation mapping - uses English keys for logic comparisons
+const META_OP_MAP = {
+  Equals: "equals",
+  "Not equals": "notEquals",
+  Contains: "contains",
+  "Does not contain": "doesNotContain",
+  "Starts with": "startsWith",
+  "Does not start with": "doesNotStartWith",
+  "Ends with": "endsWith",
+  "Does not end with": "doesNotEndWith",
+} as const;

Option 2: Pass the map as a parameter to processMetaFilters.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/app/lib/surveys/surveys.ts` around lines 538 - 566,
processMetaFilters currently references META_OP_MAP which is defined only inside
generateElementAndFilterOptions, causing a ReferenceError; fix by either (A)
defining META_OP_MAP at module scope so processMetaFilters can access it, or (B)
add a parameter (e.g., metaOpMap) to processMetaFilters and pass the existing
META_OP_MAP from generateElementAndFilterOptions (update all callers
accordingly); ensure you update the function signature of processMetaFilters and
every call site (including generateElementAndFilterOptions) or move the constant
above the function definition so the symbol is available at module scope.

---

302-403: ⚠️ Potential issue | 🔴 Critical

Critical: Filter logic still compares against hardcoded English strings, breaking i18n.

The UI now displays translated filter values (e.g., t("environments.surveys.filter.filled_out")), but these helper functions still compare against hardcoded English strings like "Filled out", "Skipped", "Clicked", "Dismissed", "Accepted", "Includes either", "Includes all", "Is equal to", etc.

When a non-English user selects a filter, the translated string will not match these hardcoded comparisons, causing filters to silently fail.

You need a translation strategy that maintains internal identifiers while translating at the UI layer. Consider using stable keys/identifiers for logic and only translating at display time.

Suggested approach: Use stable identifiers for logic

Instead of comparing translated UI strings, use stable operation keys:

-const processFilledOutSkippedFilter = (
-  filterType: FilterValue["filterType"],
-  elementId: string,
-  filters: TResponseFilterCriteria
-) => {
-  if (filterType.filterComboBoxValue === "Filled out") {
-    filters.data![elementId] = { op: "filledOut" };
-  } else if (filterType.filterComboBoxValue === "Skipped") {
-    filters.data![elementId] = { op: "skipped" };
-  }
-};
+// Use a mapping from translated labels to operation keys
+const FILTER_VALUE_TO_OP = {
+  filledOut: "filledOut",
+  skipped: "skipped",
+  // ... etc
+} as const;
+
+// Store the operation key alongside the translated label in filterComboBoxValue
+// or use a separate field for the operation identifier

The filter options should store both the display label (translated) and a stable identifier for logic comparisons.

Based on learnings: "In apps/web/app/lib/surveys/surveys.ts, the conditionOptions and filterOptions objects contain hardcoded user-facing strings... that need to be marked as translatable. These values are used both for UI display in ElementFilterComboBox and for logic comparisons in getFormattedFilters, requiring a translation strategy that maintains internal identifiers while translating at the UI layer."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/app/lib/surveys/surveys.ts` around lines 302 - 403, The helper
functions (processFilledOutSkippedFilter, processRankingFilter,
processMultipleChoiceFilter, processNPSRatingFilter, processCTAFilter,
processConsentFilter) are comparing against hardcoded English labels which
breaks i18n; change the filter option shape so UI displays translated labels but
also carries a stable identifier (e.g., add fields like optionId / valueId /
comboId on conditionOptions/filterOptions and ensure ElementFilterComboBox
passes those ids into getFormattedFilters), then update each helper to switch on
these stable identifiers instead of filterType.filterComboBoxValue or
filterType.filterValue (and still parse ints for NPS/rating when the identifier
expects numeric values). Ensure UI uses the label for display only and logic
uses the stable id for comparisons.

---

405-431: ⚠️ Potential issue | 🔴 Critical

Critical: Picture selection filter parsing breaks with translated labels.

Line 421 parses the picture index using option.split(" ")[1], assuming "Picture N" format. However, the translated label t("environments.surveys.filter.picture_idx", { idx: idx + 1 }) may produce different formats across languages (e.g., "Bild 1" in German, "Image 1" in French), breaking this parsing logic.

Proposed fix: Store index alongside translated label

Store the picture index as data rather than parsing it from the display string:

 case TSurveyElementTypeEnum.PictureSelection:
   return {
     ...baseOption,
-    filterComboBoxOptions: element.choices?.map((_, idx) =>
-      t("environments.surveys.filter.picture_idx", { idx: idx + 1 })
-    ) ?? [""],
+    filterComboBoxOptions: element.choices?.map((choice, idx) => ({
+      label: t("environments.surveys.filter.picture_idx", { idx: idx + 1 }),
+      id: choice.id,
+      index: idx,
+    })) ?? [],
   };

Then update processPictureSelectionFilter to use the stored index/id instead of parsing.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/app/lib/surveys/surveys.ts` around lines 405 - 431,
processPictureSelectionFilter currently parses the choice index from the
translated display string (option.split(" ")[1]) which breaks localization;
instead store the choice index or id when building the combo options (e.g.,
include an explicit value/index field on each filterComboBoxValue entry) and
update processPictureSelectionFilter to read that stored index/id (from
filterType.filterComboBoxValue[*].value or similar) to map to element.choices
(use element?.choices[index]?.id or the stored choice id) so parsing of
translated labels is eliminated. Ensure the code references
processPictureSelectionFilter, filterType.filterComboBoxValue, and
getElementsFromBlocks element.

apps/web/app/lib/surveys/surveys.test.ts (1)

565-584: 🧹 Nitpick | 🔵 Trivial

Note: Tests use English strings matching current (broken) implementation.

The filterComboBoxValue: "Filled out" at line 577 tests against the current implementation where processFilledOutSkippedFilter compares against hardcoded English "Filled out". Once the implementation is fixed to use stable identifiers, these test inputs will need updating.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/app/lib/surveys/surveys.test.ts` around lines 565 - 584, The test is
using the English string "Filled out" which matches the old broken
implementation; update the selectedFilter fixture so
filter.filter[0].filterType.filterComboBoxValue uses the stable identifier the
code now expects (e.g., the enum/value used by processFilledOutSkippedFilter
such as "filledOut" or FilterComboBoxValue.FilledOut) for the openTextQ case so
getFormattedFilters(survey, selectedFilter, ...) produces { op: "filledOut" } as
asserted; adjust the selectedFilter construction in this test (and any similar
tests) to reference that stable identifier rather than the English label.