Fatal errors & validation errors when generating issues.

This patch appears to have tabs not spaces or some other whitespace badness. Can you fix that and re-post?

Thanks,
-Derek

Tab- & whitespace-badness fixed, attached is a new version of the patch.

Thanks for re-rolling -- much better. Something like this is definitely needed. When I apply the patch, I can certainly create issues with project_release disabled, which is a great start. ;)

However, sometimes when generating issues with the patch applied and project_release enabled, I get error messages like "Invalid choice selected" or "You have to specify a valid version" so I think something about the patch is still broken. :( I've tried generating issues without the patch applied while project_release was enabled, and I haven't yet hit an error like that. It's not consistently failing, so I don't know exactly what's going on here. If you have time to try to debug this with project_release enabled and see what you can come up with, that'd be a huge help. My hands are pretty full right now with #157693: Upgrade project issue to Drupal 6.x and related issues...

Thanks!
-Derek

Hmmm, strange.

I did a couple of test runs, and this message (generated by the comment validation procedure) occurs sporadically, but both with and without the patch applied. So it looks like this is a separate issue.

Looking at the above code, there's a 50/50 change that "generate issues" will change the issue version. However, if you have issues without a version assigned (for example, issues created before project_release was enabled) and "generate issues" decides not to update the version, the validation error message will be displayed. This explains why the frequency (and whether it appears at all) of this message during issue generation varies depending on whatever issues exist in the database.

Best way to force the error is to create a bunch of issues with project_release disabled, then generate a number of issue comments after enabling project_release (and adding some versions).

Fixing it is relatively easy by checking for the absence of a version for an issue, forcing a version change if a) no version is currently assigned; and b) one or more versions exist for the project. If both conditions are met, the random value should be ignored and a new version should always be assigned.

Attached a rerolled patch containing both the original changes as well as a bug fix for the behavior described above.

I'm not sure the problem you isolated in #4 is the only problem here. I've seen these errors occassionally when using the drupal.org testing installation profile, which sets up a clean drupal.org like site and then creates several projects followed by creating lots of issues and comments. In that situation I don't think any of the issues would not have a version associated with them, yet I sometimes see the error. It could be that in my case the error is coming from another field, such as assigned or perhaps the project field.

I don't think we thought much about the case where issues might have been created without project_release enabled when we were testing this submodule, so good work isolating at least one problem in the logic of the module.

You're right. I installed the Drupal testing profile on a clean Drupal 5.15 site. None of the projects is missing release/version information. I ran a couple of "generate issue" runs with project_release enabled. During the third run I got the following validation message:

An illegal choice has been detected. Please contact the site administrator.

and an entry in watchdog

Illegal choice 185 in Version element.

Somehow, during validation, the #value selected for "version" does not appear in the select's #option-list, and form.inc throws a validation error.

For example, the #options array would contain:

I've changed the title on this issue to address all problems with "Generate Issues" described in this thread. I'll try and create a patch to fix all of these in one go.

In project_issue/comment.inc, the following snippet occurs in function project_issue_comment:

This piece of code is responsible for making sure that the correct project is loaded into memory after a project change. As indicated in the comment, it's a bit of a hack, and one that assumes that the project change was the result of a form post. When generating issues, drupal_execute('comment_form', ...) is used, and the project is changed without a form post.

We should probably see if we can improve comment.inc so it no longer relies on the $_POST variable, but given that the hack was used in the first place, there probably isn't an easy alternative. Meanwhile, I've added a single line to project_issue_generate.inc:

Whenever project_issue_generate changes the project, it sets the $_POST['project_info']['pid']-value so comment.inc can pick up on the project change.

Attached is a patch that fixes all issues described in this thread, to summarize:

1. Fatal errors when project_release is disabled;
2. Validation error when not setting a version on an update if none is set but one or more versions are available;
3. Validation error on project change during issue generation.

After applying the patch on a site using drupal.org testing installation profile, I was able to generate thousands of issues and issue comments without any error or validation warning.

Identified at least two more issues:

• When generating issues using the current -dev version (without patch), the metadata isn't always correct when it comes to project changes. For example, an issue would be generated for "Drupal.org Testing", and the metadata on the first issue comment would list the following project change: "CVS integration » Documentation"
• When not changing a project, if the component does change, it's value is taken from the component list of another project. This doesn't yield errors on a d.o. testing profile since all projects use the same list of components, but it's incorrect.

I'm re-rolling this patch to include fixes for those issues...

Ignore the first bullet on my previous post, this was an oversight on my end... The second bullet still holds true, attached is the re-rolled and hopefully final iteration of this patch. Sorry for spamming.

"Sorry for spamming." Are you kidding me? ;) Please keep "spamming" if your idea of "spam" is "here's another patch that fixes some bug in project*". ;)

I'll take a closer look at this in a little while -- I'm just in the middle of something else right now. Thanks again for all your help on this!

Identified & fixed an additional issue with issue generation: when building the list of projects to use, projects for which "Enable issue tracker" is unchecked are incorrectly included in the list. This causes errors like:

Changed the query from

to

Re-rolled the patch to include this fix. Note that this patch is now based on HEAD, no longer on 5.x-2.x-dev.

Just ran across this issue too. I haven't yet tested the patch, but am changing the title to be the same as #97095: Issue tracker depends on project_release.module from back in the old days.

Looking quickly at the patch, I'm a little leery of randomly assigning a release, but I guess we've always been doing that.

Putting the title back. This is a separate issue.

@marcp: this started out addressing the dependency on project_release when generating issues, but along the way a number of additional problems where unearthed (and resolved).

I'm a little leery of randomly assigning a release

It's been a while since I worked on this patch, but if I recall correctly, the randomly assigned release is drafted from the set of releases for the issue's project, so I think this is safe.

I don't think generate_issues was addressed (yet) as part of the port to D6, and with the large number of changes that were made during the port I think a big portion of it might have to be rewritten anyway (last time I checked I couldn't get it to work on D6). I do think that this patch still applies to 5.x-dev.

@mr.baileys - I haven't even tried generating issues, but found that there is a dependency on the project_release module just to run project_issue. It's a separate issue -- one that I linked to above that's been closed for a long time, but which is now valid again. I'm just not sure if I should re-open the old one or open a new issue.

This issue will probably still be valid even when the generic problem gets solved.

As far as the random thing -- I didn't even know what I was reading when I made that comment. Clearly if we're just generating gibberish test issues, then it's fine to pick a random release.

- Marc

I encountered the same issue with project + project_issue module enabled and project_releases disabled on D6. Patch at #11 solved the problem. Thanks.

patch fails to apply after the recent commits to get this module working on 6.x -- sorry i didn't see this patch first!

I have the project 6.x-1.x-dev from apr 3 2009 and project issue tracking 6.x-1.x-dev from Mar 29 2009 on D 6.10 and clicking any of the view links from the project page like "View pending bug reports" gets me: Fatal error: Call to undefined function project_release_get_releases() in /home/.../modules/project_issue/views/handlers/project_issue_handler_filter_issue_version.inc on line 63

I am not currently and was planning on not using the releases module.

Is the current status that the patch does not apply?

and

If I enable the releases module, will it work ok, if a bit odd to have releases if I dont have them? (EDIT: I think I'm going to try this temporarily.)

Thanks for any update.

I have the release module not enable and it works fine (http://musescore.org/project/issues).
But I had to do one thing: change the view and throw out all references to the releases module.

@yesCT and @toemaz: That's a completely separate, unrelated bug. See #396056: Viewing issues of a project without activating Project releases gives php error

Thanks!!!! I needed a point in the right direction! -YesCT