Support Single Select field mapping for storypoints

[istein1]

Problem

When using GitHub Project Single Select fields with numeric option mappings for storypoints, sync2jira fails with:

Error while processing storypoints for issue: 'number'

This occurs because the code only supports Number-type fields and tries to read item["number"], which doesn't exist for Single Select fields.

Configuration Example

github_project_fields={
    'storypoints': {
        'gh_field': 'Size',
        'options': {
            '🐇 Small': 5,
            '🐂 Medium': 8,
            '🦑 Large': 23,
        }
    }
}

Solution

This PR adds support for Single Select fields with numeric mappings by:

1. Checking if the storypoints config has an options mapping
2. For Single Select fields: reading item["name"] and mapping it via the options dict
3. For Number fields: reading item["number"] directly (preserves existing behavior)
4. Ensuring the final value is always cast to int for Jira compatibility

Testing

• Tested with migtools/crane repository using GitHub org-level project Fix issue when GitHub pull-request closes an issue #24
• Single Select "Size" field with emoji options now correctly maps to numeric storypoints in Jira
• Existing Number-field configurations continue to work (backward compatible)

Related

This enables configurations like those already used in other projects (packit, cpt, tmt, etc.) but with more flexible field types.

[qodo-code-review]

Review Summary by Qodo

Support Single Select field mapping for storypoints

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Add support for Single Select GitHub Project fields with numeric option mappings for storypoints
• Check for options mapping to distinguish between Single Select and Number field types
• For Single Select fields, read item name and map via options dictionary
• Preserve backward compatibility with existing Number-type field configurations

Diagram

flowchart LR
  A["Storypoints Config"] --> B{"Has options mapping?"}
  B -->|Yes| C["Single Select Field"]
  B -->|No| D["Number Field"]
  C --> E["Read item name"]
  D --> F["Read item number"]
  E --> G["Map via options dict"]
  F --> H["Use directly"]
  G --> I["Cast to int"]
  H --> I
  I --> J["Set issue storypoints"]

Loading

File Changes

1. sync2jira/upstream_issue.py 🐞 Bug fix +10/-1

Add Single Select field support for storypoints mapping

• Enhanced storypoints field processing to support both Single Select and Number field types
• Added conditional logic to check for options mapping in storypoints configuration
• For Single Select fields, reads item name and maps it through the options dictionary
• For Number fields, maintains existing behavior of reading item number directly
• Ensures final value is cast to int for Jira compatibility

sync2jira/upstream_issue.py

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (0)   📎 Requirement gaps (0)

🐞\ ⚙ Maintainability (1)

1. TypeError escapes storypoints try ☑ 🐞 ☼

Description

The new int(sp_options[sp_value]) conversion can raise TypeError (e.g., mapped value is
None/non-numeric type), but the handler only catches ValueError and KeyError, so a misconfigured
mapping can crash the sync while processing project fields.

Code

sync2jira/upstream_issue.py[R295-305]

+                # Check if there's an options mapping (for Single Select fields)
+                sp_options = github_project_fields.get("storypoints", {}).get("options")
+                if sp_options:
+                    # Single Select field - get name and map it
+                    sp_value = item.get("name")
+                    if sp_value and sp_value in sp_options:
+                        issue["storypoints"] = int(sp_options[sp_value])
+                else:
+                    # Number field - get number directly
+                    issue["storypoints"] = int(item["number"])
        except (ValueError, KeyError) as err:

Evidence

The storypoints parsing is inside a try/except that only catches (ValueError, KeyError). Any
TypeError raised by int(...) (e.g., int(None)) will propagate out of add_project_values and can
abort processing.

sync2jira/upstream_issue.py[292-313]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`add_project_values()` converts storypoints via `int(...)` but only catches `(ValueError, KeyError)`. If the configured mapping value is `None` (or another non-int-coercible type), `int(...)` raises `TypeError`, which is currently unhandled and can crash the run.
### Issue Context
This risk exists specifically in the new Single Select mapping path `int(sp_options[sp_value])`.
### Fix Focus Areas
- sync2jira/upstream_issue.py[295-305]
### Suggested change
- Extend the exception handler to include `TypeError`:
- `except (ValueError, TypeError, KeyError) as err:`
- Consider defensive validation before conversion:
- ensure `sp_options` is a `dict`
- ensure `sp_options[sp_value]` is not `None`
- log a clear message when conversion fails (include `sp_value` and the mapped value).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unmapped storypoints silently skipped ☑ 🐞 ◔

Description

In add_project_values, if storypoints is configured with an options mapping but the GitHub Single
Select option name is missing/unmapped, issue["storypoints"] remains None with no log, so downstream
Jira story points never update and the misconfiguration is hard to diagnose.

Code

sync2jira/upstream_issue.py[R296-302]

+                sp_options = github_project_fields.get("storypoints", {}).get("options")
+                if sp_options:
+                    # Single Select field - get name and map it
+                    sp_value = item.get("name")
+                    if sp_value and sp_value in sp_options:
+                        issue["storypoints"] = int(sp_options[sp_value])
+                else:

Evidence

When github_project_fields is enabled, storypoints is initialized to None and only assigned inside
the if sp_value in sp_options branch; otherwise it stays None without any log. Downstream Jira
updates for storypoints are skipped unless the value is an int, so this becomes a silent no-op.

sync2jira/upstream_issue.py[233-314]
sync2jira/downstream_issue.py[1194-1237]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When `github_project_fields.storypoints.options` is present, an unmapped Single Select option leaves `issue["storypoints"]` unset (None) without any log, causing Jira storypoints to not update with no diagnostics.
### Issue Context
`add_project_values()` sets `issue["storypoints"] = None` up-front and only assigns a value if `sp_value in sp_options`. Downstream updates only occur when storypoints is an `int`.
### Fix Focus Areas
- sync2jira/upstream_issue.py[295-305]
### Suggested change
- Add an explicit `else` path under the `if sp_options:` branch to log (ideally `warning` or `info`) when:
- `sp_value` is missing/empty, or
- `sp_value` is not found in `sp_options`
- Include the observed `sp_value` and configured keys (or count of keys) to aid debugging.
- Optionally, consider a safe fallback (e.g., if `sp_value` looks numeric, attempt `int(sp_value)`), but only if that matches intended behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. No single-select storypoints test 🐞 ⚙

Description

There is test coverage for number-based storypoints and Single Select priority mapping, but no unit
test covers the new storypoints Single Select options mapping path, increasing regression risk for
this new feature.

Code

sync2jira/upstream_issue.py[R295-304]

+                # Check if there's an options mapping (for Single Select fields)
+                sp_options = github_project_fields.get("storypoints", {}).get("options")
+                if sp_options:
+                    # Single Select field - get name and map it
+                    sp_value = item.get("name")
+                    if sp_value and sp_value in sp_options:
+                        issue["storypoints"] = int(sp_options[sp_value])
+                else:
+                    # Number field - get number directly
+                    issue["storypoints"] = int(item["number"])

Evidence

Existing tests exercise storypoints via a Number project field (number: 2.0) and priority via
Single Select (name: 'P1'). No test sets storypoints to a Single Select value (name) plus an
options mapping, so the new branch is untested.

tests/test_upstream_issue.py[149-252]
tests/test_upstream_issue.py[254-325]
sync2jira/upstream_issue.py[292-305]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new storypoints Single Select mapping logic is not covered by tests, making regressions likely.
### Issue Context
Current tests cover:
- storypoints from `number` fieldValues node
- priority from `name` (Single Select) fieldValues node
### Fix Focus Areas
- tests/test_upstream_issue.py[149-340]
### Suggested change
Add a new unit test similar to `test_github_issues_with_storypoints`, but:
- configure `github_project_fields = {"storypoints": {"gh_field": "Size", "options": {"🐇 Small": 5}}}`
- mock GraphQL response with a `ProjectV2ItemFieldSingleSelectValue` node:
- `{"fieldName": {"name": "Size"}, "name": "🐇 Small"}`
- assert the intermediary Issue created via `Issue.from_github` receives `storypoints == 5`
Optionally add a second assertion case for an unmapped value to verify the new logging/behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[istein1]

@webbnh , Tests are now added.

[istein1]

Thanks @webbnh for the extensive review !!
Added tests and a fix for the last comment.

[webbnh]

/ok-to-test

[webbnh]

Oh, so close! The code looks fine to me, now, but Black objects to the formatting. (And, annoyingly, that prevented us from seeing whether the coverage passed the mark.) Let me know if you don't know how to fix this.

I believe the two Konflux policy checks are our problem, not yours. I just merged a Konflux update PR, which I'm hoping will address those, but, you'll need to rebase this branch, and then hopefully the tests will pass.

[webbnh]

/ok-to-test

[webbnh]

It's really frustrating not being able to see the annotated source code coverage, but Coveralls has some sort of chronic infrastructure problem that they haven't been able to trace.

In any case, Coveralls is convinced that the coverage of the new code added in this PR is still wanting:

5 of 16 new or added lines in 1 file covered. (31.25%)

I just pulled your branch and ran the coverage analysis locally and it really doesn't look good:

So, now, we need to figure out what Claude's tests are actually doing.... 😞

A quick run through the first test scenario under the debugger points to the (first) obvious problem: the test code is not setting mock_requests_post.return_value.status_code = 200, so the CUT decides that the request has failed and returns early, without doing anything which we would notice as a failure.

So, this is a little tricky to test: we're trying to make sure that certain things don't happen, while assuming that everything else does. What I think we should do is set up the context so that it will set the priority value and then make sure that it doesn't set the story point value: if it sets the story point value (or dies trying), then the test failed; if it doesn't set the priority value, then the test failed, as well.

I think that's probably a workable approach, but I have to quit for the day.