#1074 Urgency dropdown in portal generates debug trace

[Simon Wahlgren]

Hello,

FYI. Choosing an Urgency when creating an user request in the portal gives the following debug trace:

"No result for the single row query: 'SELECT DISTINCT Service_service.id AS Serviceid, Service_service.name AS Servicename, Service_service.org_id AS Serviceorg_id, Organization_org_id_organization.name AS Serviceorganization_name, Service_service.servicefamily_id AS Serviceservicefamily_id, ServiceFamily_servicefamily_id_servicefamilly.name AS Serviceservicefamily_name, Service_service.description AS Servicedescription, Service_service.status AS Servicestatus, CAST(CONCAT(COALESCE(Service_service.name, '')) AS CHAR) AS Servicefriendlyname, CAST(CONCAT(COALESCE(Organization_org_id_organization.name, '')) AS CHAR) AS Serviceorg_id_friendlyname, CAST(CONCAT(COALESCE(ServiceFamily_servicefamily_id_servicefamilly.name, '')) AS CHAR) AS Serviceservicefamily_id_friendlyname FROM service AS Service_serviceINNER JOIN (organization AS Organization_org_id_organization ) ON Service_service.org_id = Organization_org_id_organization.idLEFT JOIN (servicefamilly AS ServiceFamily_servicefamily_id_servicefamilly ) ON Service_service.servicefamily_id = ServiceFamily_servicefamily_id_servicefamilly.id WHERE ((Service_service.id = '1') AND (Service_service.org_id IN ('2'))) '
Debug trace:

0 /home/vagrant/aranya-itop/core/metamodel.class.php(5088): MetaModel::MakeSingleRow('Service', '1', true, false, NULL)
1 /home/vagrant/aranya-itop/application/wizardhelper.class.inc.php(116): MetaModel::GetObject('Service', '1')
2 /home/vagrant/aranya-itop/pages/ajax.render.php(560): WizardHelper->GetTargetObject()
3 {main}"

Best regards,
Simon

[Denis]

To be investigated...

[Stephen]

Hello,

I have exactly the same issue. Meanwhile, is it possible to disable this debug trace for our customers ?

Best regards,

Stephen

[maxhq]

As a workaround, the attached file will disable any error output in the user portal.
Copy it anywhere and then execute:

patch -p0 --backup -V simple --forward --directory /var/www/itop --reject-file=- < pages_ajax.render.php.patch

[seemax1991]

Exact same issue here.
Gonna try max's workaround.
EDIT: Workaround works!

[Romain Quetiez]

First part of the fix: the debug trace has been removed from the output. Committed (some time ago, by Denis) in trunk as [r3606] and in branch 2.1.0 as [r3589].

To reproduce:
1) Install with default options (simple tickets)
2) Create user with the profile "User Portal", the contact "Claude Monet" and allow the organization "Demo"
3) Logoff / Login to the portal
4) New user request (Computer & peripherals, New desktop ordering)
5) Select a value in ANY of the dropdowns (impact or urgency)

Notes:

• It is a must to restrict the allowed organization, otherwise it does not produces any error
• The ticket gets created correctly in the end

[Romain Quetiez]

Root cause:
The design of the portal relies on the use of 'Allow all data' flags on the queries, making it possible to view the services owned by a company which is not allowed for the current (portal) user.
But, the GUI uses the standard ajax service 'ajax.render.php?operation=wizard_helper' which does attempt a GetObject on each external key so as to update the corresponding external fields.

The fix consists in letting the wizard helper be in a degraded mode (external fields not always set) when the current user cannot fetch the objects corresponding to the external keys. I could not see the real consequences of that.

Committed in trunk as [r3686]

Requires further testing (with customized portals) before an eventual retrofit to older versions of iTop.