Bug 584954

  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.

(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)
...

(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.

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.

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.

(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.

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.

opps.  The comment I made above applies to bug: 584956.  I'll move this comment.

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.

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

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.

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

Assigning back to me, and marking as blocking JIRABZ.

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

Version field contains not only data Affects Version from Jira, but also from Affects field. See search
https://bz-web2-test.devel.redhat.com/buglist.cgi?classification=Other&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&version=Compatibility%2FConfiguration&version=Documentation%20%28Ref%20Guide%2C%20User%20Guide%2C%20etc.%29&version=Interactive%20Demo%2FTutorial&version=One%20Off%20Releases&version=Release%20Notes&product=JBoss%20Enterprise%20Application%20Platform

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

(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.

(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.

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?

Created attachment 498018 [details]
Versions field showing HASH

(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.

(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

This change went live as part of the updated last Thursday (EDT).

  -- simon

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

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

(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

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

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)

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

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.

The affects field in jira is being copied to the version field in bugzilla. If this functionality is not desired, please let me know.

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?

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.

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?

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,

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.