Close issue queue for a project while maintaining access to the history

I think this could be generally useful for project issue.

We have exactly the same request now that the Devel module has moved to GitLab using the new DrupalSpoons contrib module platform built by Moshe Weitzman. He has automated the migration of all open issues and we have now disabled the issue queue on drupal.org. Individual issues can be found if you know the number, and each Drupalspoon issue has an automatic link added back to d.o. on migration.

However, it would be really helpful if the full issue queue could be viewable and searchable, but no new issues could be added. I have started this question and Moshe agrees that it would be ideal. Other projects may well be moving to DrupalSpoons and this feature would be very good for all of them.

I hope you'll consider adding this option as it will help a large number of d.o. users to stay connected with projects when they move to other platforms.

This setting is actually really incomplete. It doesn’t even prevent new issues from being opened, or moved from a project to one with its issues “disabled.” Relying on this setting isn’t something I can recommend.

OK thanks for the info. So is there any hope for the functionality we'd like? If we cannot rely on the existing option is there an alternative? I'm ok with the current option being incomplete. If an occasional new issue is moved to the disabled queue that is manageable. The benefit of generally having the queue viewable but not having a 'Create a new issue' link at the top would be sufficident in 95% of the scenarios and would be a great benefit. There could even be a warning note by the option saying to use it with caution, and explain the short-comings.

It would be a simple hook_node_access() in project module I suspect.

That estimate from https://gitlab.com/drupalspoons/devel/-/issues/303#note_350981906 is way off-base. hook_node_access() isn’t involved in the current implementation and wouldn’t be added. This is more to do with access to a View.

I’d say this is might be a half day of work. Could be closer to a whole day to make the existing setting behave as expected.

You are of course welcome to work on helping to add this.

See also #524464: Issue node form still works for projects where issues are disabled

We had a lengthy chat in a thread in #drupalspoons on Slack related to this. While the existing checkbox is definitely broken, and while these issues would all be worth fixing, I'm bummed that the "right" fix is to make it highly frustrating and confusing for end users trying to submit issues to projects that have decided to move off site.

Pasting a few of my relevant comments here for history:

The bigger problem is that for the ~98% of projects on d.o that host their issues on d.o, if someone submits an issue to one of those queues, and then The Right Thing(tm) to do is to move that issue to a project that has issues hosted elsewhere, there's no good solution. That part is basically impossible for Project* to get right.

The "easy" fix is to simply remove externally hosted projects from the selector, so it's technically correct, but frustrating as hell for end users.
The more complicated thing would be to leave all the projects in the selectors as available projects (both for new issues and reclassifying existing issues), but if you pick something that's externally hosted, AJAX returns you a big warning message: "This project has moved its issues to XXX. Click YYY to submit your issue. " (more or less)

The impossible thing would be actually moving the issue into the appropriate external service.

None of which is something I want to spend time on, since I'd rather put the effort into making native Gitlab merge requests available in d.o issues (which is nearly done and close to general deployment, anyway). Then devs can be happy to have MRs and the better review tools, but end users can be happy since all the issue history isn't splintered across the world.

Issue #1857390: User can add issues to projects that doesn't have issue tracking enabled. is also working on some inconsistencies and bugs around this.

I suggest showing the list of issues, in case there are any, and also a warning/error message saying that the project is not allowing new ones. The link to add new ones in that view should also disappear in this case.

I suggest that we tackle them together and that we mark this one as a duplicate.

Actually, the module provides a default value for the view, which I believe is the right one for most cases: to display a 404 page.

This would be the right call in most cases, but for those where it isn't, the view can be altered as needed for the site. See the options available:

These options should be flexible enough to display a message if needed. But as far as the module pre-configured view goes, I think it should stay as it is.

For sites like www.drupal.org, I'd recommend changing the behavior to display the issues. I'll create an issue in that project and propose closing this one.

Child issue: #3314448: Show list of issues for a project even if issue tracker is disabled

Based on #10, we're closing this issue as the default is just that, a default, but can be altered with the different validators and actions offered.

For the specific case of www.drupal.org, there is this issue #3314448: Show list of issues for a project even if issue tracker is disabled which will allow viewing of the issues with a warning message.