Repository navigation
Round 3 follow-up: further split _search_term_filters() in users/admin.py - #559
Merged
Merged
Conversation
…n.py My earlier extraction in #546 (merged) moved get_search_results()'s complexity into a new _search_term_filters() module function, but that function itself was re-flagged by Sonar at complexity 17 (even higher than the original 16) once re-analyzed on stage-eks. Split it further into _search_separator_and_operator(), _build_search_filters(), and _any_lookup_needs_distinct(), plus an early return when search_fields/ search_term are empty (matching the original's effective behavior, since the old guard conditions were equivalent to a no-op in that case). No behavior change: verified the early-return path returns the exact same (empty filters, False, operator.and_) that the original's untouched initial values would have produced when the outer `if search_fields and search_term:` was false.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #450 (round 3).
Sonar issue: python:S3776,
users/admin.py:41, complexity 17.My earlier extraction in thunderbird/addons-server#546 (merged) moved
get_search_results()'s complexity into a new_search_term_filters()module function, but that function itself got re-flagged by Sonar at complexity 17 (higher than the original 16!) once re-analyzed onstage-eksafter merge. Caught this by re-pulling OPEN issues forusers/before starting other work there, per the round-3 brief's "re-pull before each file" rule.Split it further into
_search_separator_and_operator(),_build_search_filters(), and_any_lookup_needs_distinct(), plus an early return whensearch_fields/search_termare empty (matching the original's effective behavior, since the old guard conditions were equivalent to a no-op in that case -use_distinct/filters/joining_operatorwere never mutated from their initial values when that branch wasn't taken).No behavior change: verified the early-return path returns the exact same
([], False, operator.and_)that the original's untouched initial values would have produced.Also confirmed via re-pull that
users/backends.py(2xS1172kw, 1xS1172request) andusers/models.py/users/widgets.pyfindings are already-documented exclusions from earlier rounds, not touched here.Local Greptile review: org free-tier quota exhausted, skipped per coordinator guidance; the Greptile GitHub check on this PR still runs independently.