Customisable attributes

This feature has now been implemented.

Current problems

• Severity, status and priority cannot be edited per project or per company
• Additional classifications of tasks cannot be added

Solution

Attributes can be defined and grouped per company or per project.

Schema

[AttributeGroup]
companyId:int
id:int
name:string (short name which is displayed in the UI)
required:boolean (if true, then a task cannot be created or edited without selecting at least one attribute from this group.)
oneOnly:boolean (if true, only one attribute from this group may be attached to a task at a time. In practice that means a popup or radio button set in the UI)
allProjects:boolean (if true, this group applies to all projects, if false, then we expect to see some join records to specific projects)

[Attribute]
id:int
attributeId:int
name:string (short name which is displayed in radio buttons, popups, etc)
colour:string (html colour code which is used to colourise tasks with this attribute)
icon:binary (image which is used to identify tasks with this attribute)
isDefault:boolean (the default attribute within the attribute group. Only one can be selected per group.)

[Attribute_task]
attributeId:int
taskId:int

[AttributeGroup_project]
attributeGroupId:int
projectId:int

Attributes are joined to tasks with a many to many join.
Attribute groups are joined to projects with a many to many join. This is optional since many attribute groups will be used across the company.

User interface

Task edit

The existing interface is largely unchanged, except that all attributes need to be grouped since they are generated dynamically. This means moving task status to the right menu alongside priority and severity.

For each task, the attribute groups are queried to find allProjects=true or groups joined to the current project. This means the GUI needs to be updated when the project is changed. Attributes no longer available are deleted. For each attribute group, a popup or a set of checkboxes is drawn, depending on whether the group is oneOnly. Validation needs to enforce the required flag. For new tasks, the default attribute is selected already.

Search filter

Where priority, severity and status are hardcoded now, attribute groups should dynamically populate the search filter. Ajax is needed to updat the attribute groups shown as the project is changed. Obviously significant changes are needed to the SQL behind the filter and to the mechanism which saves the filters into Views.

Preferences

An interface is needed to define the attribute groups and attributes and then attach them to specific projects. It would be satisfactory in the first instance to only implement company-wide attribute groups and leave project specific groups to later.

Task list

Currently the task list has colours and icons added to each task row. This behaviour should continue with several caveats:

• it is possible that two attributes are assigned to a task, both of which assign a colour or icon. In that case the first attribute (sort order?) should be used and the second ignored.
• speed may be an issue given the joins required. If so, some caching (denormalisation) may be required, but every effort should be made to avoid polluting the schema with fields which add complexity and possibility of error if they are not updated in every case.

Migration

Several candidates are identified for migration to the new concept.

• Severity. This migration should be simple and obvious.
• Priority. Again, simple.
• Status. This will be more complex since status has significance within several search filters. In particular, some filters have a concept of ‘open’ which is a grouping of ‘in progress’ and ‘open’ actual statuses.

Ultimately the whole point is to add flexibility to status, so migration needs to be dealt with at some point.