Area missing

[Monkzzz]

Hello to everyone!
We haven't notes/description section in 1.9.17 version. How we can switch it back?
Thanks in advance!

[fman]

the .htaccess files can be blocking js loading for web rich editor.
configure it in the right way or remove it.

[Monkzzz]

Thanks for Your answer, but we use nginx.

[Monkzzz]

In another words - we havnt Notes/Description and Result (with radio buttons, Save execution, Save and move to next) areas

[fman]

get bitnami installer, do fresh install and retest.
you will be able to compare configurations

[ScriptHappy]

tl:dr; there is a bug for admins in non-public projects in the version 1.9.17 preventing the display of test cast execution controls and thus prevents the test case execution for that user. The workaround is to use a tester (I'm new to testlink) http://mantis.testlink.org/view.php?id=8475

Thank you for the idea about investigating .htaccess using the bitnami instance. I too have this problem, and was able to use your tip to confirm that .htaccess is not a part of the problem.

The main reason is that these controls are not lazily loaded by the browser, but are included in the php templating engine. When you debug the http response of execSetResults.php, the controls are already missing and no code attempts to load them.

To investigate this, I dived into the following server-side executed files:

• lib/execute/execSetResults.php - the actual php code being called server side to generate the detailed execution view of the test case. (That is, the right half of the screenshot in the above bug report.)
• gui/templates/execute/execSetResults.tpl - the view template of the php page.
• gui/templates/execute/inc_exec_show_tc_exec.tpl - an included template in the main template. I find the name demonstrates it's expected responsibility, it "shows the test case execution"

In the last/inner-most template I mentioned is a conditional guard which determines if the actual controls should be displayed or not. This logic pulls in various things, but at a hight level it boils down to evaluating if you (the user) are permitted to run this test case. I debugged the code and found the chain of logic starts evaluating to "false" (not allowed) in the middle of an assertion of user roles - the admin I'm logged in to does not have any project specific permissions to be evaluated, so the code runs into an else and falls back on the evaluation if the project is public. It isn't, so the control is never displayed.

I did not observe this behaviour out of the box - after identifying the problem, I confirmed my default "admin" user could run the tests, but after switch users one more time (to my personal admin account and back), even this user could not run the tests.

Edit: fixing grammar and clarity.