The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Sticky / pinned issues 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.
GitHub has recently added pinned issues (#7)
Proposed resolution
TBD
@dww #1:
- This only makes sense on the per-project issue views.
- Given that we're already using table row coloring for the status values, how would we visually queue the sticky issues?
- Could be confusing for tablesort links.
- 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.
@Michelle #2:
I think doing it only in the default would be best... the main point is that folks coming into the issue queue see this item right up on top where it can't be missed.
@webchick #3:
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.
Remaining tasks
- Decide how it should work:
- UI + access work-arounds to let project maintainers toggle sticky bit on issue forms for issues in their projects?
- Visual + accessible way to announce / distinguish sticky issues at the top of the lists?
- Decide how much to implement in project_issue vs. drupalorg
- Implement
- Tests?
- Reviews
- RTBC
- Commit
User interface changes
TBD
Comments
Comment #1
dwwa) 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
Comment #2
michelleI 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
Comment #3
webchickI 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.
Comment #4
dwwMarked #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...
Comment #5
Anonymous (not verified) commentedIf/when this is implemented a checkbox on the node/%/maintainers view to allow for allowing other maintainers to also make use of the sticky makes sense.
Comment #6
avpadernoI am changing version, since the Drupal 6 version isn't supported anymore (and it's not used on drupal.org too.)
Comment #7
mglamanGitHub has recently added pinned issues. It'd be great if we had the same functionality
Comment #8
dwwNote: while most of #1 is still TBD, d.o's plumbing has changed a lot since #4. Issue queue views on d.o are now separate Search API views in the drupalorg project, so we'd just have to make sure sticky got into the search index and there'd be no performance concern there.
Summary update to clarify the problem and remaining TBD parts.
Cheers,
-Derek