Sla

Service level agreements

A new concept to accomodate companies who provide service at a particular level and need to report against those service agreements as well as ensure that tasks are flagged appropriately. There will be significant overlap with this feature, queues and triggers. It will also affect which worklogs are exported for billing purposes.

Schema

[ServiceAgreement]
id
name

[Project-Client]
client_id (not null)
project_id (not null)
serviceagreement_id (null allowed)

This new table refactors the existing many-to-one join between project and client, and makes it many-to-many. It also adds a new join to serviceAgreement.

User interface

1. A new list and a new edit view to show and edit service agreements. No search or paging needed since the list will usually be < 20. Add new menu under preferences, only accessible to admin users
2. Project edit view needs to have many many join to clients instead of many-one. An autocomplete field:

[ ]
add client

Acme Trading [ popup ] X
Big Company [ popup ] X

The popup has a list of all the service agreements, plus the default option “[none]” which results in a null join. The X is the delete button of course.

3. Within the task edit view, there is a project popup. It can no longer be grouped by client, so let’s just make it alphabetical. This may have similar effects elsewhere.

4. We need a strong visual aid in the task edit view to show that a task is linked to an SLA (that is, it is linked to a project which is linked to an SLA with a client who matches the client who is linked to the task). For now, just put in some red text under the task title “SLA: name of service agreement” and we’ll work on a better piece of design.

5. Searching. Tasks can be found in the filter by SLA.