DeveloperWiki:Web Admin

From ParabolaWiki
Jump to: navigation, search

1 Redmine Web Admin

See README.maintenance for instructions on how to enable the Redmine web admin controls.

1.1 Groups and Roles

Groups are arbitrary collections of members; primarily for the purposes of Project<->Role associations and mass member assignment.

Roles are per-Tracker permissions sets that govern the access and visibility levels, the available Workflow options, and posting constraints for assigned members.

For simplicity, each custom Group has a one-to-one pairing with a Role of the same name. The built-in 'Non member' and 'Anonymous' do not have Roles.

Group Issue Assignee? Moderator? Post Unconstrained? Post? Read?
Hacker
Community
Member
Non-Member
Anonymous

1.2 Tracker Classes

Trackers (labeled as "Issue Concern" in the GUI) have associated IssueStatuses and Workflows.

There are two distinct classes of Tracker. Each Tracker within a class shares a common set of IssueStatuses and Workflows.

1.2.1 "Bugs" Tracker Class

  • Bug
  • Freedom Issue
  • Privacy Issue

1.2.2 "Features" Tracker Class

  • Porting
  • Feature Request
  • Packaging Request
  • Housekeeping

1.3 IssueStatuses

The Bugs class issues have the default state of 'unconfirmed', with the available states:

  • unconfirmed (default)
  • info needed
  • confirmed
  • in progress
  • forwarded upstream
  • duplicate
  • not-a-bug
  • fixed (assignee required)

The Features class issues have the default state of 'open', with the available states:

  • open (default)
  • info needed
  • in progress
  • forwarded upstream
  • wont-fix
  • fixed (assignee required)

Note that the 'unconfirmed' and 'confirmed' states for the Bugs tracker class are analogous to the single 'open' state for the Features tracker class; and the 'not-a-bug' state for the Bugs tracker class is analogous to the 'wont-fix' state for the Features tracker class.

1.3.1 Workflow Matrices

The Workflow Matrix for each Role, determines the state transitions from which IssueStatus that an Issue has currently, to which appropriate next IssueStatus it may take.

Note: TODO: note that those analogous Issue states described above were originally as one - when the new disambiguation states were added, many issues were orphaned in one of 'open' or 'not-a-bug' (formerly 'invalid') - the "workflow" matrices still carry some cruft from this transition - ideally, each issue in one of the "bugs" classes that is still in the 'open' state should be changed to either 'unconfirmed' or 'confirmed'; and each issue in one of the "features" class that is still in the 'not-a-bug' state should be changed to either 'wont-fix' - after that, the 'open' and 'wont-fix' states can be pruned from the "workflow" matrices for the "bugs" tracker class; and the 'unconfirmed', 'confirmed, and 'not-a-bug' states can me pruned from the "workflow" matrices for the "features" tracker class