Bug 584954 - 1.1.7, 4.11: Support selecting of multiple versions per bug report
1.1.7, 4.11: Support selecting of multiple versions per bug report
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
3.6
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: Max Kanat-Alexander
Jiri Pechanec
contractor
: Reopened
Depends On: 584957
Blocks: JIRABZ 694046
  Show dependency treegraph
 
Reported: 2010-04-22 15:14 EDT by David Lawrence
Modified: 2013-06-23 23:37 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-04 07:09:12 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)
Versions field showing HASH (29.29 KB, image/jpeg)
2011-05-10 10:15 EDT, Jiri Pechanec
no flags Details

  None (edit)
Description David Lawrence 2010-04-22 15:14:46 EDT
JIRA Requirements: 1.1.7, 4.11

JIRA currently has the ability to selected multiple "affected versions" for a single issue. Bugzilla only allows for a single version to be selected per bug. Cloning of a single bug report to multiple bug reports, each with a different version, was suggested but not liked very well by the JIRA developers. 

Proposed Solutions(s):

Update Bugzilla core code to allow selecting and storing of more than one version per bug report. A new mapping table would need to be created similar to bug groups, cc, etc. to store the data and new code added to checksetup.pl to migrate the existing versions to the new mapping table.
Comment 1 Max Kanat-Alexander 2010-05-26 17:46:08 EDT
  A simpler solution might be to create a custom multi-select field that mirrors the version value list, and use it in the UI in place of the current version field. We could make the normal "version" field just take the lowest-selected version from the multi-select field. That would maintain API compatibility for the XML and RPC interfaces.

  Optionally, we could also just have an "Also Affected" multi-select that contained additional versions affected besides the base version. That would make searching a bit more complex, though.
Comment 2 David Lawrence 2010-05-27 17:34:07 EDT
(In reply to comment #1)
>   A simpler solution might be to create a custom multi-select field that
> mirrors the version value list, and use it in the UI in place of the current
> version field. We could make the normal "version" field just take the
> lowest-selected version from the multi-select field. That would maintain API
> compatibility for the XML and RPC interfaces.

We thought of that possibility. Having the core version field being the primary and a custom field to hold the extra versions. 
 
>   Optionally, we could also just have an "Also Affected" multi-select that
> contained additional versions affected besides the base version. That would
> make searching a bit more complex, though.    

Problem is the boolean charts would become cumbersome as you would have to have a different "Also Affected" custom field for each product if you wanted the values list to be different for each one. So you could have:

Also Affected (RHEL5)
Also Affected (RHEL6)
Also Affected (BRMS)
...
Comment 3 Max Kanat-Alexander 2010-05-27 19:04:57 EDT
(In reply to comment #2)
> Problem is the boolean charts would become cumbersome as you would have to have
> a different "Also Affected" custom field for each product if you wanted the
> values list to be different for each one.

  Ah, but you wouldn't, because we're already working on allowing multiple-value visibility control for fields. We'd just have to add multiple-value value control for fields.
Comment 4 David Lawrence 2010-06-01 17:20:14 EDT
Ah ok. So that sounds like we could work with that method. I have spoken JIRA folks and they are ok with having additional fields for "Extra Versions", "Extra Components". We could do as you say and add the extra component owners to the cc list of the bug. 

The question still remains on how we query for the extra versions and components. I would assume the JIRA folks are going to expect that when you select component names from the components field in query.cgi, it will do the right thing and search the primary component field in addition to the "Extra Components" field combining the results. Same with versions. Or will they need to for example select ComponentA, ComponentB, and ComponentC from both "Component" and "Extra Components" to find any bugs containing those three values in one or both fields.

Also will we be able to dynamically fill the values for each from the primary fields or will they need to be manually kept in sync? I suppose manually would be ok for now although Fedora has 6000+ components and RHEL has very large component lists as well so it could be prone to error.
Comment 5 Max Kanat-Alexander 2010-06-01 17:43:09 EDT
We can make an extension keep the fields' legal values in sync.

For searching, we could hack Search.pm to also search the Additional fields when searching the basic field.
Comment 6 David Lawrence 2010-06-01 17:56:33 EDT
(In reply to comment #5)
> We can make an extension keep the fields' legal values in sync.
> 
> For searching, we could hack Search.pm to also search the Additional fields
> when searching the basic field.    

Both sound good.
Comment 7 Mike Harvey 2010-08-18 09:34:09 EDT
We need to address the default value to be populated in the "fix For Version" field upon creation of a new bugzilla.  In discussion I have had today, the default value should be set to a "TBD" version.  Later, as part of the triage /review process, this field will be set to an actual valid version where the bug is slated to be fixed.  The thought process is that we don't want bug creators to make decisions as to which version the bug will actually be fixed in.
Comment 8 Mike Harvey 2010-08-18 09:38:33 EDT
opps.  The comment I made above applies to bug: 584956.  I'll move this comment.
Comment 9 Mike Harvey 2010-10-11 14:52:21 EDT
Assigned to Trevor to validate/QA.  https://bz-web2-test.devel.redhat.com/

You can select a single version or additional versions using the Extra Versions custom field. The lists should be the same. The JIRA issues migrated should have these fields populated properly.
Comment 10 Jiri Pechanec 2010-10-21 03:38:35 EDT
Imported bug with affects set to multiple versions - PASSED

Search using Version field and Extra version field - PASSED

Create a bug, set version field, do not set extra version field - FAILED
    - Expected result: version in version field should be automatically propagated to Extra Version field

Multiple extra target releases import - FAILED
    - Compare JBPAPP-3121 with #633213, two versions should be set 4.2.0.GA_CP08, 4.3.0.GA_CP07 but only one (4.3.0.GA_CP07) is

Multiple extra target releases setting - PASSED
Comment 11 David Lawrence 2010-11-30 17:53:46 EST
This bug is related to the same work that is being done for bug 584954. Once that bug is complete then this one will automatically work as well. I am doing them together.
Comment 13 Jiri Pechanec 2011-01-19 10:31:15 EST
Imported bug with affects set to multiple versions - PASSED

Search using Version field using more versions - PASSED

Multiple versions set - FAILED
    - Compare #681367 with JBPAPP-4532. There are 5 versions set on the issue. I found the BZ issue when I looked for versions 4.2.0.GA_CP09, 4.3.0.GA_CP09 but if detail is shown only EAP 5.0.0 is highlighted

Create a bug, set multiple versions - PASSED

Multiple extra target releases import - FAILED
    - Compare #681952 with JBPAPP-4969, I do not see fixed version imported

Multiple extra target releases setting - FAILED
    - I do not see any way how to set target version to allowed value
Comment 14 Simon Green 2011-03-01 01:18:19 EST
Assigning back to me, and marking as blocking JIRABZ.
Comment 18 Jiri Pechanec 2011-05-03 11:23:14 EDT
Imported bug with affects set to multiple versions - PASSED

Search using Version field using more versions - PASSED

Multiple versions set - FAILED, #709227 was for EAP 5.0.0. I added two more versions EAP 5.0.0.BETA and EAP 5.0.0.CR1. After submitting the page shown only the last two versions set, not the original one. But if the bug is open in fresh window, then all three versions are set.
    
Create a bug, set multiple versions - PASSED

Target releases import - FAILED, compare JBPAPP-1500 with #704317
Comment 20 Jiri Pechanec 2011-05-04 04:13:51 EDT
My bad, One Off Releases version is valid the others like Tutorial, Interactive demo etc. are not. See for example #709843 and compare it with JBAPP-4172

JBAPP-4172
Affects Version/s: 4.2.0.GA_CP09, 4.3.0.GA_CP08
Affects: Documentation (Ref Guide, User Guide, etc.)

#709843
Affects Version/s: 4.2.0.GA_CP09, Release Notes

So even the import of versions is incorrect
Comment 21 Simon Green 2011-05-04 06:09:53 EDT
(In reply to comment #18)
> Multiple versions set - FAILED, #709227 was for EAP 5.0.0. I added two more
> versions EAP 5.0.0.BETA and EAP 5.0.0.CR1. After submitting the page shown only
> the last two versions set, not the original one. But if the bug is open in
> fresh window, then all three versions are set.

Fixed, and released on to bz-web2-test.devel.redhat.com
 
> Target releases import - FAILED, compare JBPAPP-1500 with #704317

JBPAPP-1500 has "Affects Version/s: None" in JIRA, and this translates to 'unspecified' in Bugzilla.
Comment 23 Simon Green 2011-05-09 18:59:09 EDT
(In reply to comment #20)
> So even the import of versions is incorrect

This is now fixed. Marked as ON_QA for further testing and comments.
Comment 24 Jiri Pechanec 2011-05-10 10:14:33 EDT
Imported bug with affects set to multiple versions - FAILED
 - Version list contains version HASH(0x...), see for example SOA-3004 on th attached screenshot

Search using Version field using more versions - PASSED

Multiple versions set - PASSED

Create a bug, set multiple versions - PASSED

Multiple extra target releases import - FAILED
 - See for example JBPAPP-1200, Fix Version/s: 4.2.0.GA_CP05, 4.3.0.GA_CP03, but imported bug has none versions set
 
Multiple extra target releases setting - PASSED

Search using Release field using more versions - FAILED
Try https://bz-web2-test.devel.redhat.com/buglist.cgi?classification=JBoss&target_release=4.2.0.GA&query_format=advanced&bug_status=NEW&product=JBoss%20Enterprise%20Application%20Platform
It throws Internal Server Error

Also as I already mentioned see for example JBPAPP-1200
Affects Version/s: 4.3.0.GA_CP02
Affects: Documentation (Ref Guide, User Guide, etc.)
and in imported bug there are two versions set - 4.3.0.GA_CP02 and Documentation (Ref Guide, User Guide, etc.) - Is it really correct?

And to avoid confusion in search form - would not be better to rename listbox Release to Target Release as it is on bug detail?
Comment 25 Jiri Pechanec 2011-05-10 10:15:58 EDT
Created attachment 498018 [details]
Versions field showing HASH
Comment 26 Simon Green 2011-05-11 08:46:05 EDT
(In reply to comment #24)
> Imported bug with affects set to multiple versions - FAILED
>  - Version list contains version HASH(0x...), see for example SOA-3004 on th
> attached screenshot

This is a bug in the migration script. I haven't yet identified the actual bug, and hope to do that tomorrow (AEST).

> Multiple extra target releases import - FAILED
>  - See for example JBPAPP-1200, Fix Version/s: 4.2.0.GA_CP05, 4.3.0.GA_CP03,
> but imported bug has none versions set

This will be fixed when the current migration import is complete on
bz-web2-test.d.r.c.

> Search using Release field using more versions - FAILED
> Try
> https://bz-web2-test.devel.redhat.com/buglist.cgi?classification=JBoss&target_release=4.2.0.GA&query_format=advanced&bug_status=NEW&product=JBoss%20Enterprise%20Application%20Platform
> It throws Internal Server Error

Haven't looked into this yet. Will do that tomorrow morning too.
 
> Also as I already mentioned see for example JBPAPP-1200
> Affects Version/s: 4.3.0.GA_CP02
> Affects: Documentation (Ref Guide, User Guide, etc.)
> and in imported bug there are two versions set - 4.3.0.GA_CP02 and
> Documentation (Ref Guide, User Guide, etc.) - Is it really correct?

No, this will be fixed on the current import too.
 
> And to avoid confusion in search form - would not be better to rename listbox
> Release to Target Release as it is on bug detail?

Agreed.

Leaving as ON_DEV, but the things that are fixed can be tested when the current import is complete.
Comment 27 Simon Green 2011-05-20 02:50:53 EDT
(In reply to comment #26)
> (In reply to comment #24)
> > Search using Release field using more versions - FAILED
> > Try
> > https://bz-web2-test.devel.redhat.com/buglist.cgi?classification=JBoss&target_release=4.2.0.GA&query_format=advanced&bug_status=NEW&product=JBoss%20Enterprise%20Application%20Platform
> > It throws Internal Server Error
> 
> Haven't looked into this yet. Will do that tomorrow morning too.

This is now fixed.
 
> > And to avoid confusion in search form - would not be better to rename listbox
> > Release to Target Release as it is on bug detail?
> 
> Agreed.

I've reversed my thoughts on this. Due to space constraint, I want to leave the headings as 'Release' are 'Milestone'

> Leaving as ON_DEV, but the things that are fixed can be tested when the current
> import is complete.

Now changing to ON_QA, as I believe all issues are now fixed. Please test and let me know of any problems.

  -- simon
Comment 28 Simon Green 2011-05-30 02:40:28 EDT
This change went live as part of the updated last Thursday (EDT).

  -- simon
Comment 29 Jiri Pechanec 2011-05-30 04:46:43 EDT
Imported bug with affects set to multiple versions - FAILED, see JBPAPP-2500
 - Versions are set properly but there is again a HASH string and values from Affects field

Search using Version field using more versions - PASSED

Multiple versions set - PASSED

Create a bug, set multiple versions - PASSED

Target releases import - PASSED

Search using Release field using more versions - PASSED

Multiple target releases set - PASSED
Comment 30 Noura El hawary 2011-05-30 07:57:29 EDT
Hi ,

I looked at JBPAPP-2500 and this is what I found in the Affects Version/s field

Affects Version/s: 4.3.0.GA_CP06, EAP 5.0.0.BETA

I couldn't see any hash strings in the page, can you please provide a screen shot? 

Thanks,
Noura
Comment 31 Simon Green 2011-05-30 20:57:54 EDT
(In reply to comment #30)
> Hi ,
> 
> I looked at JBPAPP-2500 and this is what I found in the Affects Version/s field

Noura: Jiri was referring to https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=JBPAPP-2500 , not JBPAPP-2500 :)

> Affects Version/s: 4.3.0.GA_CP06, EAP 5.0.0.BETA
> 
> I couldn't see any hash strings in the page, can you please provide a screen
> shot? 

The hash appears in the version list. The bug was fixed a few weeks ago, but we haven't done a fresh import since then.

Jiri: Once I have addressed bug 705789 I will do a fresh import on bz-web2-test.devel.redhat.com. I hope this will be done tomorrow (Wednesday AEST)

  -- simon
Comment 32 Simon Green 2011-06-08 08:24:06 EDT
Fresh import is in progress, and should be completed by approximately midday EDT. Please retest after this to make sure all outstanding issues are resolved.

  -- simon
Comment 33 Jiri Pechanec 2011-06-09 09:26:05 EDT
It is June 9th, 1520 CEST. https://bz-web2-test.devel.redhat.com/show_bug.cgi?id=JBPAPP-2500 does not contain HASH(...) string but values from
Affects field are still imported into Version(s)
Comment 34 Simon Green 2011-06-10 06:12:29 EDT
Hi Jiri. 

I think I have misunderstood the requirements, based on comment 20. Are you saying that the affects field in Jira shouldn't be copied to the version field in bugzilla when doing the import?

  -- simon
Comment 35 Jiri Pechanec 2011-06-10 06:20:49 EDT
See comment 26

-----
> Also as I already mentioned see for example JBPAPP-1200
> Affects Version/s: 4.3.0.GA_CP02
> Affects: Documentation (Ref Guide, User Guide, etc.)
> and in imported bug there are two versions set - 4.3.0.GA_CP02 and
> Documentation (Ref Guide, User Guide, etc.) - Is it really correct?

No, this will be fixed on the current import too.
----

So from your reply I supposed that it should not be copied. Could you please clarify this issue? Is Affects field imported into Version field as a result of any other requirement?

I just want to be sure that the current behavior conforms to specification.
Comment 36 Simon Green 2011-06-10 06:34:07 EDT
The affects field in jira is being copied to the version field in bugzilla. If this functionality is not desired, please let me know.
Comment 37 Jiri Pechanec 2011-06-10 09:42:51 EDT
Mike, please decide what is the proper behavior in this case. Should be content of Afftecs field merged with Affect version and merged into one field or not?
Comment 38 Mike Harvey 2011-06-10 12:04:35 EDT
Jiri, I would have guessed this to be the correct/desired behaviour.  Why would we not want to copy the data from the Jira "Affects Version/s:" field to the "version" field in bugzilla as part of the migration.  We may have to discuss on the phone as I suspect I'm not fully grasping the problem.
Comment 39 Jiri Pechanec 2011-06-13 02:26:49 EDT
Hi Mike,

please look at the issue JBPAPP-2500

There are TWO fields 'Affects Version/s' and 'Affects' and BOTH of them are copied into 'Version' field in Bugzilla. Is this mixed of TWO fields into ONE desirable or undesirable behaviour?
Comment 40 Mike Harvey 2011-06-14 09:24:52 EDT
OK.  So, the decision is:  map only Jira 'Affects Version/s' to bz 'Version' field as this is "version" data.

We need to get a sense of the data in the Jira 'Affects' and then map that data to an appropriate bz field.  Currently, the thinking is that Jira 'Affects' filed is used like a keyword field.

Simon, maybe you can provide us with a list of what is typically populated in the Jira 'Affects" field.

Thanks,
Comment 46 Jiri Pechanec 2011-06-22 07:00:47 EDT
Imported bug with affects set to multiple versions - FAILED, see JBPAPP-2500
Version EAP 5.0.0.BETA is not set and in fact it is completely missing in the list of versions.

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