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 ]
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jim Knepley - ReleaseTEAM , timeSpentSeconds is in the payload as shown above. Thanks for the reply.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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. 👍
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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":{}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok, good, BUT you've really only provided a very small amount of usable information to be able to troubleshoot what is happening.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.