Atlassian Error: "An issue type with this name already exists" #23
Comments
|
Can you provide the full traceback and some debug logs? |
|
whats your config file look like? |
|
Just like the example: tenable:
access_key: 000001773236158ce8943c7369c12f98c092be2e1582b95ef86da5a6c3700000
secret_key: 111111773236158ce8943c7369c12f98c092be2e1582b95ef86da5a6c3711111
jira:
api_token: 11111scPw10lX2WvDoj00000
api_username: username@company.com
address: company.atlassian.net
project:
leadAccountId: 554433:00112233-ffee-aabb-aabb-998877665544 |
|
May I ask that you add in the following to your config and try to re-run: log:
level: debugThen paste in the output. If you want to make is more readable, simply wrap the output in with 3 ticks (the unshifted tilde) above and below. |
|
Thats odd. It appears to be trying to create a Sub-Task issuetype, which it shouldn't ever to as the default one should exist. Can you create this python script next to your config file, run it, and then paste the output? Basically what it's doing is retrieving the list of issuetypes and printing them to the screen. from tenable_jira.jira import Jira
from tenable_jira.config import base_config
from restfly.utils import dict_merge
import yaml, json
config_file = 'config.yaml'
config = dict_merge(
base_config(),
yaml.load(open(config_file), Loader=yaml.Loader)
)
jira = Jira(
'https://{}/rest/api/3'.format(config['jira']['address']),
config['jira']['api_username'],
config['jira']['api_token']
)
print('Available Issue Types are:')
for a in jira.issue_types.list():
print('{:>10}: {}'.format(a.get('id'), a.get('name'))) |
|
Yeah i was having trouble tracking where this issue was coming from. |
|
alrighty, well thats a lot of task and subtask issuetypes... You're likely going to need to manually force the task and subtask settings in the config. Add this in and see if it works: issue_types:
- jira_id: 3
name: Task
type: standard
search:
- Tenable Plugin ID
- jira_id: 10000
name: Sub-task
type: subtask
search:
- Tenable Plugin ID
- Tenable Asset UUID
- Device IPv4
- Device IPv6
- Vulnerability Port
- Vulnerability Protocol |
|
where am i adding that? in the config file? |
|
yup. |
|
I'm gonna need the full debug log. |
|
Looks like the rood cause is the issuetype for the task. Using the output from your issuetype selection, you have the following issuetypes with the same name (below). I had selected the lowest number for each in my config I had sent you, but you should try some of the other IDs and see if you have better success. I dont have a better answer for you sadly, as Jira's APIs are quite limited in this regard. |
|
Changing the ID's that aren't in that list, triggers a new error with |
|
can you update to the latest version of the integration? The later versions will actually report their version in the logs. |
|
yeah we haven't done this integration and its the first time getting it going. Looks like it is the lastest version and the version is being show in the logs as |
|
yes. i didnt see it in the debug you had sent before. |
|
Hmm, looking more closely at the logs, it appears that it's not able to select the appropriate screens... As a result of that, it's not associating the fields to the screens. I think we're going to have to explicitly declare to the integration the screen IDs. If you goto the configuration within Jira and look for the following screens:
If you click either the screen:
jira_ids:
- 10016
- 10017This should sidestep the screen searcher and just tell the integration to populate the tabs for those screens. This happens as Jira doesn't have a way to find the direct linkage between a project and a screen via the API, so the integration is trying to figure it out by the name. It's not perfect, and seems to have run afoul here. If all works well, you should see a lot more IDs being logged in the beginning of the run, basically detailing the screen id, tab id, and field id. |
|
accidentally closed. Working on trying this out |
|
Should those screen already exist? or do we need to create those screens and screen schemes and then add that to the config file with the ID's for the new screens (replacing the IDs you sent) |
|
those screens should have been created with the VULN Project |
|
Yeah the screens were not there. Need to create those and im assuming the screen schemes will also need to be created or those fields get created by the script? |
|
Once the screens are created, the script will create & populate the fields and tabs within those screens. |
|
Thanks for the help Steve! |
|
Everything working now? |
|
yup, got it working. When we run this will it close vuln tickets that have been addressed and then reopen the same ticket if that same vuln comes back? |
|
It will not re-open an old ticket, but create a new one instead. it will auto-close tickets when the vulnerability state changes to fixed/closed. These are all detailed out further in the readme ;) |
|
Hi SteveMcGrath, Could you please confirm if this python script is complete and from which url we can get all the modules used in the import such as jira, base_config, etc.? from tenable_jira.jira import Jira config_file = 'config.yaml' config = dict_merge( Thanks |
Getting an error when running the script. Not sure what on the JIRA end is causing this issue
The text was updated successfully, but these errors were encountered: