Add custom Priority Levels

This is a hard problem in D5 due to how priorities are handled in issue query URLs and for sorting issues generally. They just use their underlying integer representation (critical == 1, normal == 2, minor == 3). For example, the list of critical issues for D7 core development is here:

http://drupal.org/project/issues?projects=3060&priorities=1&categories=b...

Similarly, if you sort issues by priority:

http://drupal.org/project/issues/project_issue?sort=asc&order=Priority

The only reason the order makes logical sense is because the underlying DB column we're sorting on is an integer with hard-coded values that correspond to the priority levels. :(

So, making these levels customizable becomes really tricky, since either a) you could only add more values that are lower priority than "minor", b) you'd have to have a way to renumber all existing issues/comments if you added other levels that are between existing ones (e.g. adding a new "high" level between normal and critical, or c) we'd have to completely redesign the DB schema for how these values are stored, filtered, and sorted (such that each priority level had its own separate weight field, and all the SQL was modified to join on a {project_issue_priorities} table or something -- although SORT criteria that span multiple tables make for notoriously expensive queries) :(

It's possible that while re-implementing most of the issue query interface with views, we can help solve this problem. Most of the URLs are probably going to change, so maybe we can set things up in such a way that custom priority levels won't cause as much trouble in the future. But, I'm marking this issue postponed at least until the views conversion and D6 port is underway (or done).

It's possible that while re-implementing most of the issue query interface with views, we can help solve this problem.

Just wondering if this is something that could be addressed now that most of the Views integration has been finished? It's something I've been asked to do in our environment. (Note that I'd be happy to help out, just want to test the waters first and see if there's another reason for keeping this postponed)

Yes, now would be a lovely time to revisit this. However, all the problems outlined in #2 are still here. The only really clean way to do this would involve making the issue queue SQL querying punishingly slower, by adding a SORT BY to a different table (where ever we store the weights for custom levels) than all of the WHERE clauses -- which prevents the query from using an index. The only way to really make this perform well would be to denormalize the data like crazy, either ourselves, or via materialized views.

Ultimately, the category, priority and status fields should become CCK fields.
Project and version should become node reference fields.
Assigned should become a user reference field.
#85049: convert project* to CCK
That wouldn't necessarily solve the performance problems on its own, but perhaps the new FieldAPI and related discussions will provide ways around the performance woes.

An alternative approach would be to keep the priority stored as an int (effectively the weight and id) in the {project_issues} table, but change the Views filter for it to expect human-readable names in the GET args (breaking tons of bookmarks, although many are broken already) and have the filter map the human readable names into the integers for the underlying query. Then we need a fancy batch-aware method for data migration when you reorder your custom fields to LOCK everything and go though {project_issues} and {project_issue_comments} and rewrite things. Ugh.

The final approach is to say you can rename levels, and add new ones at the bottom of the list, but you can never reorder them. Then we'd keep the integer like we do now. That'd avoid most of the performance problems, and would still provide a good deal of flexibility. It'd mean that renaming is destructive and retroactive, so you'd have to use it cautiously on a live site. But, if you're just starting out, you could configure whatever you need. Perhaps the defaults on install should use 1, 5, and 9 as the default integers, to give people some space to interleave other values in between them. ;)

subscribing

It is a similar, or I would say it is a same problem as #27865: Remove hard-coded status options

@Pasqualle: Sort of. The thing is, you can already customize the status options. The point of #27865 is that, in spite of being able to customize them, there are a small handful of places in the code that still use hard-coded status numbers for a few features (e.g. auto-closing issues and moving from fixed to closed).

The tricky problem with *this* issue is that it's hard to both a) allow sorting by priority and b) prevent link rot if you can add new priorities or change their labels and meanings.