in testing http://drupal.org/node/136172 i discovered some behavior which i can't decide if it's a bug or not. apparently, it's not uncommon for entire project nodes to be deleted (i thought we usually unpublished them, but i guess not). there's nothing in project_release that notices when you delete a project node that goes off to delete all the release nodes for that project. so, we've got a bunch of entries in {project_release_nodes} pointing to projects that no longer exist. who knew? ;)

should we...

  1. delete all release nodes whenever a project is being deleted? we already do something like that for issues (although there's a bug in that behavior, too: http://drupal.org/node/74953)
  2. prevent deletion of project nodes -- if you don't want it around, unpublish it. i guess you're still left with lots of stale issues and release nodes in that case, which you need to unpublish. perhaps we need a bulk unpublish admin operation on projects -- unpublishes everything associated with that project automatically.

if folks agree that 1. is the way to go, please just followup and set this to "bug". ;)

thanks,
-derek

CommentFileSizeAuthor
#4 do-not-delete-projects-with-commits-or-issues-142957-4.patch1.75 KBavpaderno

Comments

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I would go with option #2 -- bulk unpublish everything associated with a project.

Should be a fairly simple implementation of hook_nodeapi() in both the project_issue and release modules.

drumm’s picture

drumm
he/him
Location NY, US
commented
Version: 5.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes
Related issues: +#2072309: PHP notices when visiting a release or issue node belonging to a deleted project

With #2072309: PHP notices when visiting a release or issue node belonging to a deleted project and what happens when duplicate release nodes try to get packaged, this would be good to solve.

For packaging, unpublishing is not enough. The packaged files want to be named the same in the filesystem and files_managed table. The collisions are not handled well.

I would be okay with either approach. If bad releases aren't automatically deleted, I can go ahead and delete them myself.

drumm’s picture

drumm
he/him
Location NY, US
commented
Title: delete release nodes when project nodes are deleted? » Prevent project deletion when releases are present

Dangling releases actually cause all sorts of problems on Drupal.org now - they jam up Solr indexing and make the packaging queue noisy. For Drupal.org, we want to make it difficult to delete a project.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Active » Needs review
StatusFileSize
new do-not-delete-projects-with-commits-or-issues-142957-4.patch1.75 KB

I am proposing a slightly different patch that doesn't allow to delete a project if there are commits or issues. Users who can bypass the node access permissions can still delete projects with committed code or issues.

Status: Needs review » Needs work

The last submitted patch, 4: do-not-delete-projects-with-commits-or-issues-142957-4.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

drumm’s picture

drumm
he/him
Location NY, US
commented

The project project contains project_release, but not project_issue. This patch should be checking for releases, not issues.

As a www.drupal.org priority, #3046921: Make it possible to delete spam projects’s allowance for deleting projects without code makes this issue lower-priority or unnecessary. A project with releases will always have code.