Jira in Python issue.fields.reporter.name errors with TypeError ('NoneType')

[James Gootee]

We've been using multiple Python scripts to manage specific projects within our cloud-based Jira instance for some time.

Today, one of our scripts began failing when attempting to retrieve "issue.fields.reporter.name" with TypeError: argument of type 'NoneType' is not iterable

This is a fairly simple script attempting to check if there is a "due date" set, and if not, write a friendly little comment to the reporter indicating they did not set a "due date".

Code block looks like:

...

logger.debug('Issues to upate: %s', issuesToUpdate)
logger.debug('Next deploy day: %s', next_deploy_day.strftime('%m-%d-%Y'))

for issue in issuesToUpdate:
    reporter = issue.fields.reporter.name
    comment = '[~' + reporter + '] No due date was assigned so I set it to '
    comment += 'the upcoming deployment on' + next_deploy_day.strftime('%A')

...

Output for this section looks like:

DEBUG:__main__:Issues to upate: [<JIRA Issue: key=u'DEPLOY-8943', id=u'86080'>]
DEBUG:__main__:Next deploy day: 11-20-2018
Traceback (most recent call last):
File "updateDeployDueDate.py", line 151, in <module>
main()
File "updateDeployDueDate.py", line 65, in main
reporter = issue.fields.reporter.name
File "/srv/virtualenv/jirabot/local/lib/python2.7/site-packages/jira/resources.py", line 128, in __getattr__
if hasattr(self, 'raw') and item in self.raw:
TypeError: argument of type 'NoneType' is not iterable

Weird thing is if I step through this function and attempt some prints along the way (specifically on this issue print issue.raw['fields']['reporter']) I get the following (I modified these values to protect the innocent):

>>>[stdout:]{u'displayName': u'XXXXX', u'name': u'XXXXX', u'self': u'https://XXXXX.atlassian.net/rest/api/2/user?accountId=XXXXX', u'avatarUrls': {XXXXX}, u'emailAddress': u'XXXXX', u'key': u'XXXXX', u'active': True, u'timeZone': u'America/New_York', u'accountId': u'XXXXX'}

I've checked the DEPLOY issue itself, and there is clearly a reporter, and looking at this output it looks like issue.fields.reporter.name is definitely set.

We are still running jira 1.0.3 python package, and I do believe there is a 2.x out there; but I am unable to find anything that indicates this is deprecated at this point. Any help would be lovely.

[James Gootee · Accepted solution]

The risky, convoluted hack I mentioned in my reply:

...

for issue in issuesToUpdate:
    try:
        reporter = issue.fields.reporter.name
    except TypeError:
        try:
            #specific structure hack - this will need to be watched I'm sure.
            rawIssue = issue.raw['fields']['reporter']
            reporterList = rawIssue.items()
            logger.debug('Reporter: %s', reporterList[1][1])
            reporter = reporterList[1][1]
        except:
            reporter = ''
        if reporter is '':
            comment = ''
        else:
            comment = '[~' + reporter + '] '
    comment += 'No due date was assigned so I set it to '

...

[Andy Heinzer]

I saw another user that had a similar error in regards to using python and Jira Cloud recently.  Please see https://community.atlassian.com/t5/Jira-questions/jira-python-Getting-error-on-assignee-gt-TypeError-Resource/qaq-p/930839

Initially I thought this would have something to do with the recent changes Atlassian is making in regards to user objects in the REST API because of GDPR.  But the user in that thread did indicate that in their case their problem was resolved by updating the python package.   I realize theses are not exactly the same error, but both are dealing directly with user objects in Jira Cloud via REST API python calls.  So I hope this helps.

[James Gootee]

Yeah, after looking over https://developer.atlassian.com/cloud/jira/platform/api-changes-for-user-privacy-announcement/?_ga=2.98850909.237961322.1542300824-312546730.1538767719 that you mentioned in that response, this is probably the reason these are failing.

"name" - Removed following the deprecation period

Sounds pretty related.

Since the payload coming back at this time does have the data I need, I've added a really convoluted and risky hack for the time being that looks something like:

I'm rather reluctant to pursue upgrading the Jira package component we use at this time for 2 reasons:

1) This is the only script out of quite a few that use this particular field and currently none of the other scripts fail at retrieving any data needed for their actions. I don't want to open a can or worms at this time if its not necessary, and I worry upgrading might break some other scripts in other unforeseen ways!

2) I don't actually have direct control over the server and the Python configuration where these scripts run, and attempting to get the parties involved that would be needed is another can I'd like to keep closed if at all possible.

I will however keep this in mind, as it definitely does seem like it is directly related to those changes. And if there comes a time that the only resolution that can be reached is by upgrading our package, I'll have to pursue it then.

[James Gootee]

Sorry, the "hack" I refer to I added as a separate answer.