JQL search on jira_issue table is case sensitive while the JIRA API is not Closes #85

[ParthaI]

Example query results

Results

``` **Before fix:** > select * from jira_issue where status='to Do' limit 10 +----+-----+------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+-----------------------+--------------------+----------------------+-> | id | key | self | project_key | project_id | status | status_category | epic_key | sprint_ids | sprint_names | assignee_account_id | assignee_display_name | creator_account_id | creator_display_name | > +----+-----+------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+-----------------------+--------------------+----------------------+-> +----+-----+------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+-----------------------+--------------------+----------------------+-> **After Fix:** > select * from jira_issue where status='resolved' limit 10 +-------+--------+------------------------------------------------------+-------------+------------+----------+-----------------+----------+------------+--------------+-----------------------------------> | id | key | self | project_key | project_id | status | status_category | epic_key | sprint_ids | sprint_names | assignee_account_id > +-------+--------+------------------------------------------------------+-------------+------------+----------+-----------------+----------+------------+--------------+-----------------------------------> | 10004 | DESK-5 | https://turbi63.atlassian.net/rest/api/2/issue/10004 | DESK | 10001 | resolved | Done | | | | 712020:5dab9f7f-a163-4a8e-86ff-68c> | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > | | | | | | | | | | | > +-------+--------+------------------------------------------------------+-------------+------------+----------+-----------------+----------+------------+--------------+-----------------------------------> > select * from jira_issue where status='to do' limit 10 +-------+-------+------------------------------------------------------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+----------------> | id | key | self | project_key | project_id | status | status_category | epic_key | sprint_ids | sprint_names | assignee_account_id | assignee_displa> +-------+-------+------------------------------------------------------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+----------------> | 10007 | TES-1 | https://turbi63.atlassian.net/rest/api/2/issue/10007 | TES | 10000 | to do | To Do | | | | | > | | | | | | | | | | | | > | | | | | | | | | | | | > | | | | | | | | | | | | > | | | | | | | | | | | | > | | | | | | | | | | | | > | | | | | | | | | | | | > +-------+-------+------------------------------------------------------+-------------+------------+--------+-----------------+----------+------------+--------------+---------------------+----------------> ```

[ParthaI]

The PR is in draft because of we are changing the original API response for the column value status, I don't think which is a good idea, but it should resolve the issue #85.

[cbruno10]

@ParthaI Can you please provide details on how this fixes https://github.com/turbot/steampipe-plugin-jira/issues/85? It's not immediately clear to me by looking at the code.

[ParthaI]

@cbruno10,

In this pull request, we've introduced modifications for the status column behavior. From now on, the data representation will be influenced by a hydrate function.

How the hydrate function operates:

• When the status value is specified in the WHERE clause, the status column value will be populated from the quals.
• In cases where the status value is absent in the WHERE clause during table queries, the status column value will be drawn from the API response.

Rationale for this enhancement:

1. Queries without a WHERE clause: The status column values appear in Upper Camel case.

   
   > select id, status from jira_issue limit 3
   +-------+---------------------+
   | id    | status              |
   +-------+---------------------+
   | 10007 | To Do               |
   | 10005 | Waiting for support |
   | 10006 | Waiting for support |
   +-------+---------------------+

Time: 1.5s. Rows fetched: 3. Hydrate calls: 3.

2. Query with `status` value in Upper Camel case (e.g., 'To Do') within the `WHERE` clause:
It fetches and presents a single row due to the match between the `status` value in the `WHERE` clause and the value from the API response.

select id, status from jira_issue where status = 'To Do' +-------+--------+ | id | status | +-------+--------+ | 10007 | To Do | +-------+--------+

Time: 1.3s. Rows fetched: 1. Hydrate calls: 0.

3. Query with `status` value in Lower Camel case (e.g., 'to Do') within the `WHERE` clause:
Although the API retrieves the details, an empty row is displayed due to Steampipe's filter blocking data display. The discrepancy between the `status` value in the API response (`To Do`) and the `quals` value in the `WHERE` clause (`to Do`) leads to this outcome.

select id, status from jira_issue where status = 'to Do' +----+--------+ | id | status | +----+--------+ +----+--------+

Time: 1.2s. Rows fetched: 1. Hydrate calls: 0.

In the ongoing pull request, I've introduced changes to establish the `status` value from `quals` if present in the `WHERE` clause. Otherwise, the value will align with the one returned from the API response. Consequently, Steampipe's filter will no longer impede data display for any of the scenarios mentioned above.

Thanks!

[github-actions[bot]]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.