SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001212SiT!incidentspublic2010-04-01 17:422012-01-25 12:29
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001212: Configurable weights for auto-assign lottery
DescriptionThe auto-assign lottery uses fixed values to assign a number of tickets for certain things. We should allow a administrator to configure 0, 1, 2; or 3 tickets for each condition.
Additional InformationThe lottery operates by granting 'tickets' to each user, the more tickets a user has the more likely he/she is to receive the incident, tickets are allocated as follows:

    * 1 ticket for having the appropriate skill to deal with the incident
    * 1 ticket for being online at the time of the reassign
    * 2 tickets for having a status of 'In Office' or 'Working at home'
          o or 1 ticket for having a status of 'At Lunch' or 'In a meeting'
    * 1 ticket for your queue being updated in the past 4 hours
    * 2 tickets for dealing with the same contact in your queue
    * 1 ticket for having five or less incidents in your queue
    * 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
    * 1 ticket for having an empty queue

In addition to the ticket system, a critical priority incident can only be auto assigned to a user that is online at the time.

The ticket is then chosen at random from all the users with tickets, the user owning the 'winning' ticket gets the incident.
TagsNo tags attached.
Attached Files

- Relationships
parent of 0001766closed Add plugin_do() hook into "suggest_reassign_userid()" for alternative assignment plugin 
has duplicate 0001385closed Auto Assign lottery should have a 'fair' mode 

-  Notes
User avatar (0002913)
paulh (administrator)
2010-04-02 13:33

I think the auto assign lottery algorithm should be pluggable as no one algorithm is going to fit all organisations.

We should ship some algorithms (including the one below) and allow organisations to write their own.

I don't think the pluggable approach would be difficult to achieve, my though if you'd have a folder say lotteryalgorithms with a file for each algorithm with a predefined function name and you'd have a drop down in the config centre to choose the algorithm and this file would then be included.

What do others think?
User avatar (0002915)
ivan (administrator)
2010-04-02 13:39
edited on: 2010-04-02 13:41

I think we should ship a single algorithm but add a plugin hook so it can be replaced with something custom.

Edit: I think pluggable could be much simpler even than the way you describe, it simply needs a hook inside suggest_reassign_userid()

User avatar (0002918)
paulh (administrator)
2010-04-03 11:42

My concern with shipping a single algorithm is that it would always be run and the vales retrieved would just been thrown away which is wasteful especially if the algorithm is as discussed as that sounds like it could be quite intensive/

The other problem with plugins is you could have multiple plugins which registered with the same hook thus could get random reassign results. Whilst I'm a fan of plugins I don't feel this is a suitable use of them in current form, we could use plugins to provide the underlying addition of the algorithm though I still believe we need a config option where the organisation can choose the one hey want to use
User avatar (0002920)
ivan (administrator)
2010-04-03 13:33

It's total overkill to design a whole new plugin (folder include) system just for this. I'm sure we can work something out using the existing plugins infrastructure.

It should be possible to run a plugin_do() and only use the internal algorithm if the plugin_do() did nothing. Yes there could be clash with multiple plugins, but we have that problem with almost every other plugin context already. Maybe thats something we should be addressing when we revamp the plugin manager, some kind of precedence.

This is all a bit academic anyway really, AFAIK nobody has asked for a different algorithm so we don't know that there's a need for this yet.
User avatar (0004431)
nicdev (developer)
2012-01-24 13:53
edited on: 2012-01-24 13:54

On another note, This is one of the plugins that our team have asked me to develop. Basically they want "another" system of assignment, meaning that no lottery or weights are given, just simple in one user 'group' like "Hardware support", each user in turn will get an incident assigned to him (if he is not on holiday of course). They want a sort of 50/50 system (for example when you have 2 Users in a group). If this can work for someone let me know because I have already started this as a plugin ....

EDIT: Ivan, I agree btw, that it is as simple as adding a plugin_do to the "suggest function" :-)

- Issue History
Date Modified Username Field Change
2010-04-01 17:42 ivan New Issue
2010-04-02 13:33 paulh Note Added: 0002913
2010-04-02 13:33 paulh Status new => feedback
2010-04-02 13:39 ivan Note Added: 0002915
2010-04-02 13:39 ivan Status feedback => new
2010-04-02 13:41 ivan Note Edited: 0002915 View Revisions
2010-04-03 11:42 paulh Note Added: 0002918
2010-04-03 13:33 ivan Note Added: 0002920
2012-01-24 13:19 ivan Relationship added related to 0001385
2012-01-24 13:20 ivan Status new => confirmed
2012-01-24 13:21 ivan Relationship replaced has duplicate 0001385
2012-01-24 13:53 nicdev Note Added: 0004431
2012-01-24 13:54 nicdev Note Edited: 0004431 View Revisions
2012-01-25 12:29 ivan Relationship added parent of 0001766

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker