Email to ticket gateway

A common feature of many issue tracking systems is the ability to create and manipulate tickets via e-mail. There is currently no support in the Project issue tracking module to do this. Drupal does provide a mechanism to create content via e-mail, the Mailhandler module, and there is some very old Mailhandler-integration code in Project issue tracking. However, this code really needs to be cleaned up, ported, and polished. Some of the great things this would allow:

  • Using a single system for all ticket tracking, instead of relying on one system for e-mail support, and another for the full-featured web-based system.
  • Replying to issue notification e-mails to follow-up, reclassify, and/or close issues, instead of needing to use a web browser to respond.
  • The ability to generate issue replies while working off-line which would automatically be sent off and processed once you connected back to the Net and your mail client could deliver the messages.

Improve packaging of installation profiles

Installation profiles allow easy installation and configuration of a pre-defined set of modules. For example, the Drupal.org testing profile allows a user to quickly set up a site that approximates drupal.org, which is useful for testing. The biggest usability limitation of the current system is that all of the modules required by the installation profile must be downloaded and placed in the correct directories separately. Instead of being a one step process to get a new site up and running, end users must download the installation profile, read the documentation (if it even exists!) to find the list of other things to download, and so on.

With some work, the packaging scripts that come with Project module and which create all of the releases on drupal.org could be modified to automatically gather Drupal core and all the contributed modules needed for a particular install profile, and place them in a single archive file for download. This would greatly improve the usability of installation profiles, and make it much easier for Drupal site builders to get started with a Drupal installation tailored for a specific type of website.

Improving subscriptions and notifications

Currently Project issue tracking has a limited ability for users to follow the progress of individual issues via e-mail -- they can either get notifications on all issues or on individual issues which they have created or commented on. If a user subscribes to their own issues, they cannot unsubscribe, either. In addition, the current subscription system doesn't scale well with a large number of projects.

We should provide more granularity in what users can subscribe to, and the ability to subscribe/unsubscribe as they see fit. Specifically, it would be great to:

  • Easily subscribe to any individual issue without commenting on it.
  • Have a summary view of all issues you're subscribe to, with an accompanying RSS feed.
  • Easily unsubscribe from an issue from either the issue itself or the summary page.
  • Continue to allow subscriptions to entire projects.
  • Make it scale well to a large number of projects/subscribers.

Plan of attack

  1. Several subscriptions frameworks were considered, and Flag module has been chosen as the one best-suited to our goals. It's well-maintained, has a good API, and views integration
  2. A new UI will be designed, living at user/X/subscriptions, which will have the following components
    • A global, site-wide radio button set for "Email me issues from any project" with choices for "All issues", "Subscribed issues", and "None". This information will be stored in a new, per-user table
    • A table of any projects where the user has configured emails on a per-project basis (e.g. http://drupal.org/project/issues/subscribe-mail/drupal). The table shows the current settings for each project, and includes a row with an auto-complete text field to opt-in for emails to other projects. Again, the choices are "All", "Subscribed", and "None"
    • A global setting for the option to receive issue emails in full digest format (like you get now) or to just get the latest comment (better for threaded mail clients).
  3. Users will automatically flag issues as 'Subscribe' any time they post an issue, or leave a comment on an issue.
  4. Code for sending issue emails will be adjusted to build the list of users to mail from the list of users that have flagged the issue and the global settings at user/X/subscriptions
  5. Project module will adjusted to become flag-aware, allowing users to mark projects they would like to track.
  6. The /project/user/X page will become tab-based, with new tabs for "My watched projects" and "Projects with commit access" (along with the existing "Projects I own")
  7. Tracker2 module will be adjusted to become flag-aware, which will remove the necessity to '+1 subscribe' on forum posts as well, and provide a more consistent interface between the "My issues", "My projects" and "Recent posts" pages.

Interacting with remote issue queues

Currently, the only available method for updating Project issue data is direct interaction with the website (data can be read from the site via limited email and RSS access).

A web service for Project issues would offer these advantages:

  • Remote servers or client-side programs would have read/write access to a site's issue queue.
  • Ability to create, edit, delete, and follow up on issues.
  • Generate very specific listings of issues (ie, "pull issues with the following node ID's").

Multi-file release nodes

Currently Project release nodes only allow the attachment of one file per node, which is quite limiting. In the new Drupal 6 compatible version, the database structure is in place to support multiple files per release node. However, the code logic and user interface still needs to be completed.

Advantages of multiple files per release node include:

  • Files in multiple archive formats (ie, .tgz and .zip).
  • Files for multiple platforms (ie, Windows and Linux).
  • Non-archived releases (ie, a release with two individual files instead of one .tgz file).

Version Control API

Version Control API provides functions for interfacing with the server side of version control systems. Currently, Project only has limited integration with one version control system, via the CVS integration module. The Version Control / Project Node integration module connects Project module to the Version Control API, thus allowing Project to interact with multiple version control systems, and in a much cleaner and more abstracted way than what we have now.

Currently, both the Version Control API and Version Control / Project Node integration need a push to make them production ready for use with Project. Advantages to this functionality include:

  • Version Control currently has backends for CVS, Subversion, Git and Mercurial.
  • Make it possible to use more than one version control system with one Project install. For example, each project could choose its own version control system as needed.