Getting Bad Request, possibly due to Date.toString

[nafg]

I'm getting a 400 error while trying to create an issue. This is my theory as to the cause:

IssuesApi.java line 219 passes createdAt and dueDate to withParam, which toStrings it, which results in values like Sun Feb 10 05:22:13 EST 2013, however https://docs.gitlab.com/ee/api/issues.html#new-issue says it has to be in ISO 8601.

[gmessner]

@nafg
GitLab4J uses Jackson JSON which is set up to marshal all dates using ISO8601. There are also functional unit tests that verify that createIssue() is working correctly (see src/test/java/org/gitlab4j/api/TestIssuesApi.java). Something else in the call is causing this.

If you send the code leading up to the request with the value of each parameter, I should be able to determine what the problem is.

[nafg]

Here is a screenshot from the debugger while inside createIssue, showing the value of each parameter:

I don't see where JSON comes in to the picture since it's sending it as a GitLabApiForm, form-encoded POST body. The toString that I mentioned is here: https://github.com/gmessner/gitlab4j-api/blob/master/src/main/java/org/gitlab4j/api/GitLabApiForm.java#L51

Thanks.

[nafg]

Note that TestIssuesApi only (AFAICT) tests the 3-parameter overload of createIssue, so createdAt would be null, thus not testing the toString behavior mentioned.

[nafg]

assigneeIds would be a similar issue. I'm not even sure how gitlab wants it to be formatted.

[zhengrenjie]

Date time string, ISO 8601 formatted, e.g. 2016-03-11T03:45:40Z (requires admin or project owner rights) have a try!

[gmessner]

@nafg
You are correct, thanks for pointing this out. withParam() has been overloaded to handle both Date and List types correctly. I've also added a test for createIssue() with both createdAt and assigneeIds parameters set.

I've released version 4.8.26 with the fix, please verify and close this when you have a chance.

[nafg]

I was using it to import my tickets from youtrack, and in the end I just used an http library, so I don't have what to try it with anymore.

However, the code looks good, plus it has a test, so I would assume it's solved.

(P.S. Since you're requiring Java 8, you could use java.time to do ISO-8601. Similarly, there are better types than java.util.Date. In fact, if createdAt was a java.time.Instant and dueDate was a java.time.LocalDate, arguably the most fitting types, then .toString() would be the right format. But of course, that's a breaking change, or at least an API change, which is a separate discussion...)

[gmessner]

@nafg
In reference to the use of java.time and changing to something other than Date. The ISO8601 formats used by GitLab are not always sensible and the ISO8601 class included in GitLab4J handles those insensibilities. Switching to another class for date types would be a problem with the consumers of this library, so there is really no benefit in doing so.

Do appreciate the suggestions though.