Bug 795413

Agreed however I also believe that you should be able to switch it off via the client. I'll comment back once both are complete.

Added in 0.22.0.

While there isn't a direct switch in the Content Spec I've added three new attributes to the META data:

BZCOMPONENT
BZPRODUCT
BZVERSION

If BZCOMPONENT and BZPRODUCT are specified then the links will be turned on. You can also turn off the injections by using the "--hide-bug-links" parameter.

The Entity file that's created when building also uses these new parameters but will default back to using the VERSION and PRODUCT attributes if the Bugzilla attributes aren't specified.

Edit:

I've left this in the code but since Matt has added a set of Bugzilla properties for tags, this is partly redundant. As such I've made it so that if the CSP META data properties are specified then they will be used as a backup source where the Bugzilla properties have not been set.

Since these properties can no longer be used to successfully define that the links should be disabled I've also added a "Bug Links = (On|Off)" META data tag to the content specification. If this option isn't defined then default will be on.

These properties will still be used to insert into the .ent file as described above.

You can still turn off injections by using the "--hide-bug-links" options in the client.

Slight change to this. The order is now reversed, so now the properties in a Content Specification will be used over the properties in Skynet.

OK, so when 

Bug Links = On 

then the Bugzilla properties of a tag applied to a topic supply the BZ data. If no tag with BZ data is applied to the topic, then the CS Meta data BZ data (if supplied) is used.

What happens if more than one tag with BZ Data is applied to a topic?

No the opposite way Josh. That was how it originally worked. The bugzilla data per topic is unique so it won't save duplicate data. As for having two tags that contain bugzilla information it's handled the same way as Skynet which is the first in first serve approach. So the first tag found with bugzilla information will be used, that is why you should only add bugzilla information to the release tag.

So to sum up it will use the CSP Meta data first. If no meta data is supplied then it will attempt to use the bugzilla data attached to each topic. If a topic has no bugzilla data then the bugzilla link is just to "https://bugzilla.redhat.com/enter_bug.cgi".

Thanks for the info Lee. I'm documentingthis behaviour and I've got a couple follow on questions.   

When topics are reused, they will tagged with more than one release tag. So it will be luck of the draw who gets the bug report. 

1. Is there a mechanism to ensure that a bug logged against (for example) JBEAP topic that has been included in a Messaging book will prompt the Messaging book owner to triage impact/fix the topic rebuild the book?

2. If the bug is logged against the EAP component, is there a way for EAP component owner to know that the bug was actually raised against a specific instance of the topic in a Messaging book?

Because the bug might be about the structure of the book (for example missing or incorrectly ordered procedure in a process/missing topic required in the book, or some other error that's output and not topic-specific). In which case the EAP component owner can't fix it.

To be honest the Skynet bug feature is just a fall back mechanism. The main idea would still to use the Content Spec Bug Meta Data to specify bug links.

As for Question 1: no, because it is just a fall back so it may be better to just remove the fall back.

Question 2: No but that could be added fairly easily. Atm it will put in the environment that it was built by the CSP but not which content spec it was built in.

Closing and setting as current release as no QA was performed by the original reporter. If there is still an issue with this bug still than please re-open it.