367502 - Error when attempting to modify "Attributes" of case or plan

Status: RESOLVED WORKSFORME

(Testopia :: Cloning, defect)

Description

[IgnoreMe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Bugzilla 2.22.1 and Testopia version 1.1.2

When I attempt to commit a cloned test case I receive this error
message in my browser.

Software error:

DBD::mysql::db do failed: Column 'fieldid' cannot be null at
Bugzilla/Testopia/TestCase.pm line 868
        Bugzilla::Testopia::TestCase::update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)',
'HASH(0x8ea6478)') called at /usr/share/bugzilla/tr_show_case.cgi line
381
        main::do_update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)') called
at /usr/share/bugzilla/tr_show_case.cgi line 193

For help, please send mail to the webmaster (*@*.*), giving this error
message and the time and date of the error.

Basically I create a case and commit it to the plan and that works
fine.  I then click on the clone button on that case and it goes to the
next page asking me how I would like to clone it, I just use the
defaults and hit submit, and It goes through that process as well.  I
am then taken to the cloned test case, which I then modify a view
fields and then commit, and that is when I get the error.

If I open up the plan and view the selected cases I see the case that I
just modified and got the error from and it has all my changes.

Here are the logs from apache when I hit the commit button and get the
error

[Wed Jan 17 13:36:06 2007] [error] [client 10.10.10.17] [Wed Jan 17
13:36:06 2007] tr_show_case.cgi: DBD::mysql::db do failed: Column
'fieldid' cannot be null at Bugzilla/Testopia/TestCase.pm line 868,
referer: https://bugzillaserver/tr_show_case.cgi
[Wed Jan 17 13:36:06 2007] [error] [client 10.10.10.17] [Wed Jan 17
13:36:06 2007] tr_show_case.cgi:
\tBugzilla::Testopia::TestCase::update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)',
'HASH(0x8ea6478)') called at /usr/share/bugzilla/tr_show_case.cgi line
381, referer: https://bugzillaserver/tr_show_case.cgi
[Wed Jan 17 13:36:06 2007] [error] [client 10.10.10.17] [Wed Jan 17
13:36:06 2007] tr_show_case.cgi:
\tmain::do_update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)')
called at /usr/share/bugzilla/tr_show_case.cgi line 193, referer:
https://bugzillaserver/tr_show_case.cgi

Reproducible: Always

Steps to Reproduce:
1.  Create a case and commit it to a plan.
2.  Click on the clone button on that case.
3.  Use the clone defaults and hit submit.
4.  Modify a few fields and then commit the case.
Actual Results:  
Receive error message.

Software error:

DBD::mysql::db do failed: Column 'fieldid' cannot be null at
Bugzilla/Testopia/TestCase.pm line 868
        Bugzilla::Testopia::TestCase::update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)',
'HASH(0x8ea6478)') called at /usr/share/bugzilla/tr_show_case.cgi line
381
        main::do_update('Bugzilla::Testopia::TestCase=HASH(0x90bd194)') called
at /usr/share/bugzilla/tr_show_case.cgi line 193

Expected Results:  
Should be able to properly commit this cloned case

Comment 1

[Greg Hendricks]

Are you able to update other test cases (not cloned ones)?
Can you describe the steps you took right before seeing this message? 
Was this a newly cloned test case? How did you clone it? 
(There are several places from which you can clone a test case).

Comment 2

[Greg Hendricks]

Ah, I missed your "Steps to reproduce"

Still, I am not able to reproduce this. Which fields exactly did you modify?

Comment 3

[IgnoreMe]

Excellent questions, I was working on getting the information you requested, and I found that this has nothing to do with cloning.  I just happened to assume it was since that was the only time I received the error.

I was able to find that when I attempt to modify any of the following on an already existing case Summary, Default, Tester, Alias, Status, Priority, Requirement, Automatic, Script, Arguments.  I receive the error, and the case is modified with my changes.

If I modify any other field's then the ones listed above the case is modified and all is well.

Comment 4

[IgnoreMe]

Was creating a new case today, and I messed up on the name.  I attempted to change the name, and got the error on submit as well.  So it looks like this issue isn't confined to just test cases.  On the plan's it happens if I change any of the Attributes.  If I change other things on the plan it works without the error.  Modified the summary to reflect this.

Comment 5

[Greg Hendricks]

Can you verify the contents of the test_fieddefs table on your installation. The error you are reporting seems to indicate missing entries in that table. 

Mine looks like:

+---------+-------------------------+-------------------------+------------+
| fieldid | name                    | description             | table_name |
+---------+-------------------------+-------------------------+------------+
|       1 | isactive                | Archived                | test_plans |
|       2 | name                    | Plan Name               | test_plans |
|       3 | type_id                 | Plan Type               | test_plans |
|       4 | case_status_id          | Case Status             | test_cases |
|       5 | category_id             | Category                | test_cases |
|       6 | priority_id             | Priority                | test_cases |
|       7 | summary                 | Run Summary             | test_cases |
|       8 | isautomated             | Automated               | test_cases |
|       9 | alias                   | Alias                   | test_cases |
|      10 | requirement             | Requirement             | test_cases |
|      11 | script                  | Script                  | test_cases |
|      12 | arguments               | Argument                | test_cases |
|      13 | product_id              | Product                 | test_plans |
|      14 | default_product_version | Default Product Version | test_plans |
|      15 | environment_id          | Environment             | test_runs  |
|      16 | product_version         | Product Version         | test_runs  |
|      17 | build_id                | Default Build           | test_runs  |
|      18 | plan_text_version       | Plan Text Version       | test_runs  |
|      19 | manager_id              | Manager                 | test_runs  |
|      20 | default_tester_id       | Default Tester          | test_cases |
|      21 | stop_date               | Stop Date               | test_runs  |
|      22 | summary                 | Run Summary             | test_runs  |
|      23 | notes                   | Notes                   | test_runs  |
+---------+-------------------------+-------------------------+------------+

Comment 6

[IgnoreMe]

It looks like we have nothing in that table.  It's starting to look like that is the issue :)  Do you have any suggestions as to how it can be fixed?  I also find it interesting that data is actually being changed wouldn't it just fail completely if this data was missing?

Comment 7

[Greg Hendricks]

This table is used when storing history of changes, not the changes themselves. That is why your changes are still being applied

These values should have been inserted when you ran tr_install. To get the values you can maually run the testopia.insert.sql script located in the testopia directory. 

mysql -u [user] -p [bugzilla_db] </path/to/bugzilla/testopia/testopia.insert.sql

Did you get any errors while installing Testopia?

Comment 8

[IgnoreMe]

When installing Testopia we did not receive any errors.  We attempted to run the command manually and received this error.

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (2, ' at line 2 

Comment 9

[IgnoreMe]

Attachment: The file that we are attempting to import

Here is the file that we have that we are attempting to import.

Comment 10

[IgnoreMe]

The DB version that we are running is MySQL Distribution 5.0.20 Version 14.12

Comment 11

[IgnoreMe]

We fixed the syntax and inserted in the items that were missing within two separate tables.  I know longer have this problem.

Comment 12

[Vance Baarda]

So should we close this bug, or does Testopia need a fix of some sort?

Comment 13

[IgnoreMe]

By running the command

mysql -u [user] -p [bugzilla_db]
</path/to/bugzilla/testopia/testopia.insert.sql

We got syntax errors.  So we put the ;'s at the end of the lines.  Tried again and got ERROR 1062 (23000) at line 1: Duplicate entry '1' for key 1.

So then we looked into it more and saw that the file was doing inserts within 4 different tables.

These were already in our DB

INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (1, 'IDLE', 1)
INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (2, 'PASSED', 2)
INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (3, 'FAILED', 3)
INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (4, 'RUNNING', 4)
INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (5, 'PAUSED', 5)
INSERT INTO test_case_run_status (case_run_status_id, name, sortkey) VALUES (6, 'BLOCKED', 6)

These were already in our DB

INSERT INTO test_case_status (case_status_id, name) VALUES (1, 'PROPOSED')
INSERT INTO test_case_status (case_status_id, name) VALUES (2, 'CONFIRMED')
INSERT INTO test_case_status (case_status_id, name) VALUES (3, 'DISABLED')

This was in our DB but with the incorrect value so we changed it to the correct one that was listed in the file.

INSERT INTO test_plan_types (type_id, name) VALUES (1, 'Unit')

These were not in our DB and needed to be added

INSERT INTO test_plan_types (type_id, name) VALUES (2, 'Integration')
INSERT INTO test_plan_types (type_id, name) VALUES (3, 'Function')
INSERT INTO test_plan_types (type_id, name) VALUES (4, 'System')
INSERT INTO test_plan_types (type_id, name) VALUES (5, 'Acceptance')
INSERT INTO test_plan_types (type_id, name) VALUES (6, 'Installation')
INSERT INTO test_plan_types (type_id, name) VALUES (7, 'Performance')
INSERT INTO test_plan_types (type_id, name) VALUES (8, 'Product')
INSERT INTO test_plan_types (type_id, name) VALUES (9, 'Interoperability')

These were not in our DB and needed to be added

INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (1, 'isactive', 'Archived', 'test_plans')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (2, 'name', 'Plan Name', 'test_plans')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (3, 'type_id', 'Plan Type', 'test_plans')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (4, 'case_status_id', 'Case Status', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (5, 'category_id', 'Category', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (6, 'priority_id', 'Priority', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (7, 'summary', 'Run Summary', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (8, 'isautomated', 'Automated', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (9, 'alias', 'Alias', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (10, 'requirement', 'Requirement', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (11, 'script', 'Script', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (12, 'arguments', 'Argument', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (13, 'product_id', 'Product', 'test_plans')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (14, 'default_product_version', 'Default Product Version', 'test_plans')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (15, 'environment_id', 'Environment', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (16, 'product_version', 'Product Version', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (17, 'build_id', 'Default Build', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (18, 'plan_text_version', 'Plan Text Version', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (19, 'manager_id', 'Manager', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (20, 'default_tester_id', 'Default Tester', 'test_cases')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (21, 'stop_date', 'Stop Date', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (22, 'summary', 'Run Summary', 'test_runs')
INSERT INTO test_fielddefs (fieldid, name, description, table_name) VALUES (23, 'notes', 'Notes', 'test_runs')

Some of these items didn't make it in, one did, but it was incorrect somehow, and some items made it in correctly.  The files syntax was an issue for us as well, maybe this worked on other DB's but we couldn't see how it could.  Maybe its how it's called with the .pl's that we run at setup, I am not sure.

Comment 14

[Vance Baarda]

Here's the code in tr_install.pl that handles this:

    open FH, "< testopia/testopia.insert.sql" or die;
    $dbh->do($_) while (<FH>);
    close FH;

That is, testopia.insert.sql was not designed to be called directly by the mysql command.

I'm closing this bug since we can't recreate the problem. You can reopen it if you want, if you can figure out how tr_install.pl ran through part of testopia.insert.sql but not the whole thing.