MD.OFFICE
FAL

Daily Log: 2026-02-25

Formula-Based Conditional Validation Implementation Plan

  • Completely researched and designed the Formula-Based Conditional Validation architecture. Confirmed that validation rules should leverage the actual backend APIs (/validate at design time, /evaluate at runtime) using raw mathematical expressions rather than GUI-based logical condition tree structures.
  • Documented a robust 3-Phase Implementation Plan:
    • Phase 1: Enhance the application data model (BaseFieldConfig.validationRules) and integrate the FormulaBuilderComponent into the "Error Tab" configuration inside the form builder UI.
    • Phase 2: Add runtime support inside FormEngineService by implementing an async validator factory and dependency value tracking across reactive form controls.
    • Phase 3: Ensure that field label renames seamlessly propagate into validation rule formulas within the same form via updateAllFormulas().

FormulaBuilderComponent Logic Upgrades

  • Overlapping RegExp Bug Fix: Addressed a critical bug where formula field labels ending in parentheses (e.g., @Total Compensation (Legacy)) were ignored during transformation to JSON keys because of an overly strict \b word boundary check. Also resolved edge cases surrounding overlapping label substrings (e.g., @Base Salary vs @Base) by redesigning string replacements to evaluate array lengths in descending order, ensuring accurate value swapping.

Testing & Quality Assurance

  • Drafted a full test suite of manual UI steps involving single evaluations and library-based conditional fallbacks.

Phase 1 Completions: Data Model & Builder UI

  • Data Model: Introduced the ValidationRule interface and added validationRules to BaseFieldConfig.
  • Boolean Enforcement: Added a mode: 'calculation' | 'validation' input to FormulaBuilderComponent. In 'validation' mode, the component enforces that the formula contains a mathematical comparison operator (e.g., ==, >, <=) before attempting to validate against the backend API, correctly rejecting purely arithmetic paths.
  • Rule Builder UI (Error Tab):
    • Overhauled the ErrorI18nParentComponent to support full CRUD operations for validation rules.
    • Implemented an accordion-style interface for each validation rule to keep the UI clean even when multiple complex formulas are present.
    • Aligned the formula error display metadata with the existing standard error configurations (e.g., required, min).
    • Auto-generation of displayKey dynamically handles prefixing based on the element type and JSON key (df.error.[jsonKey].[errorKey]) for cleaner translation maps.