Issue node form still works for projects where issues are disabled
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
I've searched and have had no luck finding an issue on this. I can't believe I'm the first to report it, which makes me think I'm missing something, so hopefully I won't come off looking like a fool. :)
I just went to file an issue on a new project. Normally, I go look at the existing issues first and file the issue right from the issue queue itself. But, being a new project, there were no issues. I searched on the project page but see no place to create a new issue. Now, I could cheat because I know the URL to get to a project's issue queue but not everyone will realize this.
I've been noticing a lot more "issues" posted in the forums in recent months. I wonder if that's due to the fact that it's not clear how to file an issue on a project? Even if there are existing issues that you can click on to get to the queue, a lot of folks may not realize they will find a create issue link there. They may just look at the project page, see nothing about creating an issue, and hit the forums instead.
At the very least, we need a link if there are no issues. Expecting people to guess the URL to file that first issue is a bit much.
Unless I'm just blind and there's a link there somewhere but I sure don't see it.
Michelle
#1
While the "create an issue" link is somewhat harder to find these days, it turns out that in this case the project had issues turned off: http://drupal.org/node/521948/edit/issues
Which highlights a new bug: if issues are disabled then not only should the UI be hidden but also the node form should be blocked.
#2
I could have sworn I fixed the project...
#3
My question is, why do we allow the issue queue to be turned off? Do we want projects with no queues? Especially since the queue is still there, just more hidden, considering I filed my issue by typing the URL in manually.
I still say knowing you need to click on the "0 issues" to file an issue is not good UX.
Michelle
#4
Sorry, crosspost.
Michelle
#5
Kind of a schizophrenic issue here now ;)
Why remove the "create issue" link? Because Mark and Leisa's research told us to. Partially to promote searching before submitting.
Why allow projects without issues? In this case it's because they are tracking bugs elsewhere. I'm not sure how many projects we have like this, but I imagine it is quite a few and I think it's ok.
#6
I suppose the fact that I'm finding more and more people filing issues in the forum because they don't know about the issue queues doesn't matter because I haven't performed formal usability studies, right?
Ugh.
Ok, I can't fight against the UX machine. I'll cede the issue to you and your bug. Maybe I'll just put a big note on all my project pages with a "click here".
Michelle
#7
Giving a better title to reflect the actual bug here.
In terms of the previous feature request, the "create a new issue" link wasn't removed by Mark + Leisa. It came from #310446: Remove issue creation links from project pages. @Michelle, you participated in that thread and supported the change. ;) A few tasty quotes from memory lane:
#310446-13: Remove issue creation links from project pages:
#310446-31: Remove issue creation links from project pages:
;)
#8
I remember that issue, but I didn't realize at the time what I was supporting was making it both unclear where the issue queue was and also impossible to file an issue without typing in the URL manually in some cases. I was excited about reducing dupes and didn't see the confusion the change would cause. I guess maybe I'm the first person in the world to see an easy fix and not be aware of all the potential ramifications... My apologies for that.
Michelle
#9
@Michelle: Your comment sounds a little bitter -- I didn't mean to strike a raw nerve. I was just pointing out where the change was coming from. Sorry if you took it the wrong way. I'm definitely not faulting you for supporting something that ended up having unintended consequences -- I've certainly done that 100s of times myself. ;)
There's no reason at all to have to ever manually type a URL for anything. Can you be more specific about that?
Also, I'm hoping that the issue queue moving prominently into left sidebar blocks would make it more obvious and easy to see/find, instead of the bizarro and confusing pile of links strewn about below the release table.
Sounds like your main gripe is about a project where issues were disabled...
Perhaps part of the solution to this problem is that projects that have issues disabled should have a different block that shows up instead of the "issue cockpit", with a little message like "The issue queue is disabled on this project" or something. Personally, I think it's annoying and lame if folks host issue tracking elsewhere. Frankly, I'd be fine with locking down the disabling of issues to only project admins, and just leave the queue enabled on all projects on d.o by default.
To allow some informed decisions, here's a bit of wisdom from the DB:
SELECT n.nid, CONCAT('http://drupal.org/project/', pp.uri) FROM node n INNER JOIN project_projects pp ON n.nid = pp.nid INNER JOIN project_issue_projects pip ON n.nid = pip.nid WHERE n.status = 1 AND pip.issues = 0;+--------+-----------------------------------------------------+
| nid | CONCAT('http://drupal.org/project/', pp.uri) |
+--------+-----------------------------------------------------+
| 3232 | http://drupal.org/project/chatbox |
| 3306 | http://drupal.org/project/taxonomy_dhtml |
| 7827 | http://drupal.org/project/emailpage |
| 11098 | http://drupal.org/project/it |
| 11118 | http://drupal.org/project/ja |
| 11541 | http://drupal.org/project/hu |
| 12569 | http://drupal.org/project/survey |
| 15059 | http://drupal.org/project/pushbutton_phptemplate |
| 15863 | http://drupal.org/project/contact_dir |
| 18044 | http://drupal.org/project/agent |
| 22550 | http://drupal.org/project/go |
| 22558 | http://drupal.org/project/zippy_images |
| 25693 | http://drupal.org/project/portfolio |
| 26133 | http://drupal.org/project/gsitemap |
| 28407 | http://drupal.org/project/debate |
| 32818 | http://drupal.org/project/phpbb |
| 33464 | http://drupal.org/project/civicrm |
| 39484 | http://drupal.org/project/is |
| 41213 | http://drupal.org/project/optimize |
| 47252 | http://drupal.org/project/businesscard |
| 49075 | http://drupal.org/project/views_bookmark |
| 50740 | http://drupal.org/project/sifr |
| 59712 | http://drupal.org/project/aggregator_node |
| 68011 | http://drupal.org/project/tagmark |
| 69407 | http://drupal.org/project/moduleweight |
| 69565 | http://drupal.org/project/svn |
| 71102 | http://drupal.org/project/easylinks |
| 71705 | http://drupal.org/project/scoopt_words |
| 72995 | http://drupal.org/project/feedparser |
| 78555 | http://drupal.org/project/fieldgroup |
| 80922 | http://drupal.org/project/googlesearch |
| 84150 | http://drupal.org/project/poll_inline |
| 85101 | http://drupal.org/project/googleverify |
| 106231 | http://drupal.org/project/slideshow_creator |
| 107543 | http://drupal.org/project/mybloglog |
| 111286 | http://drupal.org/project/no |
| 121369 | http://drupal.org/project/corei18n |
| 135024 | http://drupal.org/project/civiconference |
| 135601 | http://drupal.org/project/pressflow_multidomain |
| 138904 | http://drupal.org/project/auctionads |
| 149937 | http://drupal.org/project/cck_slideshow |
| 157674 | http://drupal.org/project/cck_flashcard |
| 172017 | http://drupal.org/project/gallerix |
| 180395 | http://drupal.org/project/file_translit |
| 181098 | http://drupal.org/project/rollout |
| 188997 | http://drupal.org/project/emspace |
| 201705 | http://drupal.org/project/lists |
| 212678 | http://drupal.org/project/blockclone |
| 219472 | http://drupal.org/project/legacypath |
| 230733 | http://drupal.org/project/image_square_thumbnails |
| 239258 | http://drupal.org/project/verse |
| 245438 | http://drupal.org/project/usermenus |
| 251627 | http://drupal.org/project/help_soc |
| 254101 | http://drupal.org/project/xmppclient |
| 265697 | http://drupal.org/project/field |
| 269731 | http://drupal.org/project/maps |
| 289588 | http://drupal.org/project/accurate_read_count |
| 299242 | http://drupal.org/project/performance |
| 319071 | http://drupal.org/project/rlisting |
| 319074 | http://drupal.org/project/notice |
| 334930 | http://drupal.org/project/AlumniDrupal |
| 346103 | http://drupal.org/project/export_node |
| 370512 | http://drupal.org/project/admin_my_content_comments |
| 375317 | http://drupal.org/project/og_donate |
| 407536 | http://drupal.org/project/BasicRed |
| 472592 | http://drupal.org/project/batchapi |
| 521870 | http://drupal.org/project/udcountdown |
| 521910 | http://drupal.org/project/udheader |
| 521928 | http://drupal.org/project/udlocomap |
| 521938 | http://drupal.org/project/udplanet |
| 521948 | http://drupal.org/project/udtheme |
+--------+-----------------------------------------------------+
71 rows in set (0.01 sec)
Not sure what the deal is with all of those... There are an additional 38 projects with issues disabled that are unpublished, but we obviously don't care about them... I clicked on one and it happened to be owned by the Abandoned Modules user. So that explains 20 of them:
SELECT n.nid, CONCAT('http://drupal.org/project/', pp.uri) FROM node n INNER JOIN project_projects pp ON n.nid = pp.nid INNER JOIN project_issue_projects pip ON n.nid = pip.nid WHERE n.status = 1 AND pip.issues = 0 AND n.uid = 291168 ORDER BY nid;+--------+-------------------------------------------------+
| nid | CONCAT('http://drupal.org/project/', pp.uri) |
+--------+-------------------------------------------------+
| 7827 | http://drupal.org/project/emailpage |
| 15863 | http://drupal.org/project/contact_dir |
| 22558 | http://drupal.org/project/zippy_images |
| 26133 | http://drupal.org/project/gsitemap |
| 41213 | http://drupal.org/project/optimize |
| 69407 | http://drupal.org/project/moduleweight |
| 80922 | http://drupal.org/project/googlesearch |
| 84150 | http://drupal.org/project/poll_inline |
| 85101 | http://drupal.org/project/googleverify |
| 107543 | http://drupal.org/project/mybloglog |
| 135024 | http://drupal.org/project/civiconference |
| 135601 | http://drupal.org/project/pressflow_multidomain |
| 149937 | http://drupal.org/project/cck_slideshow |
| 157674 | http://drupal.org/project/cck_flashcard |
| 212678 | http://drupal.org/project/blockclone |
| 219472 | http://drupal.org/project/legacypath |
| 269731 | http://drupal.org/project/maps |
| 319071 | http://drupal.org/project/rlisting |
| 319074 | http://drupal.org/project/notice |
| 375317 | http://drupal.org/project/og_donate |
+--------+-------------------------------------------------+
20 rows in set (0.00 sec)
Clearly, there's a bug that project_issue lets you submit issues for projects where issues are disabled. Perhaps we also need a feature request about better notification to end users that issues are disabled on a given project. Finally, perhaps we want a feature request to change the permissions required to enable/disable issue tracking for projects. Other thoughts?
#10
Yes, I was a bit peeved about having my enthusiasm for something I wasn't totally clear on thrown back in my face. :P
At any rate, aside from the issue queue disabling (which is where the manually typing the URL comes in), the real problem, I think, is that the issue queue links are a bit of mystery meat. We don't necessarily need a direct create issue link but rather something along the lines of "View/Create bug report or support/feature request" that links to the "open issues" view. That has clear text that non devs will understand. "bug" is such a part of our language that it should be pretty clear that's where you go if you have a problem. Linking to "0 open" really doesn't have the same effect, I don't think.
This issue is wandering all over... If you want me to make a new issue, I'll do so.
Michelle
#11
Wasn't able to finish my reply before... Kids. :)
Anyway, I think disabling the issue queue should be a special permission done only for unusual projects. The project I ran into it on was the new Ubuntu theme. I just assumed the problem was it was a brand new project and therefore had no issues when it turned out the issue queue was disabled. I can see no reason for disabling an issue queue on a theme. If a maintainer doesn't want to deal with support/feature requests and bug reports then they need to find someone to co-maintain who will. I don't think folks should be able to just shut off the queue.
Michelle
#12
@Michelle: The "issue cockpit" block says the following:
To avoid duplicates, pleasesearch before submitting a
new issue.
[_________________________]
(Search) Advanced search
Then comes the "mystery meat". You don't think that's clear? Should "submitting a new issue" be a link to the open issues page, too? What (exactly) should it say (and what link(s) should it provide) if you think it should be changed? ... I'd like to not have a wall of text there.
Thanks!
-Derek
#13
1 yes. and the bug also lets access the existing issues
2 yes. "The issue queue is disabled on this project" sounds good
3 yes. +documentation
no
#14
@Pasqualle: Ok, thanks. In that case, please submit new feature requests for 2 and 3. Let's use this issue for bug #1.