Re: [Mailmanager-developers] Queueing and User Abilities

[Kevin C. <ke...@lo...>]

On Mon, Jan 30, 2006 at 11:30:10AM +0000, Kevin Campbell wrote:
> For those of you following the HEAD branch of development, you have probably
> noticed the addition of queueing code. This is to add in the ability to queue
> tickets and allow users to obtain a ticket from the queue one at a time, 
> rather than the current allocation system of auotmatically assigning a ticket
> to a user. To have this fit in with the internal design, there is a hidden 
> queue manager role account for each queue, so that tickets are always assigned
> to a user.

Regarding the queue allocations, I should probably point out where things are
going with regard to abilities, categories and attributes. Categories in 
MailManager are a bit too limited and will at some point be replaced with 
a more flexible system. Internally, we should also be replacing how we deal
with categories with the more general 'attributes' in the ruleset engine,
although there are some issues with that.

Initially the plan had been to generate abilities based on categories,
but this causes issues with the dynamic nature of the ruleset. Having an 
entirely static ruleset allows ticket lifecycles to be replayed from start
to finish at any point, which does have a reasonable amount of benefits. It
should be possible to preserve this property with a bit of work.

For the next 2.1 release, we're adding in the concept of abilities, which can
be assigned to users. These will be used by the queueing logic to determine
whether a user can deal with a ticket or not. Users will be given a list of
abilities showing what category assignments of tickets they can deal with.
This isn't great, but it should be suitably powerful for most use cases for
now until we can replace how categories work.

    CREATE TABLE mm_user_abilities_category0(
        username TEXT REFERENCES mm_user,
        category0 TEXT
    );

As an example, category0 could be entitled language, with 'french', 'english'
and 'german' as potential options. Users would then be given a list of what
languages they can deal with as abilities. The current queueing logic will
only assign tickets to users who should be able to deal with them. It will
also prioritise cases where tickets can only be dealt with by a single user
and assign appropriately. There is a test case to this effect, which should 
soon be added to head. 

Most of these changes should be structured to allow you to further customise
this to your own needs. The queueing logic is modular and you can replace the
current BasicQueue class with your own alternative. So, should you wish to 
make something which does weighted assignment to prioritise tickets more 
effectively, you can do so. By altering the ruleset description you can also
use these queues throughout the system although at present the UI might not
support that particularly cleanly.

K

--
Kevin Campbell 
Software Engineer 
Logicalware Ltd
GPG Key: F480EC23