SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001884SiT!incidentspublic2013-07-05 13:172013-07-06 16:34
Reporternicdev 
Assigned Toivan 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.69 
Target Version3.90beta1Fixed in VersionCurrent GIT 
Summary0001884: Auto assign function does not work as described / expected
DescriptionThe 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 InformationAny ideas welcome ;-)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (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.
User avatar (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


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker