WFK has moved to JIRA and made their Bugzilla instance read-only. This means that Report a Bug links in WFK docs no longer work. Please work with Sneha and Petr, the WFK writers, to determine which fields need to be set via the content spec and how to form the URLs. Also, please consider making the BZ and JIRA base URLs configurable. I wonder if we should support Github or Google Code issue tracking as well. If you guys decide this is possibly in scope, please clone this RFE accordingly. While this is important, it is not urgent. Please prioritize it to fit in with the rest of your work.
This is possible for JIRA see: https://confluence.atlassian.com/display/JIRA/Creating+Issues+via+direct+HTML+links Basic example bookmarkable URL: https://issues.jboss.org/secure/CreateIssueDetails!init.jspa?summary=test&pid=12313921&issuetype=1
I've taken a better look into what is involved with this and unfortunately it's not going to be as easy as Bugzilla, however still doable without too much effort. Firstly, since the required elements for the URL are ids and not names that means we'll have to do a look up. To do this we'll either have to make the users enter the key as the project (ie WFK2), or get them to enter a name and then pull down all the projects and find the matching project name. We'd have to do something similar with component, however it can be obtained easier from the project. Secondly, as far as I can see there is no way to validate the labels, unlike keywords in Bugzilla. In saying that though that doesn't look like it'll be an issue as you can put any label, even if it's not a recommended one. Thirdly, we'd have to create our own REST wrapper or do the calls using plain HTTP calls, as I was unable to find a library that wouldn't clash (the JIRA once uses Jersey and much older components than we are using). All those points however aren't blockers in anyway. The third point being the one that will take the longest to implement.
REST API Docs: https://docs.atlassian.com/jira/REST/latest/
Hi Lee, I already managed to create a URL in one of our books, staged at [1]. 1) I used JIRA CLI [2] to obtain the IDs, it was pretty easy. 2) Why would you want to validate the labels. If you provide the "docs" label as part of the URL, as I did in [1], that's all we need. Or am I missing something? 3) I don't understand why you need REST calls. Do you want to obtain the IDs and stuff automatically? Wouldn't it be better if you just let us create a topic and the default feedback section with it, the same as I did in [1]? [1] http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_JBoss_Web_Framework_Kit/2.4/html/Errai_Quickstart_Guide/jboss-feedback.html [2] https://marketplace.atlassian.com/plugins/org.swift.jira.cli
EDIT: in 3) above, I meant "... and override the default feedback section with it"
This has little to do with a feedback topic and is specific to the "Report a Bug" links below each topic, but yes you could do that if you wanted. As for one, that is too complex for some and they won't understand. It would be much simpler, if they can just specify the Project/Component names which they can easily see. For 2 you may want to specify something other than docs or perhaps something extra so it needs to be configurable, so as with all user input it'll need to be validated. For 3 to do both 1 and 2 you'll need access to the REST API to do that.
Petr, Lee is correct, these are two separate issues. The Feedback one is already solved well enough, for the most part. Lee, I don't think keywords need validation in JIRA. Assuming that the book had the product, component, and keywords set in the spec (just like in Bugzilla), rather than detected automatically, can you please estimate how many ideal hours it would take to do this RFE?
Yeah you are correct Misty, labels can be any String. I found that out when I wrote a REST Client that uses RESTEasy on the weekend (see https://github.com/lnewson/JIRARESTClient). As for an estimate it primarily depends on a couple of things I'd need to discuss with Matt (which I'll do during the weekly meeting tomorrow) but I'd say about 3 hours, given that I've already done the hard part.
Right, now I see this being two different issues. Sorry, I was not getting the whole picture. We will stick with overriding the Feedback topic for now, and switch to automated when it's available. As for the "Report a Bug" links, our next release is scheduled for mid-November, so it'd be fine having it implemented by then. Thanks for the additional info.
Added in csprocessor 1.0.0. The new Meta Data elements are: JIRAServer = <JIRA Server URL> JIRAProject = <JIRA Project Name, Key or ID> JIRAComponent = <JIRA Component Name or ID> JIRAVersion = <JIRA Version Name or ID> JIRALabels = <comma separated list of labels> The Server and Project are the only compulsory elements. Example: JIRAServer = https://issues.jboss.org/ JIRAProject = WFK2 JIRAComponent = Errai These elements will be validated and produce warnings if the content cannot be found. Upon building if the elements can't be found then a build exception will be thrown.
Petr pointed out today that I've missed something very important. To switch from using Bugzilla Bug Links to JIRA, you need to add/change the following metadata option: Bug Links = JIRA
Going to mark this as complete since it released fully in 1.2 and I know some people are currently using it.