275386 - importxml.pl does not understand <group> tags

Status: NEW

(Bugzilla :: Bug Import/Export & Moving, defect)

Description

[Ravenous Bugblatter Beast]

When importing bugs it is not possible to use the <group> tag in the XML to
specify the product group to which the bug belongs. This tag is generated by a
query with &ctype=xml appended to the query string.

I have worked around this by manually running a mysql query to insert rows into
bug_group_map after performming the import.

Comment 1

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 2

[Greg Hendricks]

we do not want to allow arbitrary <group> tags to be the basis ofdetermining the groups an imported bug belongs in as this could potentially create inconsistencies in the group tables. 

It is better to add the imported bug to the groups which it's product is a member of. This way we know the imported bug behaves the same as any other new bug in the product.

dependent bug addresses this.

Comment 3

[Frédéric Buclin]

(In reply to comment #2)
> we do not want to allow arbitrary <group> tags to be the basis ofdetermining
> the groups an imported bug belongs in as this could potentially create
> inconsistencies in the group tables. 
> 
> It is better to add the imported bug to the groups which it's product is a
> member of. This way we know the imported bug behaves the same as any other new
> bug in the product.

I partially disagree. I agree that imported bugs have to be in all mandatory groups applying to the product, even if those groups were not in the XML file; I also agree that groups which do not apply to a given product have to be ignored, even if they are in the XML file. But we could discuss what to do with the remaining groups. The patch in bug 285614 gives you no alternative. Maybe it should, especially if the group has Shown/NA or Shown/Shown settings.

Comment 4

[Greg Hendricks]

Doesn't Shown/Shown or Shown/NA cause the group to be a part of Product::group_controls?

importxml as currently written will add the bug to ALL groups in Product::group_controls EXCEPT in the case where it is NA/NA. It will also display in the comments that it is ignoring <group> tags but displays their value so that if you wish to manually add the bug(s) to such groups you can search for them and Update accordingly.

Comment 5

[Frédéric Buclin]

<group> has been added to the list of known fields, so the maintainer will not be informed. And so bug 285614 doesn't fix it.

Comment 6

[Matthias Kienle]

(In reply to comment #4)
> importxml as currently written will add the bug to ALL groups in
> Product::group_controls EXCEPT in the case where it is NA/NA.

This function should be implemented, but coded is 'if both controls not equal NA then add the bug to the groups'. I think it would be helpful to implement 'do nothing if both controls are NA'.

if ($product->group_controls->{$group_id}->{'membercontrol'} != CONTROLMAPNA
   && $product->group_controls->{$group_id}->{'othercontrol'} != CONTROLMAPNA){
        $sth_group->execute( $id, $group_id );

If i am a member of the group (membercontrol != 0) which we would add the bug the value of othercontrol is for me not from interest. add the bug to his group

if ($product->group_controls->{$group_id}->{'membercontrol'} != CONTROLMAPNA
   || $product->group_controls->{$group_id}->{'othercontrol'} != CONTROLMAPNA){
        $sth_group->execute( $id, $group_id );

I have done a simple replace of && with || and it looks fine for me

please review the part of code and over think the code iplmentation

Comment 7

[Frédéric Buclin]

ghendricks, we should decide what to do with this bug before 3.2rc1.

Comment 8

[Greg Hendricks]

waiting for Bug.pm.

Comment 9

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.