project* namespace bugs in $node

subscribing. I wrote a patch for casetracker (renaming table columns and vars to no longer use pid but ctprid). I'll see what the results of this discussion will be, and will roll another casetracker patch using the same solution as what you decide over here. Thanks Derek!

The next step for those not included in this dev conversation is...? I imagine its wait until the next release, is this accurate?

Also, may you have any odd jobs a not-so-elite coder can help with?

Any fix/patch?

DWW writes: or, you could roll a patch against project_issue that does everything via $node->pi_xxx or $node->project_issue_xxx instead of just $node->xxx directly. however, if you do that, please post the patch at http://drupal.org/node/98278

OK! I'll stop being lazy and play around with fixing this pid issue in project_release.

Mind you, I'm just searching and replacing, yet my releases Now Work *knock on wood*. Simply replaced pid for pro_id. Also changed MYSQL table project_release_nodes pid to pro_id.

Patch attached (note I'm using 5.x-0.1-beta)

A pitty you didn't use the best way, which is to use a proper namespace per module inside the $node object as mentioned by dww. Could you not update your patch accordingly? I'm sure this is the way to go, and this is the way which would be unanimously accepted!

I am busy reading Pro Drupal Development (excellent, really excellent) but noted also there in the examples variables get just assigned without worrying too much about possible other modules using the same variables, like on p 209 where global variables are created $last_change and $last_id. This really is an issue which deserves the attention of all developers, and it should probably be mentioned somewhere at the start of any developer's manual: a standard way of defining variables used by a module, global variables or variables inside other objects like $node.

A pitty you didn't use the best way, which is to use a proper namespace per module inside the $node object as mentioned by dww. Could you not update your patch accordingly? I'm sure this is the way to go, and this is the way which would be unanimously accepted!

tbh I'm not sure what dww's and your comment about 'proper namespace per module' exactly means. What I've been doing is replacing pid w/ pro_id. Are you saying that I can simply search and replace pid w/ project_release['pid']?

Anyhow, until I understand the name space game a little better here's another patch for project.module to work with the above project-release module changes of pid to pro_id as the project was having issues displaying the correct release on the */project page.

What dww means (and me too) is that it looks much cleaner if every module doesn't pollute $node arbitrarily, but instead keeps all its variables properly stored in a separate namespace, like $node->module_name[var_name], so I think yes, simply search and replace pid w/ project_release['pid'].

you postponed #148420 so it looks like we'll just take care of it here.

here's a first pass on the project module. it still needs lots of work.

dww asked if I could find a regex to fix some of these namespace issues. I've identified cases where there are potential namespace conflicts. I went throught the schemas and pulled any non-node-native fields that are potentially assigned to node objects. Here's what I've found so far...

fields from {project_projects} to be partitioned as $node->project['<field>']
uri|homepage|changelog|cvs|demo|release_directory|version|mail|documentation|screenshots|license

fields from {project_issue_projects} to be partitioned as $node->project_issue['<field>']
issues|components|help|mail_digest|mail_copy|mail_copy_filter|mail_copy_filter_state|mail_reminder

fields from {project_issues} to be partitioned as $node->project_issue['<field>']
pid|category|component|priority|rid|assigned|sid|file_path|file_mime|file_size|original_issue_data|last_comment_id|db_lock

Comments are also a potential problem because they're merged in hook_comment. This could clash with other modules, so I'll go ahead and find those cases too.

fields from {project_issue_comments} to be partitioned as $node->project_issue['<field>']
component|category|priority|assigned|sid|pid|title|timestamp|original_issue_data

I'm going to attempt to auto replace and add tracing comments to these this evening.

If anyone sees any conflicts or holes in the above list, let me know. This really seems like it could be a best practice that should be added to the handbook pages on node-type modules.

Adding project releases...

fields from {project_release_nodes} to be partitioned as $node->project_release['<field>']
pid|version|tag|file_path|file_date|file_hash|rebuild|version_major|version_minor|version_patch|version_extra|

Here is the first of two bulk-replacement patches.

Changes are marked as follows...

// MUNGE: $node->assigned
// MUNGE: $node->assigned
// MUNGE: $node->assigned
        $node->project_issue['assigned'] => ($node->project_issue['assigned'] && ($account = user_load(array('uid' => $node->project_issue['assigned']))) ? $account->name : t('Unassigned')),

And the second...

I ended up not using a script. I did it all with regex replace in komodo. But I can post the basic regexs here...

Here's the find pattern:

(?=^(([ \t]*)((.*)(\$node)->(uri|homepage|changelog|cvs|demo|release_directory|version|mail|documentation|screenshots|license)([a-zA-Z0-9_]*)(.*))))((?!//).)*$

This finds lines containing an assignment of $node->property where property matches one of the OR list. I pulled the OR list from the .install files and excluded node-native fields like .nid. It excludes comment lines so it can be run multiple times. The disadvantage to this pattern is that it won't find multiple matches per line, so you have to run it multiple times until there are no more matches. I think there are a few extra parenthesis, but it seems to work. The modules installed on the first try.

I replace that with something like this:

// MUNGE: \4->\5\n\1\3\4->project['\5']\8

That insterts a comment line saying what was replaced, then on the next line rebuilds the line from the extracted parts, inserting the project array into the assignment.

I also wrote one to remove all but the field name from the copied and pasted schema definition. Just copy and paste the fields you want.

^([ \t]*)([a-zA-Z0-9_]*)\s(.*)$

and replace with

\2|

It could easily be a perl script, but it seemed easier to do manually at the time.

I'm going to assign this to myself it no one objects. I've re-run my bulk replace against head and going through each change now. The regex was definitely not fool proof, but it was a good start. If anyone gets impatient, I can post the latest patch, but it's broken in a number of areas.

It brings up an interesting point... Since loading properties into the node object in hook_load or hook_nodeapi is accepted practice, any module could easily create this conflict. We could try to automatically fix, with a "namespace" array or object for each module, but... Creating a "namespace" array or object would break most hook_validate implementations because hook_validate doesn't correctly build the node object with the namespace variables. hook_validate assumes that the node's structure is identical to the node form's structure. I haven't tried setting the form #tree property to true yet. That might help make hook_validate more agreeable. To get around this for project, I chanaged the hook_validate call to a standard validate($form_id, $form_values) function.

Yeah, the first big breaker I saw was the hook_validate stuff. It doesn't currently have enough smarts to 'just work' without big changes to 5.x modules. I'll be working on this more today. I've gotten through project creation/editing and issue creation/editing so far,

I spent several hours working on the namespace array fix proposed initially and ran into one huge issue with the FAPI. I've summarized the problem here for reference, but I'll cover it below too. I discussed this with hunmonk on IRC last week.

Hunmonk proposed for project, simply prefixing the variable names with project_ so we end up with $node->project_pid. And so on... This will work well for the time being, and I'm all for it.

Thoughts? Here are the nitty gritty details for the curious...

When editiing or creating projects, project_issues, or any other node types, the FAPI automatically builds a node object for processing by node_save who's structure is determined by the supplied form tree. This means you'll typically get a flat node object coming into node_validate and node_save - even if you have created a namespace array in hook_load. There are two code paths for node object creation. One for loading and one for "reconstituting" forms.

You can create a hierarchical structure in the form tree by setting the #tree property to true in the appropriate places. The problem with this is that #tree affects entire branches, and can not be restricted to leaf nodes and leaf parents. This means that with #tree=true, fieldsets are always fully expanded and clutter the node further. Project, for example, has many fieldsets to group the UI.

One ugly workaround is to use the #parents property to manually specify how the FAPI builds the node structure. You can then place any module properties exactly where you want them in the $node object. This is ugly because it is not automatic, and will require a certain degree of thought for every property on the form.

Chris.

criznach, I think you can work around the issue you're describing by inserting a $form['project'] with with no type and #tree = true. Its children would be the fieldsets and would have #tree = false... wouldn't that do the trick? I've gotten this working in the past but don't recall the exact details off the top of my head.

1. it seems like a bad idea to fight fapi here with weird hacks like that
2. seeing as we handle namespacing issues for modules with modulename_hookname, i think modulename_varname makes a fair amount of sense
3. while i can see benefits of having the array structure, we don't even know yet how core will solve this problem. solving it in the least complex way possible now seems like a good interim step, until core provides a more foundational fix.

drewish: I think what I found was that a #tree=true anywhere in a branch makes that entire branch tree expand. I tried it reluctantly, because that solution - like setting #parents - adds a lot of maintenance headaches (IMHO).

I hope to get back to this over the weekend. I'd made good progress up to this issue, and now I think it should be a pretty straightforward process to get beyond. It's great to dive head first and get ankle deep in a good sized project that's not written entirely by myself. :)

I made some progress on this over the weekend. Project and Issue creation fields are updated and somewhat tested. I'm currently hung up on the comment system and wondering if it's even necessary to namespace comment fields at this point. My goal was to cover all of the project, project_issue and release, modules for consistency, so I'll plug away for now unless it's more important that we just get this committed.

please convert the comment stuff as well -- we want consistency. in particular, i'd like to get rid of the #tree of $form['project_info'], which we can do once we stop colliding w/ comment module's pid.

Ok, that's right, I do remember recognizing that and replacing the #tree with a prefixed variable name. So maybe the comment code needed a workover anyway. I'll keep plugging away.

Hello criznach, how's progress?

I rolled a very hacky patch that solves the issue with issues: http://drupal.org/node/198545#comment-673804

I'd like to help with this proper fix if I can.

for both book and menu for D6, all the data is stored in a single array on the node, so unless something major changed in FAPI, I don't think it's that hard. However - all the form elements are within one fieldset for book and menu respectively.

I was away for the holidays and busy with work, so I haven't had a chance to work on this for a while. I'll try and make some time to look at the checkins since I started and try to roll a partial patch. I think the ultimate goal is to encapsulate the project properties in arrays just like what pwolanin mentioned about book and menu. That's where my work was headed.

subscribing

Here is my project and project issue work from several months back. It may take some work to get it up to speed, but project nodes are mostly functional, issues are mostly functional, releases and notifications are partially functional. I'm flying out Friday morning, so won't be able to sprint, but hopefully this helps.

Later,
Chris.

@criznach - thanks for the starting patch

patch for project.inc (project.module seems to have nothing that needs to change)

Looks good, form is set off correctly and node has project array with fields. Updating works correctly.

Leaving status unchanged cause I'm not sure if the code needs more work.

needs review

Great! I just got home to Montana from Boston. Were you able to use what I posted, or did you have to start over?

@criznach - I just started over, since the search-n-replace was easy.

#234911: Editing a release disassociates it from a project has been marked a duplicate of this issue.

Subscribing. I applied the patch and it definitely did not fix my problem in bug report #234911: Editing a release disassociates it from a project.

Well, this patch is not complete - should probably be CNW. I got the project module itself, but not other files that may load the project node.

At the Drupalcon Boston code sprint pwolanin and I discussed the project_release module and I finally have a patch to attach. This patch also needs some work because I don't think version is getting picked up correctly and saved. Peter had asked at the sprint that I at least get what I have so far up, so here it is.

This should probably be rolled into the patch for project.module but I think it needs some work still which I hope to get to soon.

Here's an updated version that:
1. Corrects a few spots in issue.inc that pwolanin missed
2. Includes a few changes to the project module that were committed since the patch in #34
3. Incorporates coltrane's patch in #43 into all of the other changes.

I initially tested the project changes on a local site and everything seems to be good. I have not tested the project_release changes at all.

Setting back to CNW because I'm getting errors in node_load() when I go to a URL such as drupal/node/111/edit where node 111 is a project_release node.

Also, I think we still need to fix the $node object usage in the project_usage module, which is also part of the project module.

From the patch in #44 there were two extra placeholders in the INSERT in project_project_insert() so here's a reroll without those. Also, I didn't get any errors after creating a release node but I'm working with the cvs module off, could that be the difference?

It looks like the errors I described above are due to the cvslog module, so we'll eventually need to fix that module as well. But that'll be in a separate patch.

Sorry, setting back to CNW because of project_usage

Applied patch to release version, no joy. (had to do some lines manually) in fact files are no longer attached when creating releases. Going to try dev version.

@drinkypoo: In most cases, patches will be rolled against code in the -dev branch, not against official releases. In the case of this patch, I don't believe anything has been committed to the project module since it was last re-rolled, so it should apply without needing any manual changes, unless you're running an otherwise patched version locally.

Also, just in case you aren't aware, the -dev branch is in development and not necessarily stable, so I wouldn't advise that you use it on any kind of production environment.

Finally, when you follow up to an issue with something like "Applied patch to release version, no joy", it doesn't really help us much. It would be great if you could explain what "no joy" means. Do you mean that the patch breaks your site, that the patch appears to not solve the $node object namespace collision, or something else?

@all: I have not tried doing much other than browsing pages with this patch applied. We should definitely check out what drinkypoo says here: "in fact files are no longer attached when creating releases".

@aclight: My apologies, I was going to go off and test against -dev but I got busy (still don't have time now.) So I'll go into more detail here: The current patch does not solve my problem in #234911: Editing a release disassociates it from a project, which is marked as a duplicate of this problem. In addition, as I reported above, when creating a release, the file is no longer attached.

This is the result of applying the patch to the current release version. Every hunk applied cleanly except for some which were simply not in the same place (but the code didn't appear to have changed at first glance - some of the lines in question are like 300 characters long and thus extremely hard to read. Here's what happens when I apply the patch to release:

$ patch -p0 < /home/drink/Desktop/drupal/98278_project_node_namespace_46.patch 
patching file project.inc
Hunk #14 FAILED at 312.
Hunk #18 FAILED at 390.
2 out of 19 hunks FAILED -- saving rejects to file project.inc.rej
patching file project.module
patching file release/project_release.module

(project.inc.rej attached)

From the .rej file and the .inc file it looks like the code is only two lines away in the current release. But of course, I haven't checked to see what else changed.

#239405: unable to edit project issue - after edit project empty in issue was marked as a duplicate of this issue.

#283779: problem with sorting after editing project release - urgent has been marked as a duplicate of this issue.

I have found that pathauto also conflicts with project release.

I'm really confused at the moment, what should I do to make sure that the releases can be associated to their respective projects at the moment?

Which patch should I use?

@watbe: I believe that all of the patches here are incomplete and/or no longer apply, so I don't recommend using them as is. I haven't used pathauto, but perhaps it's possible to disable it for certain node types? If so, I recommend that you disable it for project, project release, and project issue nodes, since I believe that users have had conflicts with all three of these node types.

OK, thanks for clarifying.

I can't seem to disable pathauto for certain nodes so I'll post an issue in their support queues.

@watbe

I'm using pathauto with project* and while it's quirky, it's working for me.

For project nodes, it creates a duplicate URL, but once I delete the extra one, the one created for short project name works fine. For project issues, I just used the pattern issues/issue[nid]. Not elegant, but not the mangled mess you get if you try to use titles, either.

There's already work being done to improve project* interaction with pathauto at #229063: project* should support tokens for pathauto and others. You might want to check it out before opening a new issue somewhere else.

Micah

Ok, sounds good, I'll try it out now.

Is there anyway to get project/[projectname]/issue[nid]?

#46 applies to 5.x-dev with a few offsets.

Testing and updating the patch.

Updated to 5.x.-dev.

Unless I'm mistaken, the project_usage module hasn't been fixed in this patch. Is there nothing there that needs to be changed?

As a note, we really need to fix this in project_issue at the same time we fix project, or otherwise project_issue won't work with project HEAD for some time. In addition, if we're going to actually fix this in the 5.x version then that's going to hold up the port of pi for that much longer, as well as mean that I have to fix this in the D6 port now. It's going to be a real PITA to fix this either way, however.

Right. The current patch doesn't touch either Project Issue or Project Usage -- and probably needs to, though a comment above says to hold those for a separate patch. We also need to rename $node->components to $node->project_issue_components or put it inside the $node->project_issue array.

Attached patch adds a few fixes to Releases, putting all release information into $node->project_release.

What is the priority of fixing this issue? I jumped on it this morning thinking it was something fixable -- though painful.

I'll take a look at Update and Issue, then.

IIRC, the plan we discussed at Drupalcon was to get this fixed during code sprint day, because it was something that needed to be fixed in a lot of places and would totally require other patches to be rerolled. Some progress was made during the sprint, but it never happened. The post-drupalcon absence of dww and hunmonk from the queues for a while made me think that fixing it before porting would just lead to the port taking a very long time, if we needed to wait on namespace to get fixed, so I started to work on the port, since that's something I actually care about (namespace is a big problem, but not one that affects any of my sites).

I don't mind too much if we fix it now rather than later, but if we are planning to fix it soon then I won't consider starting the pi port until it's fixed. However there's still a lot to do with the project release and project update ports anyway, so that's not a problem right now.

I would say that if we can finish the patch this week, then let's barge ahead. If not, apply to 6.x only and leave it broken in 5.x.

Project Usage does not use any $node data.

The project release scripts _might_ need some attention. I don't quite follow what is going on there.

project_release_update.php performs some node handling.

function convert_release($old_release) converts data into a $node object and runs node_save, so it may be affected by these changes.

project_release_nodes.php has no node handling, actually. It pulls its data from the db. Same with project-release-create-history.php and

Note: I am about halfway through with Project Issue -- big change there, since it used to use an object and now it is an array.

Question: Not sure what to do about project_issue_metadata_changes()

OK. Attached are three patches for the project, project_issue and cvslog directories.

I am running these and have caught the obvious errors. I am most concerned about issue mailings and cvslog integration, but the changes to arrays seem to work.

The $node object is now populated with the following arrays, where applicable:

$node->project <-- information about the project
$node->project_issue <-- note that this is now an array, and the 'components' is part of that array
$node->project_release <-- information about the release
$node->cvs <-- information about cvs integration

Here's a cvslog patch that actually applies properly. The first hunk wasn't working right for me. Otherwise nothing changed.

I took a look at all of the patches and have a few issues with them. I tested functionality some, and haven't run across any problems.

As for getting this in, we might just want to commit it to HEAD (after review) and then work out any problems that arise there. The sooner this gets in, the better, because rerolling these patches each time something else gets in is going to be a pita.

cvslog patch: no problems found, other than the one fixed in attached patch.

project issue patch:
1. It looks like you didn't revert one of your other patches from another issue.

-  if (!file_check_directory($directory, 0)) {
+  if (!file_check_directory($directory, 1)) {

and

-  file_check_directory($directory, FILE_CREATE_DIRECTORY, $form_element['#parents'][0]);
+  file_check_directory($directory, FILE_CREATE_DIRECTORY, $form_element['#parents'][0], 1);

2. I'm not sure what this is doing here:

-              $project = node_load(array('title' => $node->$text, 'type' => 'project_project'));
+              $project = node_load(array('nid' => $node->text, 'type' => 'project_project'));

project patch:
3. Why are we moving the title and body fields out of the project fieldset? I know those properties need to stay in the $node object directly (not in $node->project[]), but I don't think that means we have to move them out of the fieldset as well.

-  /* Project properties */
-  $form['project'] = array(
-    '#type' => 'fieldset',
-    '#title' => t('Project information'),
-    '#collapsible' => TRUE,
-  );
-  $form['project']['title'] = array(
+  $form['title'] = array(
     '#type' => 'textfield',
     '#title' => t('Full project name'),
     '#default_value' => isset($node->title) ? $node->title : NULL,
     '#maxlength' => 128,
     '#required' => TRUE,
   );
-  $form['project']['body'] = array(
+  $form['body'] = array(
     '#type' => 'textarea',
     '#title' => t('Full description'),
     '#default_value' => isset($node->body) ? $node->body : NULL,
@@ -91,11 +85,19 @@ function project_project_form($node) {
     '#rows' => 10,
     '#required' => TRUE,
   );
-  $form['project']['format'] = filter_form($node->format);
+  $form['format'] = filter_form($node->format);
+  /* Project properties */
+  $form['project'] = array(
+    '#type' => 'fieldset',
+    '#title' => t('Project information'),
+    '#collapsible' => TRUE,
+    '#tree' => TRUE,
+  );
+

4. I don't see where this comment and the cache_clear_all() was removed in the patch, so why are they here?

+      // Finally, clear the cache for the release table on any of these node
+      // operations, since what we want to display might have changed, too.
+      $cid = 'table:'. $node->project_release['pid'] .':';
+      cache_clear_all($cid, 'cache_project_release', TRUE);

Probably needs some cleaning -- I have lots of patches flying around :-). I agree we should commit to HEAD and then test.

Notes:

1) Easily removed.

2) This logic didn't make any sense to me as written, since $node->text in that instance is the project pid (a node id) and not a title string. So this seemed like faulty logic that I corrected.

3) I don't have an answer. That was inherited from pwolanin's patch, I believe.

4) Not sure.

I'll have to resync with HEAD, apply the patch and fix.

Patches cleaned and re-attached.

Careful with cvslog -- HEAD of that module is D6, so the patch applies to the DRUPAL-5 branch. Other patches are against HEAD.

Issues above:

1) Fixed.
2) Original logic restored -- though I suspect a bug here.
3) Returned to the project fieldset. Watch that the #tree assignment doesn't cause issues. Seems fine.
4) Remnant from another patch, removed.

I thought it was just Eclipse that put in this stuff:

-// $Name:  $
+// $Name: DRUPAL-5 $

I've never seen those lines in any of the patches I create on my system (not using Eclipse). Do they actually serve a purpose? If so, what is it?

Re #2: I haven't looked at this closely, but you may be right. If so, it's best to create a new issue and not hide it in this issue.

That top line is a remnant from the HEAD/DRUPAL-5 mixup and does not belong in the patch. Revised.

The secondary bug is now at #293882: Project lookup error: mail.inc.

/me learns something new everyday.

rerolled project* and project_issue patches as some hunks didn't apply any longer. I do not understand the $node->text business in project_issue/mail.inc which was supposed to be fixed in #293882: Project lookup error: mail.inc. So please check this section in the patch as I'm not sure to understand the behavior here.

The cvslog patch in #76 still applies.

Reroll of cvslog patch

The previous version (and possibly earlier versions) of the project patch (from #80) had this:

 function project_release_load($node) {
-  $additions = db_fetch_object(db_query("SELECT * FROM {project_release_nodes} WHERE nid = %d", $node->nid));
+  $additions = db_fetch_array(db_query("SELECT * FROM {project_release_nodes} WHERE nid = %d", $node->nid));
   // Add the API term associated with the release.
   $api_vid = _project_release_get_api_vid();
   $api_tid = db_result(db_query("SELECT tn.tid FROM {term_node} tn INNER JOIN {term_data} td ON tn.tid = td.tid WHERE td.vid = %d AND tn.nid = %d", $api_vid, $node->nid));
-  $additions->version_api_tid = $api_tid;
-  return $additions;
+  $additions['version_api_tid'] = $api_tid;
+  return array('project_release' => $additions);
 }

hook_load() is supposed to return an object, so I don't understand why it was modified to return an array.

Instead, the attached patch does this:

 function project_release_load($node) {
-  $additions = db_fetch_object(db_query("SELECT * FROM {project_release_nodes} WHERE nid = %d", $node->nid));
+  $additions = db_fetch_array(db_query("SELECT * FROM {project_release_nodes} WHERE nid = %d", $node->nid));
   // Add the API term associated with the release.
   $api_vid = _project_release_get_api_vid();
   $api_tid = db_result(db_query("SELECT tn.tid FROM {term_node} tn INNER JOIN {term_data} td ON tn.tid = td.tid WHERE td.vid = %d AND tn.nid = %d", $api_vid, $node->nid));
-  $additions->version_api_tid = $api_tid;
-  return $additions;
+  $additions['version_api_tid'] = $api_tid;
+  $release = new stdClass;
+  $release->project_release = $additions;
+  return $release;
 }

In addition, there was one replacement that wasn't included:

-  _project_release_form_add_text_element($form['rel_id']['version'], t('Version string'), $release->version, $is_edit, $admin, true, 20, 255);
+  _project_release_form_add_text_element($form['rel_id']['version'], t('Version string'), $release->project_release['version'], $is_edit, $admin, true, 20, 255);

Attached fixes project_project_load() and project_issue_load() just as I fixed project_release_load() in #83. It also fixes a call to project_release_load() in issue.inc that was producing fatal errors.

It looks like returning an array from hook_load() functions was first introduced by the patch in #35. It's not at all clear to me why that was being done.

Updated versions of all 3 patches. There were a bunch of places in cvslog where the corrections had not been made. Also modified the forms created/altered in project.inc and cvslog.module to work correctly. I probably still need to investigate whether similar changes for pi and pr are necessary.

The patches from 85 do not cleanly apply against project-5.x-1.2 or the latest project_issue-5.x-2.x-dev (2008-Nov-17). I was able to manually apply changes for the failed hunks to project.inc, but issue.inc gets a whole lot more complicated.

The hunk for issue.inc at line 760 is supposed to change $node->assigned to $node->project_issue['assigned'] in the creation of the $assigned array, but in current versions of issue.inc, this line is a call to project_issue_assigned_choices instead. I was unable to figure out if any changes need to be made to that function.

The other failed hunks in issue.inc are all pretty easy to figure out, but this one is a show-stopper for me to test.

dww, your solution in #92 is exactly what i do in most of my modules... technically nid and vid, but the point is the same.