langchain/tests/integration_tests/utilities/test_jira_api.py

65 lines
1.8 KiB
Python
Raw Normal View History

"""Integration test for JIRA API Wrapper."""
from langchain.utilities.jira import JiraAPIWrapper
2023-04-21 22:49:46 +00:00
def test_search() -> None:
"""Test for Searching issues on JIRA"""
jql = "project = TP"
jira = JiraAPIWrapper()
output = jira.run("jql", jql)
2023-04-21 22:49:46 +00:00
assert "issues" in output
def test_getprojects() -> None:
"""Test for getting projects on JIRA"""
jira = JiraAPIWrapper()
output = jira.run("get_projects", "")
2023-04-21 22:49:46 +00:00
assert "projects" in output
def test_create_ticket() -> None:
"""Test the Create Ticket Call that Creates a Issue/Ticket on JIRA."""
2023-04-21 22:49:46 +00:00
issue_string = (
'{"summary": "Test Summary", "description": "Test Description",'
' "issuetype": {"name": "Bug"}, "project": {"key": "TP"}}'
)
jira = JiraAPIWrapper()
output = jira.run("create_issue", issue_string)
2023-04-21 22:49:46 +00:00
assert "id" in output
assert "key" in output
def test_create_confluence_page() -> None:
"""Test for getting projects on JIRA"""
jira = JiraAPIWrapper()
create_page_dict = (
'{"space": "ROC", "title":"This is the title",'
'"body":"This is the body. You can use '
'<strong>HTML tags</strong>!"}'
)
output = jira.run("create_page", create_page_dict)
assert "type" in output
assert "page" in output
Replace JIRA Arbitrary Code Execution vulnerability with finer grain API wrapper (#6992) This fixes #4833 and the critical vulnerability https://nvd.nist.gov/vuln/detail/CVE-2023-34540 Previously, the JIRA API Wrapper had a mode that simply pipelined user input into an `exec()` function. [The intended use of the 'other' mode is to cover any of Atlassian's API that don't have an existing interface](https://github.com/hwchase17/langchain/blob/cc33bde74ff2e050a400e4451e04ff5b32c4a7bd/langchain/tools/jira/prompt.py#L24) Fortunately all of the [Atlassian JIRA API methods are subfunctions of their `Jira` class](https://atlassian-python-api.readthedocs.io/jira.html), so this implementation calls these subfunctions directly. As well as passing a string representation of the function to call, the implementation flexibly allows for optionally passing args and/or keyword-args. These are given as part of the dictionary input. Example: ``` { "function": "update_issue_field", #function to execute "args": [ #list of ordered args similar to other examples in this JiraAPIWrapper "key", {"summary": "New summary"} ], "kwargs": {} #dict of key value keyword-args pairs } ``` the above is equivalent to `self.jira.update_issue_field("key", {"summary": "New summary"})` Alternate query schema designs are welcome to make querying easier without passing and evaluating arbitrary python code. I considered parsing (without evaluating) input python code and extracting the function, args, and kwargs from there and then pipelining them into the callable function via `*f(args, **kwargs)` - but this seemed more direct. @vowelparrot @dev2049 --------- Co-authored-by: Jamal Rahman <jamal.rahman@builder.ai>
2023-07-05 19:56:01 +00:00
def test_other() -> None:
"""Non-exhaustive test for accessing other JIRA API methods"""
jira = JiraAPIWrapper()
issue_create_dict = """
{
"function":"issue_create",
"kwargs": {
"fields": {
"summary": "Test Summary",
"description": "Test Description",
"issuetype": {"name": "Bug"},
"project": {"key": "TP"}
}
}
}
"""
output = jira.run("other", issue_create_dict)
assert "id" in output
assert "key" in output