Posted by webchick on May 25, 2009 at 11:29pm
Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
This could be really handy for modules that want to keep an issue like "List of things required for a D6 port" or "Looking for a maintainer" at the top of the issue listing.
Comments
#1
a) This only makes sense on the per-project issue views.
b) I'm a little concerned about the WTF? impact if certain issues are sticky at the top of the list, even when you click on the tablesort headers.
c) in IRC, Earl mentioned that there is a setting in the table settings in the views2 UI to control if the tablesort headers should clobber or append to the existing sorts. So, should sticky always be sticky, or only in the default listing without any tablesort? What about when you search for things -- should sticky trump search score?
d) Given that we're already using table row coloring for the status values, I'm concerned there's no visual queue for the sticky issues.
e) Only project maintainers that happen to be node admins on d.o could make use of this -- there's no other way to control the sticky bit on issue nodes. If you go back and edit an issue later on to add the sticky bit, that's also going to bump the issue in everyone's tracker pages.
Given all of this, I'm tempted to "won't fix". If you're still interested, please provide more justification for this change, and answers for the above.
Thanks!
-Derek
#2
I asked for this almost a year ago. :) #298719: Ok to sticky issues?
I think the fact that you have to be a site maintainer to make use of it is the biggest downside. Non site maintainers could file an issue requesting it, though. As long as we aren't innundated with requests, it would work.
This is one of those things that not everyone would make use of but would be handy in certain instances like webchick mentioned.
As for C: I think doing it only in the default would be best since there's the option. The main point is that folks coming into the issue queue see this item right up on top where it cant' be missed.
Michelle
#3
I agree. If there's a way to make it work only for the default project/issues/[shortname] (and not when any sort/searching is applied), that would be best.
As for e), who cares? The issue gets bumped in my tracker every time someone edits their node, edits their comment, posts a "+1 subscribe"... one extra bump isn't going to hurt anyone, particularly when it brings lots of benefits to those trying to manage large projects.
d) Does probably need to get solved though. If we simply added the sticky class, then it would probably take the default node sticky styling which is grey. That would visually separate it. But it would prevent any other colouring like "needs review" from showing. I'm not sure that's really a huge deal though, since these would only be used for "announcement" type things anyway.
#4
Marked #791068: make project_issue default views respect "sticky" duplicate...
In addition to the problem of only site maintainers being able to mark issues sticky (should probably move to a per-project thing controlled by the 'Maintain issues' project permission) and the views changes themselves, we've also been on a kick to optimize the queries for the issue views:
#921210: Fix performance of "My issues"
Adding a default sort on {node}.sticky is going to suck for these queries. We'd need to denormalize that field into {project_issues} for it to not majorly complicate the queries...
Definitely all doable, and I'd support seeing it done, but just pointing out it's a bigger job than it sounds like...