Bug 481660 - [RFE] Need ability to have multiple aliases for a single bug report
[RFE] Need ability to have multiple aliases for a single bug report
Status: CLOSED NEXTRELEASE
Product: Bugzilla
Classification: Community
Component: Database (Show other bugs)
3.2
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: Noura El hawary
: FutureFeature
Depends On: 485170
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-26 16:53 EST by David Lawrence
Modified: 2013-06-24 00:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-23 13:00:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
v1 for having multiple aliases for a single bug (27.08 KB, patch)
2009-02-11 09:43 EST, Noura El hawary
dkl: review-
Details | Diff
v2 for adding multiple aliases to a bug (27.07 KB, patch)
2009-02-16 08:56 EST, Noura El hawary
dkl: review-
Details | Diff
Patch demonstrating unified section_title in edit.html.tmpl (dkl) (25.62 KB, patch)
2009-02-16 14:07 EST, David Lawrence
no flags Details | Diff
v4 for adding multiple aliases to a single bug (34.66 KB, patch)
2009-02-17 07:28 EST, Noura El hawary
dkl: review+
Details | Diff

  None (edit)
Description David Lawrence 2009-01-26 16:53:47 EST
Description of problem:
The Security Response Team would like the ability to have multiple 'aliases' for a single bug report. Currently they use the alias field to record the CVE identifier of the security issue and have too create several bugs that each have a different CVE identifier as the alias. If a bug could have multiple aliases then they could create one bug report with all of the relevant CVE identifiers attached to it. The multiple aliases would still need to be unique and each one cannot be attached to more than one bug report for the alias process to still work. 

Code wise, we would need a mapping table instead of a single varchar in the bugs table to contain the multiple values. Also when searching for a bug by alias either using the boolean charts or simply typing show_bug.cgi?id=ALIASNAME it should still find the correct bug report.

The web UI would need some design consideration as using a standard text field would not work as we already allow empty space in a single alias. Normally we could separate on the whitespace or commans. Maybe we would create a drop down list that could be added to or subtracted from.

Another option would be to keep the single varchar the way we have it, have the s-r-t members enter all CVE's in the alias field, but change the code that looks up a bug by alias to so a substring search of the alias field if at first it does not find an exact match. This would give the impression of having multiple alias support built in.

Opinions?
Comment 1 David Lawrence 2009-01-26 16:54:28 EST
Noura, do you have time to look into this request once you are done with the enter_bug.cgi enhancements?

Dave
Comment 2 Noura El hawary 2009-02-03 22:29:57 EST
Hey Dave,

I thought about how we can implement this feature, here is what i think we can do:

1- create a table maybe call it bug_aliases with 2 columns: alias and bug_id, alias is going to be the primary key of the table and this will assure us that no alias will exist more that once and it will be a completely unique value, bug_id is going to be the foreign key for the bugs.bug_id field.

2- write a migration script that will migrate aliases from the bugs table to the new bug_aliases table.

3- how the interface for the multi aliases is going to look like, i suggest that we make it similar to the cclist interface in the bug report, so maybe the first value added will appear for the alias and then there will be an edit button, that when the user click it will show all aliases and then user can select aliases to remove, edit or can add new aliases to the list. 

4- then for all the code that processes the bug alias we will direct its work from looking into bug.alias to looking at the new bug_aliases table.

Please let me know what you think Dave about the above, if it sounds good to you then i can start implementing it, it is an interesting bug for me :)

Noura
Comment 3 David Lawrence 2009-02-04 15:57:32 EST
(In reply to comment #2)
> 1- create a table maybe call it bug_aliases with 2 columns: alias and bug_id,
> alias is going to be the primary key of the table and this will assure us that
> no alias will exist more that once and it will be a completely unique value,
> bug_id is going to be the foreign key for the bugs.bug_id field.
> 

We would call it 'bugs_aliases' to be consistent with the other tables names but you are correct in the design.

> 2- write a migration script that will migrate aliases from the bugs table to
> the new bug_aliases table.

We would then drop the bugs.alias field after the migration.

> 3- how the interface for the multi aliases is going to look like, i suggest
> that we make it similar to the cclist interface in the bug report, so maybe the
> first value added will appear for the alias and then there will be an edit
> button, that when the user click it will show all aliases and then user can
> select aliases to remove, edit or can add new aliases to the list. 

I like the concept. Should we show all aliases in a comma delimited list? Or do you think it would be two cluttered. Maybe Show the first one or two and then have a "More.." link at the end that will use javascript to finish the displaying the rest of the list?

> 4- then for all the code that processes the bug alias we will direct its work
> from looking into bug.alias to looking at the new bug_aliases table.
> 

Yeah. Sounds good. Bugzilla::Bug::bug_alias_to_id would be one of the few places that would need to be changed. Unless there are lots of places in the code that are accessing bugs.alias directly.

Most of this sounds very doable and may not be too much hassle. Let me know how long you think it will take.

Dave
Comment 4 Noura El hawary 2009-02-05 00:00:21 EST
hey Dave,

I don't think it will take much maybe couple of days, so I guess i can submit a patch for it by early next week.

Noura
Comment 5 Noura El hawary 2009-02-11 09:43:43 EST
Created attachment 331568 [details]
v1 for having multiple aliases for a single bug

Hi,

attached is a patch that will enable us to have multiple aliases for a single bug,
I have talked with mkanat from upstream about this feature and if they will be looking at implementing, and he told me that it is not needed for upstream and it would just add unnecessary code complexity for them, but he also mentioned that he saw in few places people asking about this feature.

Please note that the attached code is now on bz-web2 so you can use it for testing.

notes about the patch:

1- users can now enter multiple bug aliases at bug entry time, by having multiple aliases with comma or space separated.

2- alias is no more shown at the bug title, it is now listed under the CC list section in the bug report , and it works same way as how the CC list works, with the difference that aliases are unique ofcourse.

3- users can use show_bug.cgi?id=$ALIASNAME  using any of the bug alias names and also can still use aliases in the quicksearch.

4- buglist.cgi will contain bug aliases and i used for that a mysql function AliasList(bugs.bug_id)

5- BugMail and Bug history are also working as they should be with multiple aliases.


TODO:

1- need to change the schema code in bugzilla code to create the new table bugs_aliases and drop the column bugs.alias i will ask Tony to implement that if he can.

2- I wasn't sure how to treat the alias in 'template/en/default/bug/dependency-tree.xml.tmpl'

Please review and test and let me know what you think.

Thanks,
Noura
Comment 6 David Lawrence 2009-02-11 17:46:22 EST
Noura will more review tonight/tomorrow and functional testing. Couple things I have seen right away:

Index: process_bug.cgi
+    my (@alias_add, @alias_remove);
+    if (Bugzilla->params->{"usebugaliases"} && (defined $cgi->param('newalias')
+                                            || defined $cgi->param('removealias'))) {
+
+        my ($alias_add, $alias_remove) = "";
+        $alias_add = join(' ',$cgi->param('newalias'));
+        # We came from bug_form which uses a select box to determine what cc's
+        # need to be removed...
+        if (defined $cgi->param('removealias') && $cgi->param('alias')) {
+            $alias_remove = join (",", $cgi->param('alias'));
+        }
+    
+        push(@alias_add, split(/[\s,]+/, $alias_add)) if $alias_add;
+        push(@alias_remove, split(/[\s,]+/, $alias_remove)) if $alias_remove;
+
+        $first_bug->remove_alias($_) foreach @alias_remove;
+        $first_bug->add_alias($_) foreach @alias_add;

Nit-picks: 
1. Put my (@alias_add, @alias_remove) inside the if (Bugzilla->params->{"usebugaliases"}) block.
2. Change my ($alias_add, $alias_remove) to something else to not cause confusion with @alias_add and @alias_remove already declared.

Index: template/en/default/bug/edit.html.tmpl
+
+         [% PROCESS section_aliases %]
+
+         [% PROCESS section_spacer %]

          [% PROCESS section_spacer %]

Nit-pick: No need to add extra section_spacer.

Index: Bugzilla/Bug.pm
+# REDHAT EXTENSION START 481660
+sub add_alias {
+    my ($self, $alias) = @_;
+    return if !$alias;
+    my $bug_aliases = $self->alias;
+    push(@$bug_aliases, $alias) if !grep($_ eq $alias, @$bug_aliases);
+
+        use Data::Dumper;
+    my $NOTES_FILE = '/tmp/bug_alias3.log';
+    open my $notes, '>', $NOTES_FILE
+        or die "couldn't open $NOTES_FILE: $!";
+    print {$notes} Data::Dumper::Dumper( $bug_aliases  );
+    close $notes;
+}

Make sure you remove the debug lines before committing :)

More later.

Dave
Comment 7 David Lawrence 2009-02-12 16:48:12 EST
Comment on attachment 331568 [details]
v1 for having multiple aliases for a single bug

For some reason when one or more aliases are defined for a bug, when you load the show_bug.cgi page, the summary in the header is not properly set to read-only with the (edit) link to the right. It is expanded all the time showing the summary edit field.

Also when I have more than one alias defined, I only see one alias in the text next to Alias List:. Please list all aliased to the right of Alias List similar to partners, verified, etc.

Also make sure that the aliases are displayed in parentheses before the summary in the bug header. This may not be there because it incorrectly expanding to show the summary text field but please make sure.

Above could be related to these lines in edit.html.tmpl still referencing the old bugs.alias format:

[% IF Param("usebugaliases") && alias_in_title %]
        [% IF bug.alias != "" %]
          (<span id="alias_nonedit_display">[% bug.alias FILTER html %]</span>)
        [% END %]
      [% END %]

Also I think it would be better to call it Aliases: instead if Alias List:

When searching for bugs matching Alias1 or Alias2 fails though in buglist.cgi. So we need to make some changes in Bugzilla/Search.pm to work properly with the bugs_alias mapping table.
Comment 8 David Lawrence 2009-02-12 16:50:22 EST
(In reply to comment #7)
> (From update of attachment 331568 [details])
> For some reason when one or more aliases are defined for a bug, when you load
> the show_bug.cgi page, the summary in the header is not properly set to
> read-only with the (edit) link to the right. It is expanded all the time
> showing the summary edit field.
> 
> Also when I have more than one alias defined, I only see one alias in the text
> next to Alias List:. Please list all aliased to the right of Alias List similar
> to partners, verified, etc.
> 
> Also make sure that the aliases are displayed in parentheses before the summary
> in the bug header. This may not be there because it incorrectly expanding to
> show the summary text field but please make sure.

If we start to see bugs with insane amount of aliases we can re-work this but I suspect most people will only have a few set any given time.

mark, how many CVE's do you typically see for a single bug report?

Dave
Comment 9 David Lawrence 2009-02-12 22:53:28 EST
Also let's add the alias edit section on the left side column of the bug form as the right side is getting crowded already with all of the custom fields. Maybe under the bug status and above the product drop down.

Dave
Comment 10 Noura El hawary 2009-02-16 08:56:01 EST
Created attachment 332035 [details]
v2 for adding multiple aliases to a bug

Thanks for your review Dave, attached is a new patch with all your notes applies and fixed, the patch is now on bz-web2-test so you can use it for testing.

basically for the bug title section i have rewrote the whole section, i figured out it is easier to rewrite it better than playing with the existing code, and i have just renamed the old section and left it there so we can reuse it if needed to. changed the migration script to exclude creating tables and dropping columns. also done all the other changes you mentioned for the alias position.

Now one thing i haven't done yet is the search for alias1 or alias2 ,, basically the search works fine if you haven't used and/or operators in one advanced boolean chart, that is actually the same thing with dependson and blocks searches they have the same issue, I will need to investigate the problem a bit more. please take a look at the attached patch when you can and let me know what you think.

Thanks,
Noura
Comment 11 David Lawrence 2009-02-16 14:04:06 EST
Comment on attachment 332035 [details]
v2 for adding multiple aliases to a bug

>Index: enter_bug.cgi 
>     $vars->{'comment'}           = formvalue('comment');
>     $vars->{'commentprivacy'}    = formvalue('commentprivacy');
>+    
>+    # REDHAT EXTENSION BEGIN 481660
>+    $vars->{'alias'}         = formvalue('alias');
>+    # REDHAT EXTENSION END 481660
> 

Nit: remove whitespace between left and right values.

>Index: process_bug.cgi
>===================================================================
>RCS file: /cvs/qa/rh_bugzilla_3/process_bug.cgi,v
>retrieving revision 1.36
>diff -p -u -r1.36 process_bug.cgi
>--- process_bug.cgi	6 Feb 2009 21:22:08 -0000	1.36
>+++ process_bug.cgi	16 Feb 2009 13:30:08 -0000
>@@ -425,8 +425,23 @@ foreach my $b (@bug_objects) {
> if (defined $cgi->param('id')) {
>     # Since aliases are unique (like bug numbers), they can only be changed
>     # for one bug at a time.
>-    if (Bugzilla->params->{"usebugaliases"} && defined $cgi->param('alias')) {
>-        $first_bug->set_alias($cgi->param('alias'));
>+    if (Bugzilla->params->{"usebugaliases"} && (defined $cgi->param('newalias')
>+                                            || defined $cgi->param('removealias'))) {
>+
>+        my (@alias_add, @alias_remove);
>+        my ($new_aliases, $delete_aliases) = "";
>+        $new_aliases = join(' ',$cgi->param('newalias'));
>+        # We came from bug_form which uses a select box to determine what cc's
>+        # need to be removed...
>+        if (defined $cgi->param('removealias') && $cgi->param('alias')) {
>+            $delete_aliases = join (",", $cgi->param('alias'));
>+        }
>+    
>+        push(@alias_add, split(/[\s,]+/, $new_aliases)) if $new_aliases;
>+        push(@alias_remove, split(/[\s,]+/, $delete_aliases)) if $delete_aliases;
>+
>+        $first_bug->remove_alias($_) foreach @alias_remove;
>+        $first_bug->add_alias($_) foreach @alias_add;
>     }

Need to wrap the new code with REDHAT EXTENSION tags.

>Index: Bugzilla/Bug.pm
> 
>+    # REDHAT EXTENSION START 481660
>+    my $bug_aliases= delete $params->{alias};
>+    # REDHAT EXTENSION END 481660
>+

nit: add space before =

>Index: Bugzilla/BugMail.pm
>+        alias => Bugzilla->params->{'usebugaliases'} && ref $values{'alias'} ? join(" ",@{$values{'alias'}}) : "",

Nit: add space before @{$values{'alias'}}

>Index: template/en/default/bug/edit.html.tmpl
>+[%# REDHAT EXTENSION 481660, renamed the block so it doesn't get called at all %]
>+[% BLOCK section_title2 %]
>   [%# That's the main table, which contains all editable fields. %]
>   <div class="bz_alias_short_desc_container">

This part worries me. When we go to merge patches from upstream, it will cause issues. I would rather we 
try to keep one section_title and add our changes there.

I played around with this some on my own and am attaching a patch to show how I was able to make this work
for the section_title changes,

> [%############################################################################%]
>+[%# Block for ALISES                                                         #%]
>+[%############################################################################%]

>+          <span id="alias_edit_area_showhide_container" class="bz_default_hidden">
>+            (<a href="#" id="alias_edit_area_showhide">edit/more..</a>)

Nit-pick: Please just have (edit) to be consistent and also since you are now displaying
all aliases set anyway.

>+          </span>
>+          <br>
>+          <div id="alias_edit_area">
>+            <div>
>+              [% IF bug.check_can_change_field('alias', 0, 1) %]
>+              <div>
>+                <label for="aliases">
>+                  <b>Add</b>
>+                </label>
>+              </div>
>+                <input name="newalias" id="newalias" size="20">
>+              [% END %]
>+            </div>
>+            [% IF bug.alias %]
>+              <select id="alias" name="alias" multiple="multiple" size="5">
>+                [% FOREACH a = bug.alias %]
>+                  <option value="[% a FILTER html %]">[% a FILTER html %]</option>
>+                [% END %]
>+              </select>
>+              <br>
>+              [% IF bug.check_can_change_field('alias', 0, 1) %]
>+              <input type="checkbox" id="removealias" name="removealias">
>+              [%%]<label for="removecc">Remove selected aliases</label>

Please change "removecc" to "removealias" so clicking the label will check the correct check box.

Other than the things mentioned everything else seemed to work well. Please file a separate bug 
regarding the search issue when using AND/OR. Since we already have this problem with depends 
on and blocks, we can address all of them at the same time in the near future.

Good work
Dave
Comment 12 David Lawrence 2009-02-16 14:07:33 EST
Created attachment 332085 [details]
Patch demonstrating unified section_title in edit.html.tmpl (dkl)

Attaching a version of your patch that has changes in the section_title BLOCK in edit.html.tmpl which will hopefully still allow us to benefit from upstream changes to that same section.

Dave
Comment 13 Noura El hawary 2009-02-17 07:28:38 EST
Created attachment 332211 [details]
v4 for adding multiple aliases to a single bug

Hey Dave, 

Thanks for your review, attached is a patch that includes your changes to section_title and all your other review notes also i figured out i have forgotten about the xmlrpc interface and making it handle the new alias feature, i have updated the xmlrpc functions accordingly, all included in the patch, please review and let me know what you think.

Thanks,
Noura
Comment 14 David Lawrence 2009-02-17 17:28:17 EST
Comment on attachment 332211 [details]
v4 for adding multiple aliases to a single bug

>Index: Bugzilla/WebService/Bug.pm
>@@ -852,8 +852,9 @@ sub update {
>-            if (Bugzilla->params->{"usebugaliases"} && defined $updates->{alias}) {
>-                $args->{alias} = $updates->{alias};
>+            if (Bugzilla->params->{"usebugaliases"}) {
>+                $args->{add_alias}    = $updates->{add_alias};
>+                $args->{remove_alias} = $updates->{delete_alias};
>             }

Please make this take a scalar or list. Leave the POD docs saying that we require
lists but I would rather it do the conversion than die with an array reference code error.

                $args->{add_alias}    = ref $updates->{add_alias} ? $updates->{add_alias} : [$updates->{add_alias}];
                $args->{remove_alias} = ref $updates->{delete_alias} ? $updates->{delete_alias} : [$updates->{delete_alias}];

Everything else looks good and worked as expected. Once you fix this, then check it in.

Dave
Comment 15 Noura El hawary 2009-02-17 23:30:45 EST
Thanks for the review Dave , Patch has been committed to cvs with the fix you suggested, now i am going to list here what we will need to do at the time of the next package push to make sure this patch works fine:

1- maybe we need to disable bugzilla for a short time just to be safe.

2- install the new bugzilla package rpm

3- create new bugs_aliases table by getting sys admins to run the following:
# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_add_table('bugs_aliases');"

4- get the sys admins to run the redhat/migrate_bugs_aliases.pl script

5- drop bugs.alias table by getting sys admins to run:
# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_drop_column('bugs',
'alias');

5- send to sys admins the file script to create new mysql function AliasList()
and ask them to run it on live database.

6- put bugzilla up again.

What do you think Dave, is there anything missing, if all sounds good then i can send an email to sys-admins with all the information they need and attach the scripts they will need to run. Also will make sure to be around at migration time. shall we agree on a time?

Thanks,
Noura
Comment 16 David Lawrence 2009-02-17 23:51:50 EST
I think the following order may be better as there will be less chance of someone getting any errors during the changeover and we can keep Bugzilla going during.

1- send to sys admins the file script to create new mysql function AliasList()
and ask them to run it on live database.

2- create new bugs_aliases table by getting sys admins to run the following:
# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_add_table('bugs_aliases');"

3- install the new bugzilla package rpm

4- get the sys admins to run the redhat/migrate_bugs_aliases.pl script

5- drop bugs.alias table by getting sys admins to run:
# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_drop_column('bugs',
'alias');

We could do it on thursday for the normal update time. You could create the email with the directions and attachments and send it out for the admins to receive
when they come in Thursday AM EST. Then I will be around if anything comes up and
you can check in if you want as well.

Dave
Comment 17 Noura El hawary 2009-02-17 23:58:34 EST
(In reply to comment #16)
> I think the following order may be better as there will be less chance of
> someone getting any errors during the changeover and we can keep Bugzilla going
> during.
> 
> 1- send to sys admins the file script to create new mysql function AliasList()
> and ask them to run it on live database.

Dave, I think we should move this step after step no 2, as the function depends on the new table bugs_aliases, right? or can we still run it without the table there?

the rest of the ordering sounds good to me.

Thanks,
Noura

> 
> 2- create new bugs_aliases table by getting sys admins to run the following:
> # perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_add_table('bugs_aliases');"
> 
> 3- install the new bugzilla package rpm
> 
> 4- get the sys admins to run the redhat/migrate_bugs_aliases.pl script
> 
> 5- drop bugs.alias table by getting sys admins to run:
> # perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_drop_column('bugs',
> 'alias');
> 
> We could do it on thursday for the normal update time. You could create the
> email with the directions and attachments and send it out for the admins to
> receive
> when they come in Thursday AM EST. Then I will be around if anything comes up
> and
> you can check in if you want as well.
> 
> Dave
Comment 18 Noura El hawary 2009-02-18 00:05:30 EST
(In reply to comment #17)
> (In reply to comment #16)
> > I think the following order may be better as there will be less chance of
> > someone getting any errors during the changeover and we can keep Bugzilla going
> > during.
> > 
> > 1- send to sys admins the file script to create new mysql function AliasList()
> > and ask them to run it on live database.
> 
> Dave, I think we should move this step after step no 2, as the function depends
> on the new table bugs_aliases, right? or can we still run it without the table
> there?
> 
> the rest of the ordering sounds good to me.
> 
> Thanks,
> Noura
> 
> > 
> > 2- create new bugs_aliases table by getting sys admins to run the following:
> > # perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_add_table('bugs_aliases');"
> > 

hmm actually we can not do the above either until we have the new bugzilla package because it contains the table definition for the new table bugs_aliases so i guess the first thing we will have to do is to install the rpm.

Noura


> > 3- install the new bugzilla package rpm
> > 
> > 4- get the sys admins to run the redhat/migrate_bugs_aliases.pl script
> > 
> > 5- drop bugs.alias table by getting sys admins to run:
> > # perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_drop_column('bugs',
> > 'alias');
> > 
> > We could do it on thursday for the normal update time. You could create the
> > email with the directions and attachments and send it out for the admins to
> > receive
> > when they come in Thursday AM EST. Then I will be around if anything comes up
> > and
> > you can check in if you want as well.
> > 
> > Dave
Comment 19 David Lawrence 2009-02-18 11:35:07 EST
(In reply to comment #17, #18)
> > I think the following order may be better as there will be less chance of
> > someone getting any errors during the changeover and we can keep Bugzilla going
> > during.
> > 
> > 1- send to sys admins the file script to create new mysql function AliasList()
> > and ask them to run it on live database.
> 
> Dave, I think we should move this step after step no 2, as the function depends
> on the new table bugs_aliases, right? or can we still run it without the table
> there?
> 
> the rest of the ordering sounds good to me.

I tested on bz-db1-test and long as no code tries to access AliasList() before the bugs_aliases table is created then this is not an issue.

> hmm actually we can not do the above either until we have the new bugzilla
> package because it contains the table definition for the new table bugs_aliases
> so i guess the first thing we will have to do is to install the rpm.

You are right. So I think we will need to have sysadmin put up the Bugzilla outage message temporarily while we do this update. Time should be minimal.

So the new order should be:

1- Admin update data/params to add message to 'shutdownhtml' stating that Bugzilla is down temporarily for maintenance (cfengine).

2- send to sys admins the file script to create new mysql function AliasList()
and ask them to run it on live database.

3- install the new bugzilla package rpm

4- create new bugs_aliases table by getting sys admins to run the following in the bugzilla document root:

# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_add_table('bugs_aliases');"

5- get the sys admins to run the redhat/migrate_bugs_aliases.pl script from Bugzilla document root.

# perl -we -I. redhat/migrate_bugs_aliases.pl > /tmp/migrate_bugs_aliases.pl 2>&1

6- Empty out 'shutdownhtml' in data/params (cfengine).

7- Email /tmp/migrate_bugs_aliases.pl to bugzilla-owner@redhat.com.

8- Allow bugzilla admin to verify new aliases are displaying properly.

9- drop bugs.alias table by getting sys admins to run in Bugzilla document root:

# perl -we -I. "use Bugzilla; Bugzilla->dbh->bz_drop_column('bugs','alias');

Dave
Comment 20 Tomas Hoger 2009-02-23 09:00:40 EST
This change seems to create a regression at least in bugzilla.createBug (and probably other bug creating APIs).  According to the docs:
https://bugzilla.redhat.com/docs/en/html/api/extensions/compat_xmlrpc/code/webservice.html

alias was originally expected to be passed as string, while now it seems that array references is expected:
  Can't use string ("CVE-XXXX-YYYY") as an ARRAY ref while "strict refs" in
  use at Bugzilla/Bug.pm line 507.

Scripts that previously used to do:
  'alias' => $alias

now need to be changed to:
  'alias' => [ $alias ]

For the sake of backwards compatibility, it may be a good idea to handle this on the server side, so that BZ checks if value provided is array reference or scalar.  If it's scalar, BZ should do [ $alias ] for user.
Comment 21 David Lawrence 2009-02-23 13:00:04 EST
(In reply to comment #20)
> This change seems to create a regression at least in bugzilla.createBug (and
> probably other bug creating APIs).  According to the docs:
> https://bugzilla.redhat.com/docs/en/html/api/extensions/compat_xmlrpc/code/webservice.html
> 
> alias was originally expected to be passed as string, while now it seems that
> array references is expected:
>   Can't use string ("CVE-XXXX-YYYY") as an ARRAY ref while "strict refs" in
>   use at Bugzilla/Bug.pm line 507.
> 
> Scripts that previously used to do:
>   'alias' => $alias
> 
> now need to be changed to:
>   'alias' => [ $alias ]
> 
> For the sake of backwards compatibility, it may be a good idea to handle this
> on the server side, so that BZ checks if value provided is array reference or
> scalar.  If it's scalar, BZ should do [ $alias ] for user.

Fix committed to CVS and will be in the next update.

Dave

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