Bug 750800

Summary:	Injected bug link should include url / context ID
Product:	[Community] PressGang CCMS	Reporter:	Joshua Wulf <jwulf>
Component:	Web-UI	Assignee:	Matthew Casperson <mcaspers>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	1.x	CC:	cbredesen, lcarlon, lnewson, topic-tool-list
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-02 00:34:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Joshua Wulf 2011-11-02 12:03:18 UTC

At the moment we can get the Topic ID of a topic when a bug is logged against it. However, this will not be sufficient information.

Imagine the following hypothetical scenario:

Topic 123 is part of a mainstream docs release (say EAP 6)

At some point a special use-case guide is spun up. Let's say a "Getting Started with Hibernate in EAP 6 Guide", remixing EAP 6 topics, including Topic 123.

At this point two instances of Topic 123 exist on the web, in different contexts.

Now let us say that the steps in Topic 123 fail for the user in the GSGw/Hibernate Guide because the author has failed to include some necessary prerequisite step in the guide.

When the user logs a bug against Topic 123 it is ambiguous whether the bug is intrinsic to the Topic 123 content, or extrinsic and due to an architectural fault.

In this hypothetical case only two instances of the topic exist, but potentially the number of instances is unlimited, and an author cannot expect to know what they all are.

If the url of the topic instance is included, this will help in diagnosis.

So two questions:

Since the hosted url is not available at build time, is it possible to have the client inject the current url into the link that it renders on the page?

Otherwise we could pass an argument to the injector at build time to include in the bug link. In the case of the Content Spec Processor it could be the title of the Content Spec plus the Content Spec ID, or even just the Content Spec ID.

Currently the Content Spec processor reuses the Skynet injection code for topic injection. Is the bug link injection code reusable in the same fashion?

Comment 1 Matthew Casperson 2011-11-07 22:20:44 UTC

Fixed in 20111108-0820

Skynet instances can now be identified by a system property. Add a system property to the AS7 configuration.xml file called topicindex.instanceName:

<system-properties>
  <property name="topicindex.instanceName" value="My Skynet Instance"/>
</system-properties>

This value is then added into the bug boilerplate details.

Comment 2 Joshua Wulf 2011-11-14 02:29:37 UTC

It's not per-skynet instance, it's per-topic-instance. So essentially, per-build.

If I build a Developer Guide, an Administrator Guide, and a dynamic website using the same topic, then there is only one bug link at the moment identifying the topic in all three.

So I would need the ability to specify attributes like bugzilla product, component, etc when building each output, to arrive at a unique bug link.

Comment 3 Matthew Casperson 2012-02-23 05:38:41 UTC

Fixed in 20120223-1538

There is a "Build Name" option in the "Build Docbook" tab that allows you to add a custom name to the build that is then included in the Bugzilla links (under the Bugzilla Environment field).

In addition the Product, component, version and keyword elements of the Bugzilla link come from property tags that have been assigned to tags (usually a release tag like EAP 6 GA), which are then assigned to topics.

With this setup you can define the build name property for each location (different guides, dynamic web site etc) so when the bugs are reported (to the same Bugzilla queue), you can tell what the source was.

You can't (easily) define individual Bugzilla properties for each build, but I'm not sure I see the advantage of having bugs reported in different locations for the same topic.