JIRA Rest API add worklog fails when 'started' is included in the payload - python 3

J Glaser October 30, 2024

I have a python 3 script that is adding worklog entries for specified issues.  The script uses the requests module with POST and passes the appropriate payload.  I am able to successfully add these worklogs but I want to specify the started date/time for some later reporting purposes.

When I add the "started:" key - the script fails with a 500 error.  When I remove it, I get the desired 201.

The working payload is simply:
{ "comment": "This is a comment, "timeSpentSeconds": 3600 }

The failing payload is:
{ "comment": ''This is a comment", "started": "2024-10-30T00:00:00.000-0400", "timeSpentSeconds": 3600 }

The url in the requests.post is:
https://<url for our instance>/rest/api/2/issue/12345/worklog - where 12345 is the issue key

I tried various time values in the same format but all error out with the 500

I changed the key "started": to "created": and this DOES go through without errors, but I believe "created" is just being ignored.  The worklog is still created with the time when the script ran.

If I review the worklogs via the api, the "started": is just the time the entries came in when the script runs.

I see examples online, where people are passing the "started" parameter, and they say it works.

Google AI suggested something like dateStarted - I don't recall, exactly but JIRA did not recognize that and I looked at all previous worklogs and there is no such key/parameter.

Any ideas?

[ FYI - I edited the offset in the sample payload.  I had -4000.  It should be -0400.  It has been corrected in the post ]

4 answers

0 votes
J Glaser October 31, 2024

So what is interesting is that I can do an update of the "started" value on an existing worklog using a PUT with the same date/time in the same format as what fails in a create-worklog - go figure.  

My rather ugly workaround, for the time being is to capture the worklog ids when created and then loop through and update the started value.

This is only doable since my script processes very small batches at a time but would be highly unacceptable for large quantities of records.

Maybe this will help someone else - not sure.

Thanks all for the input

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 30, 2024

Hi @J Glaser -- Welcome to the Atlassian Community!

FYI there is a timed-out (i.e., not resolved) defect where the worklog REST API incorrectly returns a 500 error for other causes: https://jira.atlassian.com/browse/JRACLOUD-81320

I found that defect via this developer community post: https://community.developer.atlassian.com/t/inconsistent-behaviour-rest-api-when-creating-updating-worklog-properties/70246/3

 

Kind regards,
Bill

J Glaser October 30, 2024

@Bill Sheboy  - Thanks for that information.  I will see what I can do - perhaps the workaround in the first link will work for me.  If I can get that to work, I will mark this as the accepted answer.  Thanks, again!

0 votes
Jim Knepley - ReleaseTEAM
Atlassian Partner
October 30, 2024

Welcome to the community, @J Glaser 

Your date format looks correct, but you must add "timeSpent" or "timeSpentSeconds" to the request body. One (and only one) of those is required when creating a worklog.

ref: https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-worklogs/#api-rest-api-2-issue-issueidorkey-worklog-post

Jim Knepley - ReleaseTEAM
Atlassian Partner
October 30, 2024

If memory serves, a "500" response from the API includes a JSON document in the response body with some descriptive text. I like to use the Python "requests" library for this sort of thing, and almost always use raise_for_status():

try:
response = requests.post(url, data)
response.raise_for_status()
except HTTPError as e:
raise RuntimeError(response.text)

You'll want to adapt that to your needs and preferences.

J Glaser October 30, 2024

Hi @Jim Knepley - ReleaseTEAM , timeSpentSeconds is in the payload as shown above.  Thanks for the reply.

Jim Knepley - ReleaseTEAM
Atlassian Partner
October 30, 2024

Well, shoot... How did I miss that? I still agree that your date format looks correct, so I would need to experiment to figure it out.

Are you building the JSON payload "by hand" as a string or using the JSON library to convert a dictionary?

J Glaser October 30, 2024

Thanks @Jim Knepley - ReleaseTEAM , will look into that.  However, running the same from Postman, the json body from the response is just the basic error. message.   

I will try the raise in Python.  Appreciate the input. 👍

J Glaser October 30, 2024

I'm simply building my own dict        payload = { "etc": "etc" , "more": "more"}

Works fine without the "started": key

I use this type of payload in requests with other scripts using other product APIs so I know the payload format is good.

Frustrating. though - as it seems that it should be so simple.

FYI - the raise from the try/except just provides "errorMessages":["Internal server error"],"errors":{}

J Glaser October 30, 2024

Unfortunately, nothing I have tried seems to work.  I am stumped as to how some people on other discussion boards seem to have been able to pass "started" along with their payload (I have matched the formats, approaches, etc. item-for-item) and I am not able to get it through.  It seems there are others who have experienced the same as me - so I guess it must be a bug.

This is definitely causing a problem for me, because I need the consistency of a uniform "started" datetime.

I will have to rethink the process from the beginning to see what options I may have (if any) 😔

I appreciate all of the input from everyone.

David Bakkers
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 31, 2024

If you provide a faulty date value for the started parameter, you would normally just get a 400 Bad Request error with a "started": "Invalid date format." message, not a 500 error (which is much more serious).

I suggest you test the request and all your parameter values outside of Python. Use an API test tool like Postman to validate your request works first, thereby at least isolating the problem as being a Python fault vs a request body structure / parameter value fault.

Next, you are on Jira CLOUD right, not Jira SERVER or DATA CENTER? You've obfuscated your Jira instance's domain path as '<url for our instance>' so I can't tell.

PS. For the record, your request body is 100% valid, so it's mostly likely a Python coding mistake or some other factor that you've not tested for yet:

Untitled.png

 

J Glaser October 31, 2024

Hi @David Bakkers ,  thanks for the input. but I have tested in Postman and it fails there as well.

David Bakkers
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 31, 2024

Ok, good, BUT you've really only provided a very small amount of usable information to be able to troubleshoot what is happening.

  1. Are you using Jira CLOUD? Yes or no?
  2. Can you advise what your domain path is ('something.atlassian.net')
  3. Is the problem happening....
    1. On one issue type or all issue types?
    2. In one project or all projects?
    3. For one user's account or all user accounts (if using Basic Auth)?
    4. For one token generated or all tokens (if using OAuth)?
  4. If using OAuth, what scopes have you set and how did you validate them?
  5. Can you login using the same user credentials as you're using with the REST API and use the GUI to set the Start Time for that issue type?
  6. Do you have any third party time tracking add-ins like Temp Timesheets that might be affecting access to the built-in time tracking fields?

If you have done extensive testing to rule out the possible cause as being user error, then a 500 response is totally incorrect for the scenario you describe and indicates a major problem, so you should raise a support request with Atlassian.

0 votes
Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 30, 2024

Hi @J Glaser 

I'm not that fancy in API calls, but could it be due to the date time notation?

Are you using this notation, you could possible check this by getting an existing worklog via the API.

J Glaser October 30, 2024

Hi @Marc - Devoteam Marc, I got the date/time notation directly from our existing worklogs.  Also, it matches what I have see online in discussion communities. 

Like Marc - Devoteam likes this

Suggest an answer

Log in or Sign up to answer