We need LIMIT or TOP in JQL

Could someone take a look at this suggestion again? 

bc32e99a92d8 Please reopen this suggestion so we can vote on it again. Many people here have provided their use cases.

Yes - very suprised that LIMIT is still not available? Limiting indeed - need to put in a quick fix on the filter of the board, as the JQL there today stopped working an getting error that more than 5000 items are on the board. Checked filter and it is correct...

Hello everyone, 

You can add limit the search results with the GO! JQL plugin. It is for Jira Server and Jira Data Center.

The Jira Cloud version will be released soon. Here is the documentation.

I hope it helps, bests! 

If y'all at Jira would like to think about this again, I'd be soooooo happy!

On a more serious note, while yes, this is useful for visualizations, it's far more useful for basic automation - especially when it comes to just-in-time planning and alerting.

I understand if the development effort is too difficult or complex, but it would be nice to think if something could be done...

We need this, please add.

This would be very useful. I need to pick an issue from every Sprint, any issue (but just one), as a representative of that Sprint to drive some graphical report because the issue contains the start date and end date of its respective Sprint. The report does not have access to any of the global Jira environment variables, so using the actual issues is the only way.

Wish you had the support for this.

this is a basic functionality for a query language .. Splunk, Kibana, SQL do it .. why can't Jira do it ?

hey, lazy asses .. implement this already!

We need LIMIT or TOP in JQL.. 

Please reopen this ticket. We need this enhanacement

Please reopen this! 

It's implemented in the REST API (with startAt and maxResults), so why not add the functionality to JQL as well?

Why was it closed? @osanico?

I also support reopening this suggestion for consideration. We have a similar need to this request

Seeing how the Resolution is "Won't Fix", I assume this is not implemented. 

Is this actually implemented?

+1

I think it's a pity, this was closed as Won't Fix. 

I would really like limit or top. It's really cumbersome manually selecting the top. (We do it by adding the issue to a special sprint.)

LIMIT OR TOP would be good. Especially when we opt for bulk change. Please consider this. 

+1 on this feature. would be very useful. 

jandersson1 - thanks for reaching out again. I've moved on from the JIRA team (still here at Atlassian), which means I no longer have all of the details on the JIRA Server roadmap. I will make sure the JIRA Server PM team is aware of your ask, and I have reached out to the PM who's leading the team to let them know.

Thanks
Josh

First off, sorry about the repost.

@Josh Devenny

I totally think this should be re-opened and implemented.

Reasoning:

If the underlaying application and database get's 50 rows of returns that needs to be narrowed down to the top 5, 45 other issues were searched but their results disregarded, countless more disregarded because they did not match the criteria of the JQL, only to return 5 a widget. This adds to slowness in the application server, increased load on database servers.

Same goes for agile boards, which can be notoriously slow when JQL fetches 5800 instead of just the 300 with the highest rank.

To use the statements like: "I have in fact spoken with then engineering team and this would require a fundamental change to JQL." is like arguing about a car's gearbox should have a reverse or not. Yes, it would demand re-engineering and Yes, people can just ride around the house 5 times until a parking-spot appears which does not require a reverse gear to park in.

Further more: "It would, as you say, be very costly.". Yes, so are your products, but it didn't stop you from quadrupling license costs the last 6 years.

Going on.. "As a PM, I believe there are a huge list of things that we could do that would give you as the user more value, for the same amount of effort.". Please let us know what those features might be, so i can tell users about those features, possibly making them forget how slow JIRA can get sometimes.

Please reconsider this.

Wrong account

We could REALLY use this functionality.  Are there any plugins supporting this LIMIT capability?  Looks like the Pigsty tools is not supported any more.

A LIMIT statement in JQL would definitely be useful, especially with certain plugins.

This is not only for visualization usefull. For some plugins, we have to limit the issue number to less then 1000... (BigPicture)
I also dont understand why you are not able to fix this..

For example i have seen, when you make a bulk change, the data is also limited to 1000 sets.
So i imagine that you are able to limit the data in the background.

So why you can't offer the limit function in the foreground?

I think this is because Hybernate's HQL does not support "LIMIT": http://stackoverflow.com/questions/1239723/how-do-you-do-a-limit-query-in-hql

Why is this closed as "Won't Fix"? This is useful.

I would really like this!

This really needs to be implemented, especially while the Kanban and agile boards are running into rendering and scaling issues.
https://jira.atlassian.com/browse/JSW-12452

If I could at least limit the number of results in the board then maybe the app would be usable.

I would like to use the issue statistics gadget to collect statistics on the top N issues in my backlog. I could do this by creating a filter which uses LIMIT. Alternative suggestions are welcome but for now I would like to see this issue reopened.

This needs to be reopened and implemented.

Not being able to limit a filter to the latest occurance of an issue type (think deployment record for example) is a rediculous error of ommision.

I would like to be able to limit results so that I can subscribe to a filter and only see the top X results.

I agree with Christian Rondeau. It will be very convenient if we can just limit the issue number shown in each swimlane, for better navigation and keeping the big picture of current situations.

Another use case, hoping it may re-open that issue: We are using a Kanban board, and a Scrum board for backlog prioritization. The easiest way to work with a large backlog would be to get the KanBan board to show only the to N items.

Another simple use case is performance - the backlog view loads faster if we can stop after N items.

I see the suggestion for the pigsty plugin is a great idea dn see that it would work great except that does not work with Jira in the Cloud, which is where my projects are sitting hosted on Atlassian.
I see one of the earlier comments is about Greenhopper usage which is now Atlassian Agile... so it seems Agile really needs this.

my use case:
Is that my project admins want to use a filter to limit their developers to only be able to select their work form the top 10, 20 or even 50 ranked items from the backlog.

Right now we have 400 issues in a backlog filter with items ranked by Agile. Unfortunately the value in the Rank field is a hash, not a simple number system so we can't say where Rank >7 (out of 10)
our filter is
project = foo_project AND Origin = "Customer Support" AND Status != closed ORDER BY Rank

the Filter is based on Agile Ranking we want to show only the top XX ranked items.

Our issue is that the developers are choosing items with a lower rank by clicking on the next page links or "20 of 400" and we really only want them to see the top 20.

Currently the only other way we cna think of to do this is a manually intensive tracking and assignment of some other custom field but it wouldn't be as accessible in the agile boards or work as cleanly. Which on a 50+ developer team is prohibitively time consuming.

You might say it's a training issue, but it's sometimes hard when you have a lot of develeoprs and a high turnover rate.

I've got a use case for this that I'd like to share. I'm currently using a plugin named "Gantt Chart Project for JIRA" by Soyatec. This plugin uses filters to populate tasks into its gantt chart. One of the problems with this is that the plugin can only accept so many results. It caps the amount of issues that it can display to 100. This max can be changed in the configuration of the plugin, but the point remains that there is a limit to how many tasks it can accept. I have a filter that I apply to this plugin, but it exceeds the plugin issue cap. I would like to have an operator word in JQL to limit the results of my filter to X so that I can use that filter with this plugin.

A similar use case exists for the Jira Rapid Boards. The Rapid Boards will only display 1000 issues at a time. I currently use a filter to display more than 1000, but would like to limit it to something like 800 to improve the board's performance.

Here is my use case for a LIMIT keyword:

My "assigned to me" and "watched issues" have gotten long enough that they're unworkable. I don't want to spend all day clicking, resorting, and paging through long lists. I would prefer to create clones with slight variations on these queries (top 5 oldest, top 10 newest, top 10 with a certain label, etc.) to be able to see different short summaries at a glance. The JIRA UI makes it cumbersome AFAICT to make multiple widgets with slight variations of the same query.

The fact that I can't define a limit in the query seems like a needless limitation. With recent UI changes, I have trouble finding my way around with mousing / links / form elements, so whatever decisions I can offload into something that looks like code, yay...

Awesome!
I have tried it out in my staging environment now and it behaves just as I wanted

Super-thnx for this upgrade! Keep up the compatibility, this feature will be used a lot!

svante.gustafsson: nice. let me know how it behaves

andrzej.pasterczyk1: This was great news!!!
Thnx so much for updating your plugin! Will try it out right away!

Hi guys... looks like there's a need for that so we've updated our free plugin https://marketplace.atlassian.com/plugins/com.pigsty.jira.plugin.pigstyTools
Hope this helps

https://marketplace.atlassian.com/plugins/com.pigsty.jira.plugin.pigstyTools

top in jql, but for old jira version

I also think a simple LIMIT statement would be most useful (otherwise I wouldn't have Googled it and stumbled across this issue!)

Surely it can't be that difficult/time consuming?

IMHO if this many people are asking for it (not to mention taking the time to re-justify their request several times) that should be a good enough reason to take it on board as a valid requirement

I can see this is closed and why. Just as an FYI this feature would also be very useful for me, for the same use case as Josh Burnett, ie:
•We have one project that represents a global list of wishes (issues). Issues are created by multiple departments, and issues that are cross-department are tagged as such.
•Each department has a separate rapid board to let them prioritize their issues as they see fit (using a department specific rank field).
•We have a global rapid board that is used to rank all department issues in a global order. Ideally this board would only show the top N issues from each department to keep the global list of reasonable length. This is where having a limit would be helpful.

At the moment prior to every prioritization meeting I am manually moving the issues around to have the top one per department at the top (while maintaining the correct order for each department). This is my biggest Jira pain.

Just FYI I only want to be able to do this on an Agile Board that I am using.

This would be useful for Confluence, and I see the preovios comment makes the same remark.

Maybe move this ticket to Confluence in a different narration?

I see you guys closed this...but one more use case for you:
I want to include the 10 most recent issues via Jira Macro to my Confluence page for a given project. The macro setting does not allow for a limit on display and JQL doesn't either. I am trying to do this because limiting by time - in the last month may not display anything (because project may have been on hold) but otherwise the project has too many issues to display if not limited in some way like "most recent".

I personally find this present explanation that WONTFIX due to engineering expense to be very satisfactory. And FWIW, even when you folks don't quite hit the mark, your transparency and reasonableness is way way ahead of most other vendors I deal with. Thank you!

-danny

I probably haven't been clear enough with my comments - I just re read my first one, and it doesn't give any insight into why I closed it.

I have in fact spoken with then engineering team and this would require a fundamental change to JQL. It would, as you say, be very costly. As a PM, I believe there are a huge list of things that we could do that would give you as the user more value, for the same amount of effort.

Another reason why I closed it is because we do not have any plans to touch the way the JQL engine works in the near future. I could open this issue, sure - it's a valid feature request. But my question to you is, would you rather me close it and give you a decision so that you know we aren't going to do it? Or would you rather me leave it open and let it lie dormant for the next few years with no work done on it? In my opinion 'Won't fix' is the best representation of what will actually happen to this issue over the next 24 months at least.

Let me know your thoughts - I'm open to anything (oh and remember - Flickr wasn't our fault )

... and, really, I'm just upset at what happened to Flickr, and misplacing my aggression at you ...

But, for the record, in my humble opinion, this feature ought to be left open for further consideration.

-d