Anonymous | Login | Signup for a new account | 2021-04-11 08:36 BST | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | 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 | 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 | |||||||||
![]() |
|
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. |
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. |
![]() |
|||
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 - 2021 MantisBT Team |