OK, submitting this one as new as per pulsifer's recommendations at this issue. Sorry details are sketchy, but I'll try to clarify when I get chance to look at this properly.

In short, the project drop down on the create/edit/follow up issue form isn't being filled. A quick debug told me that _project_projects_select_options() was returning an empty array, and the query:

'SELECT p.nid, n.title, d.name FROM {project_projects} p INNER JOIN {node} n ON n.nid = p.nid LEFT JOIN {term_node} t ON t.nid = n.nid INNER JOIN {term_data} d ON t.tid = d.tid INNER JOIN {term_hierarchy} h ON t.tid = h.tid WHERE n.status = 1 AND p.issues = 1 AND d.vid = %d AND h.parent = 0 GROUP BY n.title ORDER BY d.weight, n.title'

(where %d is replaced with $vid for the projects vocabulary).

Removing ' AND h.parent = 0' fixes the problem, though I am unsure why just now. A couple of comments from pulsifer:

"It seems to assume that the "Project" keyword would be a root key (parent = 0), but it is not when used with Drupal v4.7... The easiest fix I found was to disable project's use of the taxonomy module (see above about replacing 'taxomony' with 'taxonomyXXX')"

Comments

pulsifer’s picture

pulsifer CreditAttribution: pulsifer commented

That should say: "It seems to assume that the categories under the "Project" taxonomy would be root keys...". The problem is that they are not root keys, they are one level down from the root.

In order to make this query work, it needs to look to see if the term one more level up is a root. That would involve another join on the term_heirarchy table. Instead of:

...INNER JOIN {term_hierarchy} h ON t.tid = h.tid WHERE n.status = 1 AND p.issues = 1 AND d.vid = %d AND h.parent = 0 GROUP BY...

it would be something like:

...INNER JOIN {term_hierarchy} h ON t.tid = h.tid INNER JOIN {term_hierarchy} h2 ON h.parent = h2.tid WHERE n.status = 1 AND p.issues = 1 AND d.vid = %d AND h2.parent = 0 GROUP BY...

Notice its now looking to see if h2.parent = 0.

I haven't yet tried this because for my immediate purposes I'm not using the taxonomy module -- i.e., Project has some alternate code paths that kick in when taxonomy is not present, and those work find.

Another fix, BTW, is to only have one level of keys in the Project taxonomy (instead of two levels). This solves that query, but then some of the user interface related to project categories doesn't work.

pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented
Priority: Normal » Critical

I can reproduce this on three instances of project module, all latest HEAD with beta 5, one being a totally clean install of core/project module. Marking critical as this prevents:

  • new issues being created (where validation will fail);
  • existing issues being edited (where pid -> <all>); and
  • existing issues being followed up (where validation will fail).
pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented
Priority: Critical » Normal

Have just updated our project module this evening, and I'm not getting problems with this any more. Will test/check this out in more depth tomorrow, but I reckon this could be sorted?

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

Just tested with RC1 (project.module 1.233 dated 03/27/2006), and the problem is still there.

pfaocle’s picture

pfaocle
Primary language English
CreditAttribution: pfaocle commented
Priority: Normal » Critical

Yep, still a problem with RC3 and today's CVS project module.

fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

Still there in Beta4 with project.module v1.238

Removing the h.parent=0 test still fixes the issue momentarily.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Assigned: Unassigned » dww

bump: i've been looking a lot at this function recently due to http://drupal.org/node/74995. of course, thanks to http://drupal.org/node/60627, project no longer requires a taxonomy, even in 4.7 or HEAD. therefore, i don't believe this issue is still a bug. if there are no terms in the auto-generated project taxonomy, project_projects_select_options() doesn't hit any of the taxonomy-specific code, and all projects are returned. if you've started defining terms in that taxonomy, then (i believe) everything works ok.

can someone please verify that the kinds of problems you were having are now resolved? my testing and review of the code seems to indicate this is no longer a bug...

thanks,
-derek

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Active » Closed (won't fix)

after a fairly length IRC session w/ fgm, i've decided this isn't a bug, and there's nothing here to fix...

the early 4.7.x versions of project didn't have the whole taxonomy thing ironed out to be very user friendly. it was mostly added for d.o, and even then, folks had trouble classifying their modules. however, now that http://drupal.org/node/60627 and http://drupal.org/node/64221 are fixed, everything works just fine...

  • if you don't create any terms in the project taxonomy, all projects (that have the issue tracker enabled) are included in the list
  • if you start defining terms, any 1st level term will be used to group projects in the list, and the term itself will show-up as a header.
  • once you define 1st level terms, the create/edit form for project nodes *forces* you to select a *single* top-level term (via a set of radio buttons), so it's impossible to have projects that don't belong to one of the top-level terms, or to have projects that belong to more than 1. this ensures that every project is listed exactly once in the list, under the appropriate top-level category.

the only reason the folks in this issue are having any trouble is that a) they were early adopters of 4.7 project module b) for better or for worse, they decided to use the project taxonomy, c) they only selected 2nd level terms for their projects, and d) they haven't tried to edit any of those project nodes since upgrading to a more recent project.module.

if you use the current code, all you have to do is:
a) remove all terms from the project taxonomy (if you don't want any of the taxonomy-based behavior)
or
b) edit each of your nodes, and the new form will force you to select a top-level term for each one. once they belong to a 1st level term, they'll show up in the list.

if we did what they're suggesting, and take out the check that the term we're using is top-level, things would explode into insanity on a site like drupal.org. all the different possible sub-categories of "modules" would show up in the list, it's not clear which sub-category (since a module can be in more than 1) a given project would be listed under, etc, etc.

therefore, "won't fix".

thanks,
-derek