Fixed search string = operator returning an array instead of a string#3373
Open
TowyTowy wants to merge 1 commit into
akaunting:masterakaunting/akaunting:masterfrom
TowyTowy:fix/search-string-equals-operatorTowyTowy/akaunting:fix/search-string-equals-operatorCopy head branch name to clipboard
Open
Fixed search string = operator returning an array instead of a string#3373TowyTowy wants to merge 1 commit intoakaunting:masterakaunting/akaunting:masterfrom TowyTowy:fix/search-string-equals-operatorTowyTowy/akaunting:fix/search-string-equals-operatorCopy head branch name to clipboard
TowyTowy wants to merge 1 commit into
akaunting:masterakaunting/akaunting:masterfrom
TowyTowy:fix/search-string-equals-operatorTowyTowy/akaunting:fix/search-string-equals-operatorCopy head branch name to clipboard
Conversation
getSearchStringValue() documents that both : and = are single-value
(exact match) operators and should return a string, while > < >= <=
are range operators that accumulate into an array. The early return
only checked for : (str_contains($column, ':')), so a = filter such
as type=customer or account_id=5 fell through to the range branch and
was returned as a one-element array.
This breaks callers that expect a string, e.g. explode(',', $this->
getSearchStringValue('account_id')) in Abstracts/Listeners/Report.php
throws a TypeError (HTTP 500) when a report is filtered with account_id=5.
Detect the operator right after the column name so a leading = is
matched while the = inside >= / <= is not, restoring the documented
single-value behaviour for = without affecting range operators.
Co-Authored-By: Claude <noreply@anthropic.com>
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.
getSearchStringValue()documents that both:and=are single-value (exact-match) operators returning a string, while><>=<=are range operators that accumulate into an array. The early return only checked for:, so a=filter (e.g.type=customer,account_id=5) fell through and was returned as a one-element array.This breaks callers expecting a string — e.g.
explode(',', $this->getSearchStringValue('account_id'))inapp/Abstracts/Listeners/Report.phpthrows aTypeError(HTTP 500) when a report is filtered withaccount_id=5.Fix: detect the operator immediately after the column name so a leading
=is matched while the=inside>=/<=is not, restoring the documented single-value behaviour for=without affecting range operators.Verified on PHP 8.5 with a harness exercising the real trait:
type=customerandaccount_id=5now return strings (previously arrays), the reportexplode()path no longer crashes, and>/</>=/<=ranges still return arrays.AI-assisted fix, reviewed and tested before submitting.