#10: Configuration profiles

Contents

1. Motivation
2. Proposal

Proposed by

Martin Aspeli

Proposal type

Architecture

Assigned to release

• Poi 2.0 (Unreleased)

State

being-discussed

Motivation

Everybody has a diffent idea of how an issue tracker should work. Having detailed configuration options for each possible scenario in the tracker would likely lead to more confusion than benefit.

Proposal

• Take a long hard look at the various issue tracking use cases. For example, we should consider:
  • The software tracker scenario
  • The software tracker scenario as part of a PloneSoftwareCenter instance
  • The non-software generic issue tracking scenario
  • The helpdesk scenario, where issues may be logged on behalf of other people

We already do this with the isUsingReleases option - if no releases are defined, the by-release functionality is disabled. Before adding a dozen more such switches, we need to think about how to generalise profiles.

• Define options that make sense for each. Some will involve fields that are only applicable to that particular scenario. Some will involve particular defaults for e.g. issue areas, severities, and other standard options.
• Move the more specific tracker configuration options to a separate AT schemata or a different tab when editing the tracker.
• Use a simple drop-down to select a profile when creating a tracker.

The available profiles may be configured in code in the first instance. Longer term, they may also be made available TTW through a tool, but this may be overkill.