Bug 795413 - RFE: "Report a Bug" switch in the Content Spec
RFE: "Report a Bug" switch in the Content Spec
Status: CLOSED CURRENTRELEASE
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.x
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lee Newson
:
Depends On:
Blocks: 799821
  Show dependency treegraph
 
Reported: 2012-02-20 07:49 EST by Joshua Wulf
Modified: 2014-10-19 19:00 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.22.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-06 21:31:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Wulf 2012-02-20 07:49:02 EST
Can we make a switch in the Content Spec to switch this on or off? Not every document has a bugzilla component to report against.
Comment 1 Lee Newson 2012-02-20 08:59:30 EST
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.
Comment 2 Lee Newson 2012-03-05 01:43:49 EST
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.
Comment 3 Lee Newson 2012-03-05 18:51:31 EST
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.
Comment 4 Lee Newson 2012-03-21 00:10:07 EDT
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.
Comment 5 Joshua Wulf 2012-04-04 09:22:05 EDT
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?
Comment 6 Lee Newson 2012-04-04 18:31:25 EDT
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".
Comment 7 Joshua Wulf 2012-04-05 18:23:13 EDT
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.
Comment 8 Lee Newson 2012-04-09 18:41:50 EDT
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.
Comment 9 Lee Newson 2013-06-06 21:31:03 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.