Giter Site home page Giter Site logo

turbot / steampipe-plugin-jira Goto Github PK

View Code? Open in Web Editor NEW
21.0 9.0 12.0 453 KB

Use SQL to instantly query Jira. Open source CLI. No DB required.

Home Page: https://hub.steampipe.io/plugins/turbot/jira

License: Apache License 2.0

Makefile 0.10% PLSQL 0.80% Go 99.10%
sql postgresql steampipe steampipe-plugin postgresql-fdw jira atlassian-jira hacktoberfest backup etl

steampipe-plugin-jira's Introduction

image

Jira Plugin for Steampipe

Use SQL to query infrastructure including servers, networks, facilities and more from Jira.

Quick start

Install

Download and install the latest Jira plugin:

steampipe plugin install jira

Configure your credentials and config file.

Configure your account details in ~/.steampipe/config/jira.spc:

connection "jira" {
  plugin = jira

  # Authentication information
  base_url              = "https://your-domain.atlassian.net/"
  username              = "[email protected]"
  token                 = "8WqcdT0rvIZpCjtDqReF48B1"
}

For self-hosted Jira instances, please use the personal_access_token field instead of token. This access token can only be used to query jira_backlog_issue, jira_board, jira_issue and jira_sprint tables.

connection "jira" {
  plugin = jira

  # Authentication information
  base_url              = "https://your-domain.atlassian.net/"
  personal_access_token = "MDU0MDMx7cE25TQ3OujDfy/vkv/eeSXXoh/zXY1ex9cp"
}

Or through environment variables:

export JIRA_URL=https://your-domain.atlassian.net/
export [email protected]
export JIRA_TOKEN=8WqcdT0rvIZpCjtDqReF48B1
export JIRA_PERSONAL_ACCESS_TOKEN="MDU0MDMx7cE25TQ3OujDfy/vkv/eeSXXoh/zXY1ex9cp"

Run steampipe:

steampipe query

List users in your Jira account:

select
  display_name,
  account_type as type,
  active as status,
  account_id
from
  jira_user;
+-------------------------------+-----------+--------+-----------------------------+
| display_name                  | type      | status | account_id                  |
+-------------------------------+-----------+--------+-----------------------------+
| Confluence Analytics (System) | app       | true   | 557058:cbc04d7be567aa5332c6 |
| John Smyth                    | atlassian | true   | 1f2e1d34e0e56a001ea44fc1    |
+-------------------------------+-----------+--------+-----------------------------+

Engines

This plugin is available for the following engines:

Engine Description
Steampipe The Steampipe CLI exposes APIs and services as a high-performance relational database, giving you the ability to write SQL-based queries to explore dynamic data. Mods extend Steampipe's capabilities with dashboards, reports, and controls built with simple HCL. The Steampipe CLI is a turnkey solution that includes its own Postgres database, plugin management, and mod support.
Postgres FDW Steampipe Postgres FDWs are native Postgres Foreign Data Wrappers that translate APIs to foreign tables. Unlike Steampipe CLI, which ships with its own Postgres server instance, the Steampipe Postgres FDWs can be installed in any supported Postgres database version.
SQLite Extension Steampipe SQLite Extensions provide SQLite virtual tables that translate your queries into API calls, transparently fetching information from your API or service as you request it.
Export Steampipe Plugin Exporters provide a flexible mechanism for exporting information from cloud services and APIs. Each exporter is a stand-alone binary that allows you to extract data using Steampipe plugins without a database.
Turbot Pipes Turbot Pipes is the only intelligence, automation & security platform built specifically for DevOps. Pipes provide hosted Steampipe database instances, shared dashboards, snapshots, and more.

Developing

Prerequisites:

Clone:

git clone https://github.com/turbot/steampipe-plugin-jira.git
cd steampipe-plugin-jira

Build, which automatically installs the new version to your ~/.steampipe/plugins directory:

make

Configure the plugin:

cp config/* ~/.steampipe/config
vi ~/.steampipe/config/jira.spc

Try it!

steampipe query
> .inspect jira

Further reading:

Open Source & Contributing

This repository is published under the Apache 2.0 (source code) and CC BY-NC-ND (docs) licenses. Please see our code of conduct. We look forward to collaborating with you!

Steampipe is a product produced from this open source software, exclusively by Turbot HQ, Inc. It is distributed under our commercial terms. Others are allowed to make their own distribution of the software, but cannot use any of the Turbot trademarks, cloud services, etc. You can learn more in our Open Source FAQ.

Get Involved

Join #steampipe on Slack →

Want to help but don't know where to start? Pick up one of the help wanted issues:

steampipe-plugin-jira's People

Contributors

adrfrank avatar cbruno10 avatar dependabot[bot] avatar gabrielsoltz avatar johnsmyth avatar juandspy avatar karanpopat avatar lalitlab avatar madhushreeray30 avatar misraved avatar parthai avatar rajlearner17 avatar s-spindler avatar sayan133 avatar subhajit97 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

steampipe-plugin-jira's Issues

user_table not returning all results

Describe the bug

select * from jira_user doesn't display all records and returns an inconsistent number of records every time it is run (even without clearing the cache)

Additional information

  • There is no error so you'd think everything worked properly
  • select count(*) from jira.jira_user does display the correct number of users
  • Adding order by causes a 429 error every time. Example:
    select * from jira.jira_user order by display_name
    Error: table 'jira_user' column 'group_names' requires hydrate data from getUserGroups, which failed with error 429 Too Many Requests: local_rate_limited: request failed. Please analyze the request body for more details. Status code: 429.
  • Reducing MaxConcurrency seems to fix the issue. I reduced it from 50 to 5 and consistently get all records.
  • Running against a Jira cloud instance with a few hundred users

Steampipe version (steampipe -v)
Example: v0.16.4

Plugin version (steampipe plugin list)
Example: v0.6.1

Inconsistent Behavior When Querying by Epic Key

Describe the bug
If I attempt to execute a query against "jira_issue" using the "epic_key" in my "where clause" it does not yield any results. However, if I first query against jira_issue using "key" and then try by "epic_key" it works as expected.

Caveat: I am using a forked plugin, because I am going against an enterprise installation and needed to change the api endpoint path to version "rest/api/2/" and not "rest/api/3/". I assume this works against Jira cloud but scratching my head as to why I need to issue a preemptive query to get it working as expected. I realize this is not the version that was tested on for the original plugin, and perhaps that's my tough luck, but just trying to understand the behavior, because the API is still very similar and works in many cases OOTB.

Steampipe version (steampipe -v)
Example: v0.16.4

Plugin version (steampipe plugin list)
v0.6.0 (forked to use rest/api/2/)

To reproduce

Login to CLI - steampipe query
Execute query:

select
  i.id as issue_id,
  i.status as issue_status,
  i.created as issue_created,
  i.creator_display_name,
  i.assignee_display_name,
  e.id as epic_id,
  e.name as epic_name,
  i.summary as issue_summary
from
  ccoyjira.jira_epic as e,
  ccoyjira.jira_issue as i
where
  i.epic_key = e.key
  and e.key = 'APIGOV-19479'

The above does not yield any results.

Quit the CLI - .quit

Login to CLI again - steampipe query
execute a different query first - select * from ccoyjira.jira_issue where key = 'APIGOV-22292'

re-execute the query from first login:

select
  i.id as issue_id,
  i.status as issue_status,
  i.created as issue_created,
  i.creator_display_name,
  i.assignee_display_name,
  e.id as epic_id,
  e.name as epic_name,
  i.summary as issue_summary
from
  ccoyjira.jira_epic as e,
  ccoyjira.jira_issue as i
where
  i.epic_key = e.key
  and e.key = 'APIGOV-19479'

Now, this yields the expected 48 rows.

Expected behavior
I'd expect it should work the first time without having to issue an initial query. I realize that this must work against Jira Cloud version 3, but I am struggling to understand why it sort of works with this forked version. I have the LOG LEVEL set to TRACE, but can't seem to determine meaningful discrepancies between the logs that explains why it doesn't work under 1 scenario but does in another.

Querying the `sprint_ids` column in `jira_issue` fails for issues that have no sprints

Describe the bug
If an issue has no sprints, the sprint information from the SDK comes back as a string instead of map of strings

Steampipe version (steampipe -v)
v0.20.9

Plugin version (steampipe plugin list)
v0.10.1

To reproduce
See above

Expected behavior
Sprint IDs should return null instead of erroring

Additional context
Add any other context about the problem here.

Add table jira_release

References
Add any related links that will help us understand the resource, including vendor documentation, related GitHub issues, and Go SDK documentation.

Connection configuration is not available through env variables

Describe the bug
To add the connection configuration using env variables is not available as in other plugins, the documentation only defines through the jira.spc. Environment variables should be an option.

Steampipe version (steampipe -v)
v0.17.4

Plugin version (steampipe plugin list)
v0.8.0

To reproduce
The documentation is not defining the env variables available to be exported, also, there is no reference in the code docs.

Expected behavior
Passing the configuration (base_url, username and password) using env variables should be an option like in other plugins like AWS, Azure, GCP, Github, etc.

Strange result sets using epic_key in jira_issue table

Describe the bug
When querying key and epic_key using project_key column key the epic_key returns NULL.

select key, 
epic_key, 
project_key 
from jira_issue 
where project_key = 'BDT' LIMIT 10;

Result set

+----------+----------+-------------+
| key      | epic_key | project_key |
+----------+----------+-------------+
| BDT-4357 | <null>   | BDT         |
| BDT-4360 | <null>   | BDT         |
| BDT-4361 | <null>   | BDT         |
| BDT-4362 | <null>   | BDT         |
| BDT-4364 | <null>   | BDT         |
| BDT-4365 | <null>   | BDT         |
| BDT-4363 | <null>   | BDT         |
| BDT-4366 | <null>   | BDT         |
| BDT-4358 | <null>   | BDT         |
| BDT-4359 | <null>   | BDT         |
+----------+----------+-------------+

When querying key and epic_key using specific keys (as returned above) the epic_key is returned.

select key,
epic_key,
project_key
from jira_issue 
where key in ('BDT-4366',
'BDT-4357',
'BDT-4365',
'BDT-4363',
'BDT-4364',
'BDT-4360',
'BDT-4361',
'BDT-4359',
'BDT-4362',
'BDT-4358');

Result set

+----------+----------+-------------+
| key      | epic_key | project_key |
+----------+----------+-------------+
| BDT-4358 | BDT-2717 | BDT         |
| BDT-4365 | BDT-4364 | BDT         |
| BDT-4366 | BDT-4364 | BDT         |
| BDT-4364 | <null>   | BDT         |
| BDT-4363 | BDT-4362 | BDT         |
| BDT-4359 | BDT-4177 | BDT         |
| BDT-4357 | BDT-4177 | BDT         |
| BDT-4361 | BDT-4177 | BDT         |
| BDT-4360 | BDT-3654 | BDT         |
| BDT-4362 | <null>   | BDT         |
+----------+----------+-------------+

When query again later (in cli or from command line), the results are what they are expected to be for the first query.

+----------+----------+-------------+
| key      | epic_key | project_key |
+----------+----------+-------------+
| BDT-4357 | BDT-4177 | BDT         |
| BDT-4360 | BDT-3654 | BDT         |
| BDT-4361 | BDT-4177 | BDT         |
| BDT-4362 | <null>   | BDT         |
| BDT-4364 | <null>   | BDT         |
| BDT-4365 | BDT-4364 | BDT         |
| BDT-4363 | BDT-4362 | BDT         |
| BDT-4366 | BDT-4364 | BDT         |
| BDT-4358 | BDT-2717 | BDT         |
| BDT-4359 | BDT-4177 | BDT         |
+----------+----------+-------------+

Steampipe version (steampipe -v)

❯ steampipe -v
Steampipe v0.18.6

Plugin version (steampipe plugin list)

❯ steampipe plugin list
+----------------------------------------------------+---------+-------------+
| Installed Plugin                                   | Version | Connections |
+----------------------------------------------------+---------+-------------+
| hub.steampipe.io/plugins/theapsgroup/gitlab@latest | 0.2.2   | gitlab      |
| hub.steampipe.io/plugins/turbot/aws@latest         | 0.94.0  | aws         |
| hub.steampipe.io/plugins/turbot/jira@latest        | 0.8.0   | jira        |
| hub.steampipe.io/plugins/turbot/steampipe@latest   | 0.6.0   | steampipe   |
+----------------------------------------------------+---------+-------------+

To reproduce
See above.

Expected behavior
The first query should not return null.

`jira_user` only listing first 50 entries

Describe the bug
When running SELECT * from jira.jira_user WHERE active = true, I get 2 users. There should be like 115.

As additional context:
When I query the table, it only contains about 50 entries. A quick eyeball of the entries indicates that the only 2 that have "active" set to true are the same two that showed up when I ran the above query

My assumption:
Jira uses a paged list
Each of those jira_user tables is a different page in the list
When I run the SQL query, it only queries the first page in the list
Now my question: what can be done about it?

Steampipe version (steampipe -v)
Example: v0.13.6

Plugin version (steampipe plugin list)
Example: v0.0.2

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Add table jira_priority

References
Add any related links that will help us understand the resource, including vendor documentation, related GitHub issues, and Go SDK documentation.

Improve the help message if `base_url`, or any other key argument is not specified?

Describe the bug
A clear and concise description of what the bug is.

Steampipe version (steampipe -v)
Example: v0.13.6

Plugin version (steampipe plugin list)
Example: v0.0.2

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Add table jira_issue_comments, jira_issue_worklogs, maybe the related Properties tables, and jira_project_properties

select * from jira_backlog_issue

Describe the bug
Whenever I run a query against ira_backlog_issue, I get the error message
Warning: executeQueries: query 1 of 1 failed: ERROR: rpc error: code = Unknown desc = request failed. Please analyze the request body for more details. Status code: 400 (SQLSTATE HV000)
I cannot find any information from the underlying go-jira lib request object despite setting STEAMPIPE_LOG_LEVEL to trace.
The equivalent curl command works from the CLI
curl --request GET --user email:token --url "https://domain.atlassian.net/rest/agile/1.0/board/70/backlog?startAt=140&maxResults=1&expand=names" --header "Accept: application/json"

Steampipe version (steampipe -v)
v0.15.1

Plugin version (steampipe plugin list)
v0.5.0

To reproduce
I had some help from the Slack group but I don't see why the default queries would fail for me.
I have noticed 400 or 403 status codes with the following tables

jira_backlog_issue: 400
jira_advanced_setting: 403
jira_group: 403
jira_project_role: 403
jira_sprint: 400
jira_workflow: 403

Expected behavior
I would expect to run the default queries against my Atlassian domain using my username and token.

Additional context
The underying library's message about checking the request body is frustrating if there is nothing to check

Adding "resolved" field into jira_issue table

Is your feature request related to a problem? Please describe.
I want to be able to know what the resolution date of an issue is to help calculate cycle time, when a bug was closed, etc

Describe the solution you'd like
To have the "resolved" field exposed

Describe alternatives you've considered
Currently using "updated" field. However updated is different from "resolved", as an update could mean changing of description, adding of labels, etc which is different from resolution date

Additional context
Information on the JQL field here

CSV Output Column\Row Truncation

Describe the bug
When using CSV output some of the rows appear to be truncated.

❯ steampipe query
Welcome to Steampipe v0.18.6
For more information, type .help
> .output csv
select key,
       epic_key,
       substring(summary,1,30) "summary",
       assignee_display_name,
       components,
       labels,
       priority,
       created,
       reporter_display_name,
       status
from jira_issue
where project_key = 'PKEY'
and status <> 'Done'
and reporter_display_name in ('Reporter 1','Reporter 2')
order by priority desc, length(title), title asc;

An example of the problem returned rows (as displayed) are...

08T12:35:21+01:00,Reporter 1,Backlog
07-04T14:55:21+01:00,Reporter 1,Backlog
14:40:21Z,Reporter 1,Backlog
,"[""16805"",""16725""]","[""Label 1"",""Label 2"",""Label 3"",""Label 4""]",High,2022-12-16T12:49:54Z,Reporter 1,Backlog

This appears to be mostly on the created column but there are other occurrences that are on assignee_display_name column.

Steampipe version (steampipe -v)

❯ steampipe -v
Steampipe v0.18.6

Plugin version (steampipe plugin list)

❯ steampipe plugin list
+----------------------------------------------------+---------+-------------+
| Installed Plugin                                   | Version | Connections |
+----------------------------------------------------+---------+-------------+
| hub.steampipe.io/plugins/theapsgroup/gitlab@latest | 0.2.2   | gitlab      |
| hub.steampipe.io/plugins/turbot/aws@latest         | 0.94.0  | aws         |
| hub.steampipe.io/plugins/turbot/jira@latest        | 0.8.0   | jira        |
| hub.steampipe.io/plugins/turbot/steampipe@latest   | 0.6.0   | steampipe   |
+----------------------------------------------------+---------+-------------+

To reproduce
As above.

Expected behavior
Complete rows with all queried column data returned.

Additional context
None.

Add table jira_issue_type

References
Add any related links that will help us understand the resource, including vendor documentation, related GitHub issues, and Go SDK documentation.

Update doc to remove > from starting of query

Describe the bug
https://hub.steampipe.io/plugins/turbot/jira, the example query starting with > hence breaking to execute copied of content

> select
  display_name,
  account_type as type,
  active as status,
  account_id
from
  jira_user;

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Querying issues loads all issues

Describe the bug

When querying issues, no filter is passed to the API and all issues are requested from the JIRA API.

With a large number of issues, this can take a very long time, and maybe never succeed.

I had to add traces to the plugin to understand what was going on:

2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: [DEBUG] Steampipe API Request Details:
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: ---[ REQUEST ]---------------------------------------
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: GET /rest/api/2/search?startAt=0&maxResults=1000&expand=names HTTP/1.1
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: Host: mydomain.atlassian.net
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: User-Agent: Go-http-client/1.1
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: Content-Type: application/json
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: Accept-Encoding: gzip
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin:
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin:
2022-02-23 16:09:43.334 UTC [DEBUG] steampipe-plugin-jira.plugin: -----------------------------------------------------
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: [DEBUG] Steampipe API Response Details:
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: ---[ RESPONSE ]--------------------------------------
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: HTTP/2.0 200 OK
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Atl-Traceid: ******
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Cache-Control: no-cache, no-store, no-transform
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Content-Type: application/json;charset=UTF-8
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Date: Wed, 23 Feb 2022 16:09:46 GMT
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Expect-Ct: report-uri="https://web-security-reports.services.atlassian.com/expect-ct-report/global-proxy", enforce, max-age=86400
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Server: AtlassianProxy/1.19.3.1
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Set-Cookie: atlassian.xsrf.token=******; path=/; SameSite=None; Secure
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Strict-Transport-Security: max-age=315360000; includeSubDomains; preload
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Timing-Allow-Origin: *
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: Vary: Accept-Encoding
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: X-Aaccountid: ******
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: X-Arequestid: ******
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: X-Content-Type-Options: nosniff
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: X-Envoy-Upstream-Service-Time: 2753
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: X-Xss-Protection: 1; mode=block
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin: {
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:  "expand": "schema,names",
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:  "startAt": 0,
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:  "maxResults": 100,
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:  "total": 505555,
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:  "issues": [
2022-02-23 16:09:47.480 UTC [DEBUG] steampipe-plugin-jira.plugin:   {
...

Steampipe version (steampipe -v)

v0.12.2

Plugin version (steampipe plugin list)

v0.1.0

To reproduce

steampipe query "select id, key from jira_issue where key = 'MYPROJECT-42';"

Relevant code is https://github.com/turbot/steampipe-plugin-jira/blob/v0.1.0/jira/table_jira_issue.go#L221-L225

Expected behavior

A filter should be added to the JIRA API request to avoid retrieving all issues.

Additional context
N/A

Add query/table to list issue in backlogs

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
https://developer.atlassian.com/cloud/jira/software/rest/api-group-backlog/#api-group-backlog

JQL search on `jira_issue` table is case sensitive while the JIRA API is not

Describe the bug
When I do this query:
select * from jira_issue where status='Open' limit 10 it works.

But when I do:
select * from jira_issue where status='open' limit 10 it returns 0 results.

The lower case open should still return the same results as JIRA JQL is case insensitive. I tried it by calling
the rest/api/2/search JIRA api directly and it works as expected, but not via steampipe.

Steampipe version (steampipe -v)
v0.20.9

Plugin version (steampipe plugin list)
v0.10.1

To reproduce
Do a lower case search on any JIRA field:
select * from jira_issue where status='open' limit 10 for example, to see 0 results.

Expected behavior
The above query should return results including open tickets.

Add user-properties info to jira_user table

Is your feature request related to a problem? Please describe.
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-user-properties/#api-group-user-properties

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.