0001884: Auto assign function does not work as described / expected

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001884

SiT!

incidents

public

2013-07-05 13:17

2013-07-06 16:34

Reporter

nicdev

Assigned To

ivan

Priority

normal

Severity

minor

Reproducibility

always

Status

resolved

Resolution

fixed

Platform

OS Version

Product Version

3.69

Target Version

3.90beta1

Fixed in Version

Current GIT

Summary

0001884: Auto assign function does not work as described / expected

Description

The function "function suggest_reassign_userid($incidentid, $exceptuserid = 0)" that is used to find a user to assign the incident to on a lottery basis has some errors that cause the function to not work as expected: for reference see here http://sitracker.org/wiki/Auto_assign [^]
----------------
The first issue is a coding error:
line 371:
// Get one ticket for your queue being updated in the past 4 hours
if ($queue_lastupdated > ($now - 14400)) $user->userid;

should read:
if ($queue_lastupdated > ($now - 14400)) $ticket[] = $user->userid;

In fact this condition is not taken into account at all.
----------------
the second issue is in the conception of the logic. From the document in the Wiki we read:
"Receive up to 3 tickets, one less for each critical priority incident in your queue
Receive up to 3 tickets, one less for each high priority incident in your queue"

But this is never taken into account because the function looks at ALL the user's incidents (open or closed) and for all time! This means that the user's list will ALWAYS show critical and high incidents. In my case the SQL on line 353:
"// Have a look at the users incident queue (owned)
$qsql = "SELECT id, priority, lastupdated, status, softwareid FROM `{$dbIncidents}` WHERE owner={$user->userid}";"

gives a result of 2644 incidents in my queue, and of course I do have at least 3 high and 3 critical incidents in my queue :-) Thus someone that have been here for a long time, will NEVER get any tickets for these points, and will get less incidents assigned to them.

I think at least we should look at Incidents in the queue which are OPEN only, or even better that are "Active" ..

----------------

Additional Information

Any ideas welcome ;-)

Tags

No tags attached.

Attached Files

Relationships

Notes
(0004834) ivan (administrator) 2013-07-06 16:27	Thanks Nico. The first issue is already fixed in 3.90 (git) but the second issue does still exist in both the current 3.67 and the 3.90 development branch.

(0004835) ivan (administrator) 2013-07-06 16:34	Fixed in Git [master 066ad9c] * Use UNIX end of lines and Fix indenting * Fix for Mantis 1884, only look at incidents that are not closed and not awaiting closure when considering incidents that in the users queue. This is because if we look at all incidents ever logged against the user, the bias for critical and high priority incidents already in a queue won't work as documented.

Issue History
Date Modified	Username	Field	Change
2013-07-05 13:17	nicdev	New Issue
2013-07-06 16:27	ivan	Note Added: 0004834
2013-07-06 16:27	ivan	Assigned To	=> ivan
2013-07-06 16:27	ivan	Status	new => confirmed
2013-07-06 16:30	ivan	Status	confirmed => assigned
2013-07-06 16:34	ivan	Note Added: 0004835
2013-07-06 16:34	ivan	Status	assigned => resolved
2013-07-06 16:34	ivan	Resolution	open => fixed
2013-07-06 16:34	ivan	Fixed in Version	=> Current GIT
2013-07-06 16:34	ivan	Target Version	=> 3.90beta1