|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
There are lots of API endpoints which are not documented, mainly because the creator did not document them. (In this case I am at fault, though I doubt the endpoint I was replacing was documented either.)
So this is simply a bug. Using HttpResponses.forwardToPreviousPage() is commonplace in @RequirePOST endpoints that are not expected to display anything special where the UI invoker is just something that sends a POST via a form and does not want the rendered page to change. One easy fix would be to make this method in Stapler check whether there actually is a Referer, and if not, just delegate to ok() instead.
The proper fix would probably be to think of this as a real API and return 204 No Content, optionally with some body or status message indicating whether anything was actually canceled. It is also necessary to ensure that whatever status code is chosen, stopButton.jelly (called from two places with cancelItem) will not try to reload the page. From the use of _onclick_="new Ajax.Request(this.href); return false" it looks like this would already be true regardless of the status code.
And it looks like we need a Queue/_api.jelly listing the various operations. Currently this gives only generic information.