Uh oh!
There was an error while loading. Please reload this page.
fix: preserve '=' inside --filter values - #442
Open
jacalata wants to merge 5 commits into
Open
Conversation
Previously `apply_filter_value` called `value.split("=")`, so a filter
like `Notes=x=y` silently truncated to name=Notes, value=x. Split on the
first '=' only (maxsplit=1) so multi-'=' values round-trip intact, and
raise a clear error when the input isn't in name=value form.
Verified end-to-end against a real workbook: `Product Name=x=y Config Kit`
now filters correctly instead of returning empty results.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>3 tasks
Dataset with product names containing '=', '&', ',', backslashes, and metacharacter samples for exercising --filter parsing edge cases against a real server. Also includes columns whose names contain '&', '#', and '\' so future tests can exercise special characters on both sides of the name=value pair. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…rity)
The earlier tightening in this PR made apply_filter_value raise a clean
error when a clause isn't in name=value form. That's the right behavior
for the --filter flag, but URL-syntax exports inherited from tabcmd
Classic scripts often contain literal '&' inside filter values (e.g.
`?Product Name=AT&T 841000 Phone`), which get split into fragments the
parser can't understand.
Classic silently skipped such fragments. Verified end-to-end against a
Tableau Server today: with the strict path, tabcmd 2 errored out
("Filter clause 'T 841000 Phone' must be in name=value form") where
Classic silently continued and let the server return whatever the well-
formed portion matched.
Add strict: bool = True to apply_filter_value. --filter callers stay
strict; apply_encoded_filter_value (the URL path) passes strict=False,
which logs a WARNING and skips the fragment instead of exiting.
Adds three tests: strict path still exits, non-strict path skips
silently, and end-to-end apply_values_from_url_params tolerates a value
with '&'.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds more robust parsing for filter clauses (especially when values contain = or URL fragments are malformed) and expands test coverage and fixtures for these edge cases.
Changes:
- Update filter parsing to split on the first
=only and supportstrictvs non-strict behavior. - Make URL-embedded filter parsing non-strict to match tabcmd Classic’s “skip invalid fragments” behavior.
- Add tests (and a CSV fixture) covering
=in values, empty values, and&-split URL fragments.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/commands/test_datasources_and_workbooks_command.py | Adds regression tests for = inside filter values and non-strict URL fragment handling. |
| tests/assets/filter_test_data.csv | Adds fixture data with special characters used in filter parsing scenarios. |
| tabcmd/commands/datasources_and_workbooks/datasources_and_workbooks_command.py | Updates filter parsing logic and introduces strict mode to control behavior for malformed clauses. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # fragment. Match tabcmd Classic's silent-skip behavior so drop-in | ||
| # migration of scripts that contain literal '&' in filter values | ||
| # (which the parser splits on) doesn't hard-fail. | ||
| logger.warning("Skipping unparseable filter clause from URL: %r", value) |
Black 22 (pinned in pyproject.toml) reformats these two files; the CI 'Check formatting with black' step was failing.
The prior fix for `?Product Name=AT&T 841000 Phone` matched Classic by
skipping the "T 841000 Phone" fragment, but it also applied the truncated
first fragment (`Product Name=AT`) as a real filter. On any dataset with
a matching "AT" row that produces silent wrong data with only a WARNING
log the user might miss.
Detect the pattern: if a fragment after '&' has no '=' and isn't a
tabcmd options key (":..."), assume it's a continuation of the previous
value and rejoin. Warns loudly that the URL should encode '&' as '%26'
so the ambiguity is visible.
Tests cover the AT&T case, multiple '&' in a value, options mixed with
filters, and multiple legitimate filters.
Co-Authored-By: Claude Opus 4.7 (1M context) <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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Two related client-side filter-parser fixes, plus test data.
=inside a filter value was silently truncated.apply_filter_valuesplit on every=, so--filter "Notes=x=y"became name=Notes, value=x. Values that legitimately contain=(config strings, formulas, part numbers, etc.) got dropped. Fix:split("=", maxsplit=1)and raise a clear error when the input isn't inname=valueform.&inside a URL-syntax filter value used to hard-error under the strict path introduced above.tabcmd export "view?Product Name=AT&T 841000 Phone"— a tabcmd Classic script pattern — got split on&into a bogusT 841000 Phonefragment, which the new strictapply_filter_valuerefused. Classic silently skipped such fragments; verified end-to-end against a live server that this is a real regression on drop-in Classic script migration. Fix:apply_filter_valuenow takesstrict: bool = True.--filtercallers keep strict validation; the URL-syntax code path (apply_encoded_filter_value) passesstrict=False, which logs a WARNING and skips the fragment.Test fixture —
tests/assets/filter_test_data.csvwith product names, columns and values containing=,&,,, backslashes, and various metacharacters, for e2e filter-parsing tests.Verification
Against a live Tableau Server workbook (Product Name column,
escapeyvalues/Sheet1):Product Name=Widget Plain(baseline)Product Name=x=y Config Kit(=in value)Product Name=AT&T 841000 Phone(&in value, URL syntax)Product Name=x=y Config Kit(via--filter)Test plan
pytest tests/commands/test_datasources_and_workbooks_command.py— 31 passedpytest tests/ --ignore=tests/e2e— 343 passed, 2 skippedtabcmd export --csv --filter "Product Name=x=y Config Kit"returns the expected rowtabcmd export "escapeyvalues/Sheet1?Product Name=AT&T 841000 Phone"(Classic URL syntax) no longer errors; matches Classic's silent-skip behavior🤖 Generated with Claude Code