Implement more fine grained project node permissions

You have two things here.

1. I have not seen notes or requests that people removed the pin or youtube_filter modules. One might be able to do some research in the watchdog to find who did these.

2. I don't get how you came up with these zero download numbers. There is no such download data published. You might mean usage data, which is not surprising if 0 for a theme which was never released for Drupal 5 or 6. Drupal 6 includes the client for the usage count but it is optional to use and for Drupal 5, you need to even download and install a module. So if a usage count says zero, that does not at all mean that the given project is unused. Also, we are not themes stuff because they are old or ugly, or unused. One of the greatness' of open source is that people can dig up old, bad, ugly or unused and can come up with golden, popular and celebrated things from them with additional work. Since we are not deleting stuff as I said, I am surprised that (1) happened, and as I've said I don't have an answer why.

Cool URIs don't change
Old project releases are left behind where they were for archival reasons. Moving them elsewhere would be doubly annoying.

It's a bit frustrating that the example you found didn't have the automatic ability to link forward to the new home of this module development, but it only took me two clicks to find what had happened.
- clicked user - to see if they were still active, maybe the project had been dead for years.
- clicked their projects - Immediately saw the video filter next generation module. Smiled.

I don't know what is built in to the project module that currently doesn't support renaming of existing projects (looks like the URL went funny) but you can have a look at the code I guess. So I'll push this as a feature request to the module that does that re-linking. Maybe someone there can better explain why an old project release failed to link forward.

Retired modules just get frozen where they are - for historical reasons. So sometimes they will still show up in searches. That's the way the web g(r)oes.

Whoops - missed the project.module selector. too many items in the list.

Yeah, the idea is that people would not *remove* modules, but add a note to the project page that they migrated over to a different name with more/less/different features. The problem is that the module *node* was removed, and that you needed to do "hacking" (get to the now non-navigable release page, get to user, get to their projects and look at those), to find a successor project. It could have happened that the project was removed because of a better implementation was available for another user, which would totally break your hack flow of solving the problem. The idea is that projects are not removed, unless absolutely necessary, and with the youtube_filter example, the module was actually removed.

pvasili has two examples.

1. Pin module. I don't know whether this has a project page ever. It only has one commit: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/pin/ Maybe a non-issue, if it never had a project page. Then it is just a confusion on pvasili's part, and this was never a node on drupal.org.

2. Youtube_filter. Pvasili pointed us to a release: http://drupal.org/node/194146 but as the breadcrumb nicely shows, the parent project does not exist. It should.

Let's figure out what happens here. This might be a problem in some human process we do (eg. who can delete projects, why do we delete projects, etc), could be a machine error, etc.

pvasili: if we should remove trash, then complaining about and old theme which have no releases (that is voodoo, what is wrong with that?) is equally trash, and issues such as this would be deleted.

Just wanted to point out that for a long time project maintainers were able to delete their own project nodes. I am guilty of this.

Please see: http://drupal.org/node/128132

It is not that way anymore is it?

I didn't try it, but I still have a 'Delete' button on projects that I authored. The only extra roles I have in addition to CVS/project maintainer, are the docs team.

@pvasili From the looks of this CVS log, it appears that the module author removed his code and deleted the module. But I'm not very sure.

Seems we need a patch to drupalorg module to remove this button.

According to http://drupal.org/node/319783 only d.org site maintainers and above have access to delete content, which seems reasonable. Lesser user roles shouldn't be able to see that button, no?

@pvasili In that case, please let us know where you are finding the lost links.
Identifying the referring page that contains links to redundant pages is as important as fixing the target, if not more.

What are the pages that contain these bad links you post? If they are just random search results, then it's obviously not an issue, but if somewhere in project.module is still pointing at dead branches, that's what needs to be fixed.

And access to the delete button IS important, because if it can be restricted correctly, then these broken branches cannot be created. And it will become a non-problem.

from #367832-18: Implement more fine grained project node permissions

@pvasili In that case, please let us know where you are finding the lost links.
Identifying the referring page that contains links to redundant pages is as important as fixing the target, if not more.

Please do that or you are just wasting everyone's time.

In this particular case (unpublished because quicksketch didn't want people using it) I re-published it and move it to the abandoned modules user and marked the releases as unsupported so they will be harder to find which solves the same problem as quicksketch but in a way that people know what's going on a bit more.

Is this going to be a running list of unpublished / deleted projects, or are we going to do something?

Am I right that the proposal is:

- do not unpublish projects, instead make a note on the project page
- do not allow project owners to delete projects (not just the button, also the URL)

@pvasili (22): See #363213: concentration and magicsquares projects are broken?. Please do just some basic research first before posting deleted projects back here. Let's stop wasting time doing that and focus on actually patching something for the d.org custom module.

Plus, I believe that D6 adds finer access permissions for 'delete own x content' and 'delete any x content' (see node_perm()) so this should be easier to fix once we have transitioned d.org over from D5. We can make sure only trusted users have those permissions.

I would like to report that today are missing links to releases of modules http://drupal.org/project/user_readonly and http://drupal.org/project/masquerade (for Drupal5).
Therefore, the module update_status said "Not supported!" for these modules.

It is important to know who deleted these links: the authors of these modules, or someone else, for example, to update the site drupal.org?

@#28 -- Those projects still exist. The releases still exist. They have simply been marked as unsupported.

No user should be able to delete releases/projects. (Site maintainers should know better than to delete them, even if they can.)

Unpublishing projects and releases is acceptable, but should be discouraged.

The outstanding issues should be addressed as part of the D6 upgrade/redesign process.

vadbars, no one deleted them. The module maintainer(s) have decided they are no longer supporting or providing the 5.x releases, a decision completely up to them. But, hence the 'not supported' error message in the update module. The 5.x releases are still available:
user_readonly: http://drupal.org/node/53103/release
masquerade: http://drupal.org/node/49383/release

Crossposted and putting to the upgrade tag instead of redesign since this is something that can be fixed with 6.x.

Sorry.

The upgrade tag was right. Drupal 6 has better permissions, so we can finally revoke deletion of projects from maintainers, and only allow editing.

I don't think this is productive

To fix the problem, identify the source of the problem.
If there is something in the project.module or d.o. infrastructure that is creating links to these dead ends, identify that and it can be fixed once, in one place.
If you will not provide references to the sources of those pages, then this is unfixable in the general case. Or just defunct information. Search results or old links do not count. Old dead projects are old dead projects. So let them lie.

The question (again) is where are you finding these references?.
If there is a dead page that links to nowhere and is not linked to from anywhere then it's not really an issue.
Are you just doing detective work of your own to back-track these links, or running through every drupal.org/node/n+1 page to find them?

If there is a pattern to the problem then maybe the pattern can be fixed in one go.
But sometimes content is deleted because the content is no good and re-animating it is causing clutter and filling the already bloated list of modules with bad stuff.

This thread is useless.
We'll prevent deleting projects in about 10 hours from now. We're not going to do anything to "recover" the already deleted ones.

@dww: it does not seem so obvious to fix this. The Drupal 6 version of project does not provide the fine grained permissions for project nodes like the core node types do, so we cannot just go in and revoke the deletion permission. Project module has this catch-all "Maintain projects" permission. It falls back from project_project_access() on project_check_admin_access() to look up whether the user can delete the node, which returns TRUE if the user has this "maintain projects" permission and an owner of the node or a CVS maintainer on the node.

#232893: Add finer-grained permissions to control access to delete project* node types (fixed and deployed on d.o)

Superb, thank you!

@pvasili: Please stop. In this case, drupalorg_proxy was unpublished, not deleted. This has *nothing* to do with this thread. The fact you could see the release associated with it was only because whomever unpublished the project node didn't also unpublish the releases. See #142957: Prevent project deletion when releases are present for more.

Anyway, this particular issue is resolved and closed. As I said before, we're not going to go back and "repair" anything about projects that were once deleted. If you insist on continuing to report broken links like this, then please do so in the webmasters issue queue using the appropriate component, instead of trying to reopen closed issues. Thanks.