+1 yes, please ... I have a use case where I want to add a JQL to a scheduled automation rule BUT want to only run it on 10 issues at a time. Please advise? Thank you

I think it's useful too. Please, consider reopen this request.

A LIMIT function would be useful to implement so that we can have Jira Automation act on a set of items from a JQL query. Please consider reopening this request.

hey, lazy asses .. implement this already!

Please reopen this!

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

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

... LIMIT being a common, convenient idiom for anyone used to querying SQL ...

1) This is a feature request. Let users vote for it.
2) The filter is irrelevant, but sure:

project = RFC AND status = Resolved AND Grade = A

I am trying to bulk process this with jelly runner, once the bugs are worked out, I can put the jelly in as a service. While I work the kinks out, I'd like to only process a handful of issues, like:

project = RFC AND status = Resolved AND Grade = A limit 5

I can probably set maxLimit in the jelly or something but convenient and easy for me to just say "limit 5"

I can see that maybe an Engineer estimates that adding this support would be very very costly to build out, and therefor there should need to be a lot of customers that want to see this done. Instead, some PM simply decides that the user requesting the feature doesn't understand what the user really wants. I'm glad you understand our needs and desires so much better than we do.

dannyman What filter is it that you want to limit the results? Also, how would you expect my above question to be handled?

I would VOTE this feature were it not WONTFIX.

Yeah, here I am testing out a jelly script so I want to set the filter to only act on a few results at a time. I could dig up the Jelly parameter maybe, but I don't see why a LIMIT feature in the JQL is a WONTFIX. :/

John,

Thanks for including your feedback! I have a query about limiting the issues on a board.

If you are trying to limit the number of issues in each project to a specific number, adding LIMIT functionality to JQL won't help you because everything is based off one query. This means if you have 2 projects, and each project has 20 issues and you want to limit it to 5 issues from each project, the query would be something like

"project in (one, two) limit 10"

What this would do is grab the top 10 ranked issues from both projects, which means it could potentially be 10 issues from project one (as opposed to five from each). Does that make sense? Is that the functionality you're after?

Cheers

Here's our use case:

• 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.

Is it only the GreenHopper Wallboard Gadget that's not allowing you to limit the results shown? If so, I'll raise an issue with the GH team to get that added (as that's a much simpler feature request).

If there are other things, please let me know.

Cheers

Hi,

Yes I can limit the number of shown issues in most (filter-based) gadgets but if I want to show a Greenhopper gadget such as the Greenhopper Wallboard Gadget visualizing a Greenhopper board I need to be able to limit the filter since the gadget itself doesn't allow me to show the e.g. top 5

Hi Svante,

I'm curious how you're building your wallboards. If you're using JIRA gadgets, you can limit the resultset in them. If you're building your own wallboards, you should be using the JIRA REST API, which allows you to limit the number of results returned.

Let me know your setup and I might be able to help.

Cheers
Josh

This can be useful to create a filter for GreenHopper as well, so we can limit the backlog there.

Hi,

The main reason for having a LIMIT statement is for visualization!
I agree that I could just look at the 10 first issues if I have ordered them correctly but on a wallboard for example this is not possible.

A scenario could be:

• to show the 5 most voted feature requests
• to show the most active issues
• to show the most top ranked stories

This is not possible without the LIMIT function. The list on my wallboard will show ALL issues from a filter (which could be many)

I therefore think this feature request still is relevant!

Kind regards,

// Svante

Hi Svante,

I'm not sure why you would need a LIMIT statement in JQL - you can order by anything field that you wish. Since results would be returned in the order you are after, you can simply look at the top 10?

Also, performance is not a concern because JIRA fetches the results 50 at a time as you go through each page.

I'm going to close this one for now - let me know if you have some thoughts.

Regards
Josh Devenny
JIRA Product Management