Problem
DependsOnEvaluator (lib/src/utils/depends_on_evaluator.dart) has two related parsing gaps that cause depends_on / link_filters expressions authored on the Frappe web side to silently fail on mobile.
1. Trailing semicolon breaks value comparison
Some depends_on expressions are authored with a trailing statement terminator, e.g.:
eval:doc.some_checkbox == 1;
_extractValue only matches bare numeric/string literals. The trailing ; survives into the comparison value, so the numeric-literal regex never matches and the expression falls through to a string comparison that never succeeds — the dependent field is permanently hidden regardless of the checkbox's actual state.
2. doc.field reference inside a wrapped JS expression isn't recognized
extractEvalDocField is used for dependent-field detection (the "select X first" UX on Link fields with link_filters). It only matches a bare eval:doc.field value. Real-world link_filters frequently wrap the reference in a JS expression, e.g.:
eval:(doc.category||'').replace(/^prefix\s*/, '')
extractEvalDocField returns null for this — the dependent-field gate never kicks in, and the Link field just resolves zero options with no indication of why, instead of prompting the user to fill in the dependency first.
Expected behaviour
_extractValue should strip a trailing ; before attempting numeric/string literal parsing.
extractEvalDocField should fall back to a regex search for the first doc.<field> reference anywhere in the expression when the whole expression isn't a bare doc.field value.
Suggested fix
Both fixes are small, additive, and don't change existing passing behavior — see attached PR.
Problem
DependsOnEvaluator(lib/src/utils/depends_on_evaluator.dart) has two related parsing gaps that causedepends_on/link_filtersexpressions authored on the Frappe web side to silently fail on mobile.1. Trailing semicolon breaks value comparison
Some
depends_onexpressions are authored with a trailing statement terminator, e.g.:_extractValueonly matches bare numeric/string literals. The trailing;survives into the comparison value, so the numeric-literal regex never matches and the expression falls through to a string comparison that never succeeds — the dependent field is permanently hidden regardless of the checkbox's actual state.2.
doc.fieldreference inside a wrapped JS expression isn't recognizedextractEvalDocFieldis used for dependent-field detection (the "select X first" UX on Link fields withlink_filters). It only matches a bareeval:doc.fieldvalue. Real-worldlink_filtersfrequently wrap the reference in a JS expression, e.g.:extractEvalDocFieldreturnsnullfor this — the dependent-field gate never kicks in, and the Link field just resolves zero options with no indication of why, instead of prompting the user to fill in the dependency first.Expected behaviour
_extractValueshould strip a trailing;before attempting numeric/string literal parsing.extractEvalDocFieldshould fall back to a regex search for the firstdoc.<field>reference anywhere in the expression when the whole expression isn't a baredoc.fieldvalue.Suggested fix
Both fixes are small, additive, and don't change existing passing behavior — see attached PR.