Fix: JiraOperator support any return response from Jira client

[Joffreybvn]

Hello,

The JiraOperator fails when using methods that returns any other thing than a dict. This PR fix it by checking whenever a dict is returned.

Example issue

The get_project_issues_count method returns the number of issues in a project, as int.

JiraOperator(
    task_id="example",
	jira_method="get_project_issues_count",
	jira_conn_id="jira",
	jira_method_args={"project": "ABC"},
    dag=dag,
)

However, the current implementation of the JiraOperator expect a dict as response, to perform a get on it.
Thus, the above code will fail, throwing the following:

Traceback (most recent call last):
  File "/opt/app-root/lib64/python3.9/site-packages/airflow/providers/atlassian/jira/operators/jira.py", line 79, in execute
    output = jira_result.get("id", None) if jira_result is not None else None
AttributeError: 'int' object has no attribute 'get'

Solution

Check if it's a dict prior to performing a get on the returned value.

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[hussein-awala]

I wonder if we should just activate the advanced mode to get the raw response from the different methods which is a dict:
https://github.com/atlassian-api/atlassian-python-api/blob/0497b617916274b8aa3677265540b0fd06196663/atlassian/rest_client.py#L214

[Joffreybvn]

I just gave it a try, but that doesn't work: When advanced_mode is set to True, a raw requests.models.Response get returned, which doesn't has any get method:

Traceback (most recent call last):
  File "/opt/app-root/lib64/python3.9/site-packages/airflow/providers/atlassian/jira/operators/jira.py", line 79, in execute
    output = jira_result.get("id", None) if jira_result is not None else None
AttributeError: 'Response' object has no attribute 'get'

See the rest api methods like post, get, put, ... of the AtlassianRestAPI object: without advanced mode, we get a dict via the _response_handler method. With advanced mode, the raw Response object is returned. And many methods in the Jira object (e.g. issues_get_comments_by_id) will simply return that Response object.

---

Looking further in the Jira client, they are some methods that just return something else than a dict:

• int get_transition_id_to_status_name
• iterable project_leaders
• list get_all_screen_fields
  (haven't checked every method)

---

And actually, are those lines (79-80) even needed ?
The test mock for the jql_get_list_of_tickets method returns a dict with an id key (see minimal_test_ticket). But this method is supposed to return a list. The only valid test case is the one testing issue_add_comment, where there is a ticket id returned.
-> I have the feeling that the 'id' key exist in very few cases.

I suggest to merge this PR, so that the JiraOperator is usable. I'll continue to explore the Jira API, and will later create other PR with correct tests case. And maybe at that point we can discuss a better xcom.push ? What do you think ?

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.