feat(jira): extract valuable field-options optimizations from #945 on top of #944

[pibylick]

Summary

This PR takes the valuable parts called out in #945 and adds them on top of the already-merged #944 jira_get_field_options path, without reintroducing duplicate tool/model implementations.

What was added above #944 functionality

• contains parameter for case-insensitive server-side filtering
• return_limit parameter to cap returned options after filtering
• values_only mode to return only option values for smaller payloads
• Compact JSON serialization for lighter MCP responses

Important compatibility note

• Default response shape remains backward-compatible with feat(jira): add custom field options discovery for select fields #944 (list of option objects).
• New behavior is opt-in via the added parameters.

Tests

• Added server tests for:
  • default response shape
  • contains filtering
  • return_limit limiting
  • values_only output
• Ran field-options unit tests and pre-commit checks on changed files.

[sooperset]

Good extraction from #945. The opt-in parameter approach is the right call over duplicate tools. Two things to consider.

[sooperset]

This changes the default output from json.dumps(result, indent=2) to compact JSON, even when no new parameters are used. Every other tool in the file uses indent=2. Since the PR description says "Default response shape remains backward-compatible with #944", was this change intentional? Consider keeping indent=2 for the non-values_only path.

[sooperset]

(question) For cascading select fields, to_simplified_dict() emits child_options. This function only reads the top-level value, so values_only mode would return ["US"] and silently drop child values like "California". Same applies to the contains filter. Worth either handling recursion or documenting this limitation in the parameter descriptions.

[pibylick]

Comment 1 (line 549) - Fixed: Restored for backward compatibility with #944 when not in values_only mode.

Comment 2 (line 56) - Fixed: Added recursive handling for cascading select fields in values_only mode. Now preserves parent-child structure as {"value": "parent", "children": ["child1", "child2"]}. Added test coverage for this behavior in test_get_field_options_values_only_cascading.

[sooperset]

Nice opt-in approach — the filtering parameters are well-designed and backward compatibility is preserved.

One open item from the earlier review thread: the contains filter still only matches parent-level value, so searching for a child option value on cascading select fields (e.g., contains="California" when parent is "US") returns no results. The values_only recursion was addressed but this part wasn't. Could either extend _apply_option_filters to also match against child_options values, or document the limitation in the contains parameter description.

Also, ruff-format fails on the test file — missing blank line after the docstring in test_get_field_options_values_only_cascading (line 637). Pre-commit auto-fixes it, just needs a commit.

[sooperset]

Follow-up on the earlier cascading select thread: values_only recursion was fixed, but contains still only checks the parent option.get("value"). A search like contains="California" on a cascading field with parent "US" returns nothing.

Consider matching against child values too:

def _matches_contains(option: dict[str, Any], needle: str) -> bool:
    if needle in str(option.get("value", "")).casefold():
        return True
    for child in option.get("child_options", []):
        if isinstance(child, dict) and needle in str(child.get("value", "")).casefold():
            return True
    return False

Alternatively, documenting that contains only filters top-level values would also be fine.

[pibylick]

in my opinion ready to be merged

[sooperset]

Thanks for addressing all the earlier feedback — backward-compat indentation, cascading select recursion in values_only, and child-value matching in contains all look good now.

One issue from the merge: test_get_project_components_tool (from #873) and test_update_issue_accepts_json_string_fields (from #973) were dropped during the conflict resolution in d1a8249 — they're unrelated regression tests that need to be restored before this can merge.

[sooperset]

(minor) values_only is bool | None with default=None, but the code treats None and False identically (if values_only:). Every other boolean param in this file uses bool with a concrete default — bool = False would be simpler here.

[sooperset]

Thank you for the contribution, @pibylick! This has been reimplemented in #1074 with updated tests and project conventions. Your work is credited via Co-authored-by trailer.