0000350: Open incident via portal gives an eval error

(0000372)
ivan (administrator)
2008-12-23 09:49

Which version?

Is this with the default set of triggers? If not you'll need to say what your exact trigger settings are, including your trigger rule.

(0000374)
paulh (administrator)
2008-12-23 19:23

Latest trunk (so 3.45) (as of last night) I've not touched the triggers so its the default set

(0000384)
paulh (administrator)
2008-12-24 17:16

just wiped my db and created a new one and still get the error so definetly using latest set of triggers

(0000725)
ivan (administrator)
2009-03-05 13:53

Is this still an issue with 3.45?

(0000740)
paulh (administrator)
2009-03-06 20:07

Unfortunatly yes, the user error is slightly more friendly now though:

Application Warning [512]
Error in trigger rule for TRIGGER_INCIDENT_CREATED, check your trigger rules. in /home/paulh/sit/lib/triggers.inc.php @ line 110
Backtrace:
/home/paulh/sit/lib/triggers.inc.php @ line 110 trigger_error()
/home/paulh/sit/portal/add.php @ line 232 trigger()

(0000756)
ivan (administrator)
2009-03-07 15:25

thanks

(0000796)
timfederwitz (reporter)
2009-03-23 19:59

Could this be what's causing new incidents to never be automatically assigned to an available engineer? Or would that be a separate bug? Currently, on my brand new install, new incidents never get auto assigned.

(0001033)
blowagie (reporter)
2009-05-08 17:33

You can solve this problem by changing line number 232 in portal/add.php

Replace:
trigger('TRIGGER_INCIDENT_CREATED', array('incidentid' => $incidentid));
with:
trigger('TRIGGER_INCIDENT_CREATED', array('incidentid' => $incidentid, 'sendemail' => 1));

If you don't, the eval fails because {sendemail} is removed (replaced by nothing).
You end up with "$value = == 1" instead of "$value = 1 == 1".

(0001052)
paulh (administrator)
2009-05-14 19:31

Thanks for the feedback blowagie, I think this is because we have:

Rules: {sendemail} == 1.

On the trigger though sendemail isn't a required field according to the trigger definition perhaps it should be. Kieran/Ivan can you clarify?

(0001078)
ivan (administrator)
2009-05-19 16:48

Thanks blowagie (again)!

Although this isn't a required parameter, parameters don't have default values at the moment, so it does end up blank as you point out. I'll log a seperate bug about this, we need to either provide defaults for some parameters or make the trigger rules a bit more intelligent.

Added your patch in trunk svn r5390

(0001207)
kieran (administrator)
2009-06-13 14:04

This is the case that the trigger parameters (rather than rules) should be used, but there's no UI for it! In this case, you'd add {sendemail} == 0 to the parameter as you don't want to send an initial email if the user is logging it as a portal incident.

(0001290)
kieran (administrator)
2009-07-11 14:55

Resolved by Ivan in svn trunk r5390. Bug for proper solution reported as 0000760.

(0001664)
ivan (administrator)
2009-08-16 14:39

Released in 3.50rc1

Issue History
Date Modified	Username	Field	Change
2008-12-22 12:11	paulh	New Issue
2008-12-23 09:49	ivan	Note Added: 0000372
2008-12-23 09:49	ivan	Assigned To	=> paulh
2008-12-23 09:49	ivan	Status	new => feedback
2008-12-23 19:23	paulh	Note Added: 0000374
2008-12-23 19:23	paulh	Assigned To	paulh =>
2008-12-23 19:23	paulh	Status	feedback => new
2008-12-24 17:16	paulh	Note Added: 0000384
2009-03-05 13:53	ivan	Note Added: 0000725
2009-03-05 13:53	ivan	Status	new => feedback
2009-03-06 20:07	paulh	Note Added: 0000740
2009-03-06 20:07	paulh	Status	feedback => new
2009-03-07 15:25	ivan	Note Added: 0000756
2009-03-07 15:25	ivan	Status	new => confirmed
2009-03-07 15:25	ivan	Target Version	=> 3.50
2009-03-23 19:59	timfederwitz	Note Added: 0000796
2009-05-08 17:33	blowagie	Note Added: 0001033
2009-05-14 19:31	paulh	Note Added: 0001052
2009-05-14 19:39	paulh	Relationship added	has duplicate 0000685
2009-05-19 14:50	ivan	Status	confirmed => assigned
2009-05-19 14:50	ivan	Assigned To	=> ivan
2009-05-19 16:48	ivan	Note Added: 0001078
2009-05-19 16:54	ivan	Relationship added	child of 0000704
2009-06-13 14:04	kieran	Note Added: 0001207
2009-07-11 14:54	kieran	Relationship added	related to 0000769
2009-07-11 14:55	kieran	Note Added: 0001290
2009-07-11 14:55	kieran	Status	assigned => resolved
2009-07-11 14:55	kieran	Fixed in Version	=> Current SVN
2009-07-11 14:55	kieran	Resolution	open => fixed
2009-07-11 14:57	ivan	Relationship added	related to 0000760
2009-07-11 14:58	ivan	Relationship deleted	related to 0000760
2009-08-16 13:16	ivan	Fixed in Version	Current SVN => 3.50
2009-08-16 14:39	ivan	Note Added: 0001664
2009-08-16 14:39	ivan	Status	resolved => closed

Notes
(0000372) ivan (administrator) 2008-12-23 09:49	Which version? Is this with the default set of triggers? If not you'll need to say what your exact trigger settings are, including your trigger rule.

(0000374) paulh (administrator) 2008-12-23 19:23	Latest trunk (so 3.45) (as of last night) I've not touched the triggers so its the default set

(0000384) paulh (administrator) 2008-12-24 17:16	just wiped my db and created a new one and still get the error so definetly using latest set of triggers

(0000725) ivan (administrator) 2009-03-05 13:53	Is this still an issue with 3.45?

(0000740) paulh (administrator) 2009-03-06 20:07	Unfortunatly yes, the user error is slightly more friendly now though: Application Warning [512] Error in trigger rule for TRIGGER_INCIDENT_CREATED, check your trigger rules. in /home/paulh/sit/lib/triggers.inc.php @ line 110 Backtrace: /home/paulh/sit/lib/triggers.inc.php @ line 110 trigger_error() /home/paulh/sit/portal/add.php @ line 232 trigger()

(0000756) ivan (administrator) 2009-03-07 15:25	thanks

(0000796) timfederwitz (reporter) 2009-03-23 19:59	Could this be what's causing new incidents to never be automatically assigned to an available engineer? Or would that be a separate bug? Currently, on my brand new install, new incidents never get auto assigned.

(0001033) blowagie (reporter) 2009-05-08 17:33	You can solve this problem by changing line number 232 in portal/add.php Replace: trigger('TRIGGER_INCIDENT_CREATED', array('incidentid' => $incidentid)); with: trigger('TRIGGER_INCIDENT_CREATED', array('incidentid' => $incidentid, 'sendemail' => 1)); If you don't, the eval fails because {sendemail} is removed (replaced by nothing). You end up with "$value = == 1" instead of "$value = 1 == 1".

(0001052) paulh (administrator) 2009-05-14 19:31	Thanks for the feedback blowagie, I think this is because we have: Rules: {sendemail} == 1. On the trigger though sendemail isn't a required field according to the trigger definition perhaps it should be. Kieran/Ivan can you clarify?

(0001078) ivan (administrator) 2009-05-19 16:48	Thanks blowagie (again)! Although this isn't a required parameter, parameters don't have default values at the moment, so it does end up blank as you point out. I'll log a seperate bug about this, we need to either provide defaults for some parameters or make the trigger rules a bit more intelligent. Added your patch in trunk svn r5390

(0001207) kieran (administrator) 2009-06-13 14:04	This is the case that the trigger parameters (rather than rules) should be used, but there's no UI for it! In this case, you'd add {sendemail} == 0 to the parameter as you don't want to send an initial email if the user is logging it as a portal incident.

(0001290) kieran (administrator) 2009-07-11 14:55	Resolved by Ivan in svn trunk r5390. Bug for proper solution reported as 0000760.

(0001664) ivan (administrator) 2009-08-16 14:39	Released in 3.50rc1