[SOLVED] Search not working with 1.9.1

[jbullitt]

Trying to debug why our searches are not working. I would like to try and find a solution without needing to upload our db to mantis if that is possible. Keeping test cases in house is a concern with my higher ups (not my choice), so I am trying to do this myself and would love any help.

History of upgrade path.
upgraded from 1.7.4 -> 1.8.5 -> 1.9.0 -> 1.9.1 (was hoping that 1.9.1 would catch my issue)

Search from the quick search or the Search Test Cases return no results or an actual number of matches (an example would be 10 matches) and report "Too many results. Please, set a more specific criteria."

Here is what I have so far. I do a search from "Search Test Cases" and only search on the Test Case ID (PVNG8678). Where PVNG is the test case ID prefix for the test project that the test case is in. Search test cases - Number of matches : 0. I am able to go to the Navigator for the specifications and drill down to the specific test case. The test case does exist. We can execute edit, delete, all that good stuff. The search is also the same when searching with out the prefix.

I can go to mysql and run a query on what is in the summary for PVNG8678
SELECT * FROM `tl_09`.`tcversions` WHERE summary = '<p>exercise file transfer service from OBC to backend</p>';
and find the following:
id 8679
version 1
summary <p>exercise file transfer service from OBC to backend</p>
importance 2
author_id 32
creation_ts 1/7/2010 12:38
updater_id NULL
modification_ts 0000-00-00 00:00:00
active 1
is_open 1
execution_type 1
tc_external_id 8678
layout 1
status 1
preconditions NULL

So the table tcversions the field tc_external_id matches the 8678 number with out the prefix. But I don't know where to go from here. Basically I have proven that the test case is there and I can query it from mysql.

Help please? If my terminology is incorrect please correct me. Kind of stuck and any help is appreciated. Is there anything more that I can do on my end? I am guessing yes?
We do have two Test Projects but the correct test project (the one where the test case is located) is chosen.

[jbullitt]

So I did a little more digging. When I search using just the numbers without the prefix, what is being sent by tcSearch.php is the following, which seems correct.

keyword_id =0
version =0
custom_field_id =0
name =
summary =
steps =
expected_results =
custom_field_value =
targetTestCase ='PVNG8678'
preconditions =
requirement_doc_id =
importance =0
creation_date_from =
creation_date_to =
modification_date_from =
modification_date_to =
userID =66
tprojectID =1

So I started looking at what was going on with tcSearch.php. It is here where I think things are going wrong.
if($args->targetTestCase != "" && strcmp($args->targetTestCase,$gui->tcasePrefix) != 0)
{
if (strpos($args->targetTestCase,$tcase_cfg->glue_character) === false)
{
$args->targetTestCase = $gui->tcasePrefix . $args->targetTestCase;
Fb::log($args, "args->targetTestCase");

***** targetTestCase in args is = 'PVNG8678'*****

}

$tcase_mgr = new testcase ($db);
Fb::log($tcase_mgr, "tcase_mgr"); ***** way to much stuff in here for me '*****
$tcaseID = $tcase_mgr->getInternalID($args->targetTestCase,$tcase_cfg->glue_character);
Fb::log($args, "targetTestCase"); ***** targetTestCase in args is = 'PVNG8678'*****
Fb::log($tcase_cfg, "glue_character"); ***** glue_character is = can_edit_executed = 1 *****
Fb::log($tcaseID, "tcase_mgr->getInternalID"); **** $tcaseID is = 0 *****
$filter['by_tc_id'] = " AND NH_TCV.parent_id = {$tcaseID} ";
}

It looks like $tcaseID needs to be resolved to the id field in the table tcversions? My php really sucks so I am not sure.

[jbullitt]

Wanting to see the differences in a clean db's data and our db I took the time to set up a machine and do a clean install of 1.9.1. I was able to get this to happen with a clean install of 1.9.1. I must be missing something because the search is just not working for me. The db in mantis: http://mantis.testlink.org/view.php?id=4165

[Matt]

Search isn't working for me either, I've got a test db with around 300 cases in it, the search just refuses to display a list of test cases it has found, or worse still finds a woefully incorrect amount (finding 16 test cases when I search via hardcoded test case ID).

[fman]

Please give use detailed steps to reproduce on mantis issue.
Without this info dev team can not work

[jbullitt]

Search isn't working for me either, I've got a test db with around 300 cases in it, the search just refuses to display a list of test cases it has found, or worse still finds a woefully incorrect amount (finding 16 test cases when I search via hardcoded test case ID).

Well I am glad it is not just us. Thanks matt for commenting. I to tried to hard code the id with no luck as well.

[jbullitt]

I finally figured out what the issue was with our search.

In our custom_config.inc.php file, the following setting was causing our search to not work:
$g_testcase_cfg->can_edit_executed=1; This setting was a valid setting in Testlink 1.7.4 and following best practices it was in our custom_config.inc.php file. However, this changed in 1.8.

The current correct setting in that should have been in 1.8's custom_config.inc.php is as follows:
$tlCfg->testcase_cfg->can_edit_executed=ENABLED; (or DISABLED depending)

$g_testcase_cfg->can_edit_executed=1 was the correct way to do this in Testlink 1.7.4. I did not see any notes or anything about this change going forward from 1.7 to 1.8. In our case we transitioned from 1.7->1.8->1.9. Immediate jumping from 1.7->1.8->1.9 as well as that can_edit_executed was so darn close to what it should have been, caused us pain.

Hopefully someone else having the same issue might find this post and save some time and headache.

@fman: Would have updated the bug but it is closed and did not want to open it again. If you would like for me to update it let me know.

[fman]

Please reopen issue and update with this info.
sorry for problems (dammed defines!)

[jbullitt]

Added info to bug and reopened. No worries on the issue. Just want to thank you for looking into it. Personally, I was just happy to have pin pointed the issue. We have three test link servers running and two of them have around 3000+ test cases. Not having the search working was killing me/us.

[fman]

ok thanks for adding info to mantis
As you have seen due to amount of config combination, sometimes no matter how hard we work we are not able to reproduce.
That's why we ask people again and again:
add more details
give us your db
and so on