Regex check across two lines

[chrislee115]

I'm trying to write a regex check for content validation - #4944
I can't seem to match a string across two lines (I've tried using .*\s\f\v\t\n) Does anyone know what might be the issue?

I've created a new test, and I've tried something as simple as "meta-data\s*android" but can't seem to properly match this string

[MohitGupta121]

@chrislee115 As tried using the regular expression .* for the new line is working for me or I am getting something wrong?
Thanks.

[BenHenning]

This is a known limitation in the validation check logic. See:

oppia-android/scripts/src/java/org/oppia/android/scripts/regex/RegexPatternValidationCheck.kt

Lines 243 to 254 in bf47f91

	/**
	* Returns the list of line indexes which contain prohibited content per this check (given an
	* iterable of lines). Note that the returned indexes are based on the iteration order of the
	* provided iterable.
	*/
	fun computeAffectedLines(lines: Iterable<String>): List<Int> {
	if (prohibitedContentRegex != null)
	return lines.withIndex().filter { (_, line) ->
	prohibitedContentRegex.containsMatchIn(line)
	}.map { (index, _) -> index }
	else return emptyList()
	}

It's thought that more complex checks (such as those that would require newlines) would probably be a bit too fragile to introduce as regex and probably would better fit a more lexically-correct check (like we do for some formatting validation such as KDocs or XML).

For #4944 if your concern is the format changing to include newlines then perhaps you could add a check that requires the full disable line to exist somewhere in the file, otherwise it fails. This forces the format of a single-line directive, and also has the benefit of providing the logical result of ensuring the corresponding analytics property is kept disabled. For example, we could verify that the following must be present:

    <meta-data android:name="automatic_app_expiration_enabled" android:value="false" />

That being said, I think Android's code reformatter will automatically re-format this, so people may occasionally get a false positive check on the proposed pattern and would need to manually revert the line. That's not a huge issue, but it is slightly annoying.

A more robust check would probably require introducing a new script that properly parses the XML and verifies it. That's a bit overkill for what amounts to a medium-term check, so I think perhaps going with the formatting-based approach above would be the most reasonable solution.

[MohitGupta121]

Hey @chrislee115 if your query is resolved then please mark this discussion is resolved (marking as answered that comment) so that it's helpful to others in the community. And if you need help then also feel free to ask.
Thanks!

[chrislee115]

Done! Sorry for the delay