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.

Beginnings. Needs update, delete, Views, will work later afternoon and evening until its done.

Denormalizing the weight into the relevant tables. Should be trivial to integrate with Views after this. Still, needs an update path written, delete needs implemented and I am not 100% what should we do when you update the weight of an issue. I might do some fancy renumbering on the save... tabledrag is not nice.

Excellent, lovely start!

#8 implies you did more work (denormalizing the weight...) but there's no patch. ;) So, I don't want to review #7 too closely since it's obviously going to change some more. A few quick things on a skim:

A) What's up with putting + '&nbsp', in one of the rows in the $data array in theme_project_issue_admin_priorities_form()? Can't we say one of the headers spans two columns instead?

B) A few of the functions miss PHPdoc (but they're pretty friggin' obvious what they're for, so it's not worth holding up other progress on this -- but if you think of it, nice to include as you're going).

C) This seems to be quite a bit of cut & paste from the status/state handling code. E.g.:

+    // Check to see whether the state already exists:
+    $issue_state = db_result(db_query("SELECT COUNT(*) FROM {project_issue_priorities} WHERE name = '%s'", $form_state['values']['priority_add']['name']));
+    if (empty($issue_state)) {

Nice variable names and comments. ;) Either this should be generalized and shared between the two cases or at least it should be thoroughly cleaned to be specific to priorities. I haven't looked closely enough at this (and compared it to the status code) to have a sense of if generalizing is worth doing or not. Let me know what you think.

I'll review more closely once another patch comes in...

THANKS!!!
-Derek

Another , completely untested patch.

D) I don't see why we need to denormalize priority_weight into {project_issue_comments}. {project_issues} yes, but not {p_i_comments}.

E) This has got to be a bug:

$exists = db_result(db_query_range('SELECT priority FROM {project_issues} WHERE priority = %d', 0, 1)) || db_result(db_query_range('SELECT priority FROM {project_issue_comments} WHERE priority = %d', 0, 1));

There's no variable for %d given the db_query_range().

F) I don't understand why $exists is being tested at all like this. Seems like we always need to have a delete link. The question should be in the submit handler for if that's a trivial operation or requires a batch...

G) project_issue_admin_priorities_form_submit() really needs some elaboration in the PHPDoc about the overview of all the treachery that function is doing and why. Yes, I know "tablesort does weird things with numbers" is true, but that needs to be clarified and justified in a code comment, not just a passing reference in these issue comments.

H) Please excuse the SQL ignorance, but is CASE portable? I must admit to never having seen it before, so I'm not sure if that's a mysql-ism or part of the "standard".

I) I know project* is itself inconsistent about this, but isn't the core standard (now) to use singular table names? So, don't we want {project_issue_priority} instead of {project_issue_priorities}?

J) If we're going this far, hard-coding 2 here is evil:

+  $priority = $node->project_issue['priority'] ? $node->project_issue['priority'] : 2;

Seems like we need another column in {project_issue_priority} to remember which is the default priority for new issues, and the admin UI should be modified accordingly. See #423304: Add a per-project default component setting to simplify the UI when submitting issues for more in terms of a similar sort of admin UI for a default component on new issues (although that's more complicated than we care about, since this could be a global admin setting, not per-project)...

I just asked webchick in irc what the rationale for this is, and I think I get it - it's much better than having 'critical' issues moved to normal just to get the release out quicker, 'cos normal issues can get lost very easily amongst all the others.

However, I think deployment of this absolutely needs to be accompanied by an update to the contributors issue count block - so we have a 'major (count)' link alongside critical.

As we gear up for release, there are two places you have to look at the moment - 1. critical issues 2. Pending bugs - because people often post critical bugs as normal bugs, which then sit there for a week while nobody looks at them. Adding 'major' to this list means there's three places to check - because we need to look out for mis-classified 'major' bugs which are actually release blockers, and if there's not a handy link to them, I guarantee we'll release Drupal 7 with some stupid issue in it which will require a 7.1 within a matter of days. Look at the security issue which was fixed on the day D6 was released if you've forgotten how crazy it gets. And as a community we have a habit of reclassifying things at the last minute to get things done quick, that's going to be so much easier to do with a major priority.

Also apologies for the off-topic rant here, but I don't see an actual issue to add 'major' for core anywhere, so this was the best bet.

I think this feature is not for d.o, it is for custom installs.. I do not see why would d.o need new priorities, and this is not the issue for that discussion. Please create a new one.

No, this is for core. Requested by Dries. See #669048: We should have four priorities not three (introduce a new 'major' priority). However yes, we need another issue to discuss how to handle the priority, so I created #714728: New 'major' priority to avoid taking this one off course.

Right. However, #669048: We should have four priorities not three (introduce a new 'major' priority) is really about using this new feature. I repurposed it to clarify, then marked #714728: New 'major' priority duplicate and explained why. ;)

subscribing, I'll try to work on views integration this evening.

Tested priorities not so much state.

Only took a quick glance at this but it doesn't add the priority_weight column to {project_issue}.

This adds basic views support by adding a new handler that uses the custom field for sorting, and overrides the click_sort method in the field handler in the same manner.

Also fixed the missing column from project_issue_update_6003.

Haven't tested this, looking great. However, some obvious problems:

K) patch #19 doesn't add admin.inc ;)

L) this seems likely to be a bug:

+  $form['project_issue']['priority_weight'] = array(
+    '#type' => 'value',
+    '#value' => db_result(db_query('SELECT weight FROM {project_issue_priorities} WHERE priority = %d', $priority)),
+  );

that's going to be wrong in the submit handler if the user changes the priority. i don't see why we want this as a form value at all. we should run this query once in the submit handler before we're saving the node.

M) We also need to ensure we update this correctly as comments are added. Since comments can change the priority of the issue, we need to make sure that also updates this denormalized weight.

Thanks, folks!
-Derek

Turns out it wasn't actually saving the denormalized weights anywhere.

K) Is fixed.

L) & M) I've updated the queries in _project_issue_insert() and project_issue_update_by_comment() to include the denormalized weights and added the queries to fetch the weight based on the priority id in each location.

Saving and updating by posting a comment works now.

Is there a use case for editing a node? I'm not sure what the expected behavior should be.

I'm sure there are some bulk update and other queries that need updated as well, but I'm not sure where they are.

Forgot to re-add the db_add_field to project_issue.install.

I can't believe ppl actually workin' on this. Go mikey_p!

Note that $context['sandbox']['progress'] = 1; should be $context['finished'] = 1;

Yeah, forgot to mention that update_6004 is always showing as failing even though it is updating successfully.

This fixes the failing 6004 update per #24 and also fixes add require_once for the file that _project_issue_priorities_update() is in.

I did a basic search for other functions that do bulk update, or other queries affecting {project_issues} and the two places mentioned in #21 seem to cover all the bases. project_issue_update_by_comment() is used pretty much every time that table is touched.

@mikey_p: re: "project_issue_update_by_comment() is used pretty much every time that table is touched." -- yup, that was the intention. ;)

Thanks so much for taking this forward. I'm going to give it a spin in a little while. Stay tuned!

So I don't forget later, I need to run the following after applying this patch, before committing:

cvs rm includes/admin.issue_status.inc
cvs add includes/admin.inc
cvs add views/handlers/project_issue_handler_sort_issue_priority_weight.inc

Looking closely now...

This is starting to really take shape, yay! Tested locally. Below are the problems I ran into, both via functional testing and reviewing the patch...

#11.I) is still wrong (i think the new table should be {project_issue_priority}). similarly, function and variable names should be renamed to match.

N) When I tried to add a new "major" priority on my local test site, after the batch ran, I got this:

notice: Undefined variable: delta in /.../sites/all/modules/project_issue/includes/admin.inc on line 228.

which is this:

    $max = max($delta, $priority->weight);

and indeed, $delta is used uninitialized.

O) When I deleted an unused priority, I got even more notices:

notice: Undefined variable: name in /.../sites/all/modules/project_issue/includes/admin.inc on line 196.
notice: Undefined index: new_sid in /.../sites/all/modules/project_issue/includes/admin.inc on line 197.
notice: Undefined variable: delta in /.../sites/all/modules/project_issue/includes/admin.inc on line 228.

P) This needs format_plural():

'#description' => t('There are !total existing issues with @name @property. Please select a new @property for these issues.', array('!total' => $total, '@name' => $name, '@property' => $property)),

I just tried it on my test site with a single "major" issue and got this:
There are 1 existing issues with major priority. Please select a new priority for these issues.

Q) Although an edge case, weird things happen to issue comments that moved an issue into a now deleted priority. For example, I added a "major" priority, commented at an issue to move it to major, then deleted that priority. See attached screenshot:

I'm not entirely sure what we can do in this case. Perhaps the best we can do is when printing comments like this, we have to use something like "normal >> [deleted priority]"... Thoughts? Also, there's nothing that shows that the priority went from major back to normal. I'd have to think about it more to decide what, if anything, we even should do here. Probably nothing.

R) In the views handling, the sort order is confusing for the weight. When you order by "Project issue: Priority asc", you get critical, major, normal, than minor. It seems like "ascending" priority should reverse that. I think it'd be best if we just hard-code this into the views handlers themselves and reverse the requested order. That way, the weights themselves can still be "backwards" (0 == most critical, N == least critical), and that'll match the tabledrag and priority list drop down ordering as we expect (most critical == lightest == floats to the top, least critical == heaviest == sinks to the bottom), but the views handlers will actually make sense.

S) project_issue_handler_sort_issue_priority_weight.inc should have a newline at the end of the file. Also, it doesn't need the PHPDoc at the top of query() -- that's documented in the parent classes. The doc at the top of our custom handler class is all we need.

T) The description for {project_issues}.priority_weight should mention that it's the denormalized value from {project_issue_priority}.weight.

U) The description of the {project_issue_priority} table is pretty weak. ;) "+ 'description' => 'The issue priorities.'," -- How about "The available options for the priority values for issues."?

V) The description of the {project_issue_priority}.priority field is completely wrong:
+ 'description' => 'The priority for this issue after this comment was made.',
- what comment? ;)
- this is really the numeric priority ID key
- while we're at it, we should fix the descriptions for {project_issue}.priority and {project_issue_comment}.priority to mention that those are foreign keys pointing to {project_issue_priority}.priority.

W) project_issue_delete_state_confirm() isn't just for deleting states. That function definitely needs to be renamed and it desperately needs some PHPDoc. I'm also concerned it's using variable names like "$states".

X) Ditto project_issue_delete_state_confirm_submit(). And eek, are we sure this is safe?

+  $column = $form['#column'];
+  db_query('DELETE FROM {' . $form['#table'] . "} WHERE $column = %d", $form_state['values']['sid']);

Seems like if you can inject anything into $form, you can do SQL injection here on both the table and column. Can't we escape_table() and friends here?

Y)

+  $form_state['redirect'] ='admin/project/' . arg(2);

Code style (missing space after =) and ugh, must we use arg() here? ;)

Z)

+  drupal_set_message(t('Project issue status %issue deleted.', array('%issue' => $name)));

This is wrong when you delete a priority. and the '%issue' token never seems to be replaced.
Similarly, this is wrong:

 t('Are you sure you want to delete the status option %name?', array('%name' => $name)),

Similarly, the cancel link brings you back to the status page, not priorities.
I'm wondering if this confirm form is really the best place to try to share code?

AA) [heh, wow, this patch has rung up a lot of problems, not sure I ever had to go past Z before ;)]
_project_issue_priorities_update() doesn't necessarily have anything to do with priorities, so that's a bad name. The PHPDoc here sucks, too. ;) "Mass update batch operation". Uhh, thanks. What do those parameters mean? ;)

AB) I'm not convinced that the merge into admin.inc makes the most sense. Looking at it, there's only a tiny bit of genuinely shared code (that's confusingly named). I think it might be cleaner to keep admin.issue_status.inc mostly as-is, and then add both admin.issue_priority.inc and admin.batch.inc to hold the batch-related helper functions. This isn't a show-stopper -- I'm open to hearing a convincing argument against this. But, it just seems to lump a bunch of stuff into a single file that's only loosely related, without a nice clear sense of what's what. Maybe if all the functions and variables were carefully named, I'd feel better about this, but at this point, it feels like spaghetti...

All that said, this is really great work, folks! Please don't be discouraged by my rigorous review. ;)

THANKS!
-Derek

Re-rolling this tonight

Hm, I have lumped the two together because the delete - replace routine is common and the batch update is common too. Can be kept in a third file ofcourse.

I've covered everything except:

N, O) Haven't touched these items, but will look at it

Q) this may be a long shot, but what about using project_issue_add_auto_followup() to the batch so that affected issues get a comment explaining what happened?

Also, I noticed that the batched SQL for deleting a priority fails to update the denormalized {project_issues}.priority_weight, causing problems when sorting issues.

I made the change to the views sort order, but I'm not sure about it. It feels odd to click on the 'Priority' table header, and have the first sort, result in showing minor issues first. You'd think we want to emphasize the critical issues, or at least match the order the priorities are listed on the priority settings form.

I also changed a few form callback signatures from states to state inline with the singular table/function names.

I'll try to post a patch over lunch.

Here's the latest patch, it could still probably use some more phpdoc but at least the batch is included now. Still haven't touched item N) yet.

First attempt at rolling a patch with git, also adds a newline to the end of admin.batch_confirm.inc

Looked at this again, and still trying to figure out what to do with the missing priorities when deleting a priority (or a status for that matter).

It just *feels* wrong to leave priority id sitting in {project_issue_comments}. I suppose we could batch process these as well. However that will not be able to update any issues that were initially opened with a now, non-existent priority, as {project_issues}.original_issue_data is serialized and could also contain the now stranded foreign key.

One approach I considered was leaving the old items in project_issue_priority and adding a column for deleted, so that project_issue_priority could at least fetch the old name.

The other approach is simply to alter project_issue_priority so that it returns "[deleted]" or some such for non-existent priorities. (project_issue_state could use a similar patch as well)

This at least fixes the case of a deleted priority causing a notice in project_issue_priority() and returns "[deleted priority]" for any priorities that have been deleted.

Fix the sort handler and status

I should really start reading before posting these. ;) The clicksort handler for priority had the sort order revere commented out.

It is look good.
Where it will be release?

@places: Once I get a chance to review/test the latest patches (hopefully in the next few days), assuming all the above problems are resolved and everything is working properly, it'll be committed to project_issue's HEAD branch in CVS, it will be deployed on drupal.org, it will start showing up in the 6.x-1.x-dev development snapshot, and it'll be included in 6.x-1.0-alpha5 or beta1 or whatever our next official release is here.

If you wanted to help speed up the process, you could apply the patch, test it out, and report your experiences here. Did everything work? Did all the settings make sense? What happens when you try to change stuff? Did you get any PHP warnings showing up anywhere? Etc. If you apply this, thoroughly test it, and give a detailed report here, it's extremely helpful towards getting this ready to be committed.

Thanks,
-Derek

+++ issue.inc
@@ -236,8 +236,20 @@ function project_issue_default_states() {
+  if ($priority && array_key_exists($priority, $priorities)) {
+    return $priorities[$priority];
+  }
+  else {
+    return $priority ? t('[deleted priority]') : $priorities;
+  }

This is seriously ugly and a poor API to expose to calling functions.

So I chaned this into two functions, project_issue_priorities, and project_issue_priority($priority).

+++ issue.inc
@@ -235,9 +235,39 @@ function project_issue_default_states() {
+/**
+ * Return all available issue priorities, sorted by weight.
+ *
+ * @return
+ *   An array of priorities keyed by id.
+ */
+function project_issue_priorities() {

+++ issue.inc
@@ -235,9 +235,39 @@ function project_issue_default_states() {
+/**
+ * Return the name of a priority for a given id.
+ *
+ * @param $priority
+ *   The id of the priority.
+ * @return
+ *   The name of the priority.
+ */
+function project_issue_priority($priority) {

Add comments to update functions

This fixes a number of notices, and adds some tests for the issue admin form (more tests coming). This also fixes an issue where the empty row displayed on the admin form, had the same weight as the heaviest priority. This caused the new priority to have the same weight, which could cause some weird sorting issues when two priorities have the same weight. I did this by adding a +1 (I know, ugly) to project_issue_admin_priority_form() on lines 80 and 81. This should be fixed and sorted out in the submit handler, so that users with javascript off, and submitting priorities with identical weights don't mess with sorting.

Also, the tests are not working as expected due to an issue with calling batch API from simpletest and maintenance-page.tpl.php.

Even more tests, talked to grendzy, and he feels that the form weight priority thing is not a big deal as other drag and drop forms have this issue. I've changed the code a bit and added a comment there to make it clear what is happening.

Even more tests. I'll work on this some more tomorrow, but in case I get in late, here's a good start.

Super cool, thanks! I haven't tested this, but a skim makes me wonder about these:

-    'page arguments' => array('project_issue_admin_states_form'),
+    'page arguments' => array('project_issue_admin_state_form'),

Yes, it's fixing an inconsistency, but:

A) That's totally unrelated to the issue at hand (well, other than that you're touching some of that for _project_issue_batch_update() in the submit handler).

and

B) It's just going to add even more conflicts with #353248: Standardize terminology on either 'status' or 'state', not both.

I'm willing to go forward with this if you're going to reroll for #353248, but I'm slightly concerned about the churning and extra work. Thoughts?

Also:

C)

-    'page arguments' => array('project_issue_delete_state_confirm', 4),
+    'page arguments' => array('project_issue_delete_state_confirm',  4),

OMG, extra whitespace! ;)

D) Can you roll this without the whitespace-only hunks? I just nuked those in a separate commit, since I tested that that commit wouldn't conflict with #353248 and b/c when this patch lands, I'd like all the hunks in the commit to be relevant to the feature discussed here, so as not to confuse anything.

E) It'd be nice if assertAdminPrioritiesForm() had a PHPDoc comment. All custom test assertions we write in Project* should say what they're asserting and how.

F) This code-style spacing is wrong:

$post['priority[' . $key .'][name]']

Technically, should be:

$post['priority[' . $key . '][name]']

However, in these cases, I generally find this more readable:

$post["priority[$key][name]"]

G) It's not obvious to me why testProjectIssuePrioritySettings() uses 'major' for the first custom priority, then a random string for the others.

H) This:

+    // Check that the issue priority is displayed correctly.
+    $this->assertText($priority_name, t('Custom issue priority is displayed correctly.'));

Should use assertIssueMetadata() instead. Same a few lines down. Although, this makes me believe that assertIssueMetadata() could be extended to have an optional final argument for what assertion text to use, so you can continue to have these really nice specific assertion messages so you see WTF the failure would be.

Otherwise, this is looking *brilliant*!

Thanks!!!!!!!
-Derek

This should fix everything that you've mentioned, but I haven't had a chance to test the reversion of state/states. I think I caught all of those, but please double check that.

I gave this another thorough review. I had to make some changes: there was a place where we weren't prefixing DB tables, and otherwise mostly cosmetic changes and code cleanup. Attached is the patch I committed to HEAD and the interdiff. Sorry for the large hunks in includes/admin.issue_priority.inc -- part of it was just reorganizing the file so that the order of the functions made sense (form builder, theme function, submit handler, delete confirm form builder, delete confirm submit handler).

YAY!!! ;)

Now we just need to deploy to d.o... stay tuned.

deployed on d.o, but the batching DB update to populate {project_issues}.priority_weight didn't work. Back to the drawing board on this. We can test the updates themselves on d6.p.d.o to make sure this is solid. The reason this is going to be a problem is when we add a new priority level, probably the same batch is going to fail in the same way at that point. So, we need to debug and resolve this before we can plow ahead with setting up a "major" priority on d.o.

I was unable to recreate the problem with the scrubbed DB that I have access to from the redesign. Although it only has 57341 rows in {project_issues} (I believe that d.o has closer to 300k).

Also in the process I realized that there is a missing index on {project_issues}.priority_weight.

This adds an index on {project_issues}.priority_weight. I've retried the batch update function from update.php and the priorities administration form, and I can't recreate the error with my scrubbed (only 57k issues) DB.

To test this further, I think I'll need access to d6.project.drupal.org.

Here is an update to the batch function, I need to test this with status updates, and project_issue_update_6004, but it seems to work fine from the priority administration form.

I tested this patch on the project drupal test site & it worked properly: http://d6.project.drupal.org/node/286653#comment-2307493.

Filters & sorts worked also.

Hopefully after a few more reviews, this can get in!

Just wanted to confirm that I also played around with this on the test site and everything went smoothly. Didn't see any bugs.

Following up here to document where things are at.

On April 26th dww deployed the patch here to drupal.org and attempted to run the update functions and project_issue_update_6003() worked fine, while project_issue_update_6004() failed, leaving the data on drupal.org itself inconsistent. In order to recover dww ran a query similar to "UPDATE {project_issues} SET priority_weight = priority" and later something along the lines of "UPDATE {system} SET schema_version = 6004 where name = "project_issue" to resolve the linger update that wasn't working.

All of this stems from _project_issue_batch_update() failing on drupal.org database, and neither dww nor myself were able to recreate this locally, even myself with partial d.o dump (see #50 above), however I was able to recreate the problem when testing on d6.project.drupal.org with a database dump from Nov. 2009.

The patch in #52 was developed on d6.project.d.o and I've just completed testing it on scratch.drupal.org where it is working fine for priority updates, status updates, and I also tested rerunning project_issue_update_6004().

For getting this on drupal.org, I've also opened #856850: Enable major priority for issues.

As far as I'm concerned, this is RTBC, both #51 and #52.

patch in #51 looks good. patch in #52 has some issues w/ the code comments:

1. says 100 are processed, when 500 actually are
2. the $context doc has a few problems, 'min' is no longer present, and it's actually $context['finished'], not $context['sandbox']['finished']
3. // Avoid COUNT(*) like hell. Or not. -- kill this, it's just noise.

once those are fixed, i believe this can hit RTBC.

Added a few notes to how the argument processing works

committed #51 and #57 to 6.x-1.x-dev, thanks for all the work and testing!

now over to #856850: Enable major priority for issues to finish this up...

I installed project_issue 6.x-1.x-dev to get the custom priority field but now the priority field is empty.

Project: 6.x-1.0-alpha4
Drupal: 6.20

You probably didn't run update.php yet. In the future, please just open a new issue if you have a support request about something, instead of re-opening an old issue that's already closed.

Sorry about appending to the old issue, and thanks for the followup.
I did indeed run update.php but it didn't change anything. Removing, uninstalling and then reinstalling doesn't help either. I even tried freshly installing the stable release then copying the files from the 6.x-1.x-dev over and then running update. I gave up and manually edited the .module and .inc files from the stable version to add my new priority fields. (Seems to work but not sure how listing, searching displaying issues will behave yet.)