Feature #2850

Add next/previous navigation to issue

Added by Christian Zagrodnick over 8 years ago. Updated over 5 years ago.

Status:ClosedStart date:2009-02-26
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:1.4.0
Resolution:Fixed

Description

When opening an issue from an issue list there should be next/previous links on the ticket to navigate the list.


Related issues

Duplicated by Redmine - Feature #3337: Button Next/Previous on issue form Closed 2009-05-11
Duplicated by Redmine - Feature #4028: Ability to navigate to next and previous issue from an op... Closed 2009-10-14
Duplicated by Redmine - Feature #4583: Add the ability to navigate in issues Closed 2010-01-14
Duplicated by Redmine - Feature #5361: Next / previous issue feature Closed 2010-04-21
Duplicated by Redmine - Feature #7030: link issue which belong to the same custom query Closed 2010-12-03
Duplicated by Redmine - Feature #7050: Navigation bar for faster issues handling Closed 2010-12-05
Duplicated by Redmine - Feature #7323: Previous/Next issue breadcrumbs Closed 2011-01-13
Duplicated by Redmine - Feature #976: add button Closed 2008-04-02

Associated revisions

Revision 8488
Added by Jean-Philippe Lang over 5 years ago

Adds previous/next links to issue (#2850).

Revision 8493
Added by Toshi MARUYAMA over 5 years ago

use i18n label for previous and next issue (#2850)

History

#1 Updated by Mischa The Evil over 8 years ago

Just my first thoughts on this FR:

Christian Zagrodnick wrote:

...there should be next/previous links on the ticket to navigate the list.

This could become a bit difficult and can lead to some confusion considering the fact that this could be understood as:
  1. The next issue in the list (as in: #2 is the next behind #1)
  2. The next issue in the list (as in: #10# is the next behind #1 respecting the current issue-query (filters) state)

What do you think?

#2 Updated by Christian Zagrodnick over 8 years ago

The second is what I was thinking about.

Actually I'm a long time Bugzilla user, so I may be a little biased. Let me describe what's happening there as I find this quite handy:

  • When you do a search and open a ticket from this search, you'll get those first/next/prev/last links.
  • There is also a link "show list" which takes you back to the list.
  • The list stays stable. That is that the search tickets h is only done once and Bugzilla stores the ticket ids for the list. This is probably the major trick because it really avoids confusion: say you list your open and fix a few. Going back to the list shows the fixed as fixed although the initial search filters for open onces.

Another thing is that when updating a ticket Bugzilla it doesn't display the updated ticket but the next one in the list.

Just my two cents :)

#3 Updated by Jens Goldhammer over 8 years ago

Sounds really good. Trac does the same...
As you both mentioned, there are different contexts:
1. If you browse the tickets without a search-> it should provide you a next and previous button for browsing to the ticket one number after the current or one before the current.

2. If you make a search or work in a custom report, the links should take you through the list as described by Christian.

I would like to see both things implemented! To make the difference understandable by the users, there should be good button labels ("next ticket" for normal browsing, "next ticket in search" for searching) and maybe tooltips.

Thanks,
Jens

#4 Updated by Christian Zagrodnick over 8 years ago

Jens Goldhammer wrote:

1. If you browse the tickets without a search-> it should provide you a next and previous button for browsing to the ticket one number after the current or one before the current.

Frankly, I don't see a use in that. Ticket numbers are basically random in regard to the ticket contents. Subsequent numbers usualy relate to totally unrelated tickets. Why would one want to navigate that?

I think when you navigate to a ticket without having a search (or if the ticket is not in the search list) those links should just be disabled until you get to a ticket which is in the list again.

#5 Updated by Enderson Maia over 8 years ago

Christian Zagrodnick wrote:

Frankly, I don't see a use in that. Ticket numbers are basically random in regard to the ticket contents. Subsequent numbers usualy relate to totally unrelated tickets. Why would one want to navigate that?

I agree. This ticket navbar just should be shown when you are in a filter/report result.

#6 Updated by Tom Burke over 8 years ago

+1 to this ticket.

I don't agree with Christian and Enderson's recent conversation about this not being useful. I've wanted this feature for a while because often as I'm creating new tickets, related tickets end up adjacent to one another in the project's list. Then later, when updating or closing, it would be useful to navigate to the next one, recalling that they fell next to each other.

I agree with the above that search context should be retained. And I like the stipulation that if the user closes a ticket, it still appears when he scrolls through his search results via next/previous, even if it was open when he searched for it.

Here's how I view the details of this feature:

  • By default, the First button navigates to the ticket whose ID is numerically the smallest, WITHIN THE PROJECT CURRENTLY BEING VIEWED.
  • By default, the Last button navigates to the ticket whose ID is numerically the greatest, WITHIN THE PROJECT CURRENTLY BEING VIEWED.
  • By default, the Next button navigates to the next greatest ID WITHIN THE CURRENT PROJECT.
  • By default, the Previous button navigates to the next least ID WITHIN THE CURRENT PROJECT.
  • Several navigational scopes should be identified, to determine how Next/Previous/First/Last will behave:
    • A "default" scope, where the user is navigating among all open tickets. This is the state reached when clicking on "Issues" for the first time.
    • A "search" scope, where the user is navigating among tickets resulting from his last search.
    • A "filter" scope, where the user is navigating among tickets resulting from his last filter via the Issues screen.
    • An "all" scope, where the user is navigating among all tickets throughout the system.
  • The search scope should be retained even if ticket statuses change, e.g., from open to Closed (see Christian's suggestion above:)

The list stays stable. That is that the search tickets h is only done once and Bugzilla stores the ticket ids for the list. This is probably the major trick because it really avoids confusion: say you list your open and fix a few. Going back to the list shows the fixed as fixed although the initial search filters for open onces.

#7 Updated by Cyber Sprocket about 8 years ago

+1

This would be a great feature. I've been wanting a "next issue" button since the 2nd day we've been on Redmine. It is very useful as a project manager to go through and bump dates, re-assign people,or change priorites as the issues for new projects/features tend to fall next to each other on the list.

Even more useful if it goes from the list you were looking at including any filters that were set.

#9 Updated by Nanda P about 8 years ago

+1

#10 Updated by Alex Last over 7 years ago

+1.
btw, can we have "votes" to avoid adding this stupid "+1"?

#11 Updated by Eric Wasylishen over 7 years ago

+1.
It would make reading through a list of issues a lot easier.

#12 Updated by Alexander Stehlik over 7 years ago

+1

#14 Updated by Aron Rotteveel over 7 years ago

+1

#15 Updated by minkbear minkbear over 7 years ago

+1

#16 Updated by Andrew Sherman over 7 years ago

+1

At my business we recently moved from Bugzilla to Redmine and the #1 questions I get from everyone is "there a next/prev link when you are going through your issues?"

#17 Updated by Kioma Aldecoa over 7 years ago

+1 we also are moving from bugzilla, and the one thing everybody misses is the next/prev links

#18 Updated by Ivo Abadjiev over 7 years ago

+ 1 we moved from JIRA and all the team is missing this feature

#19 Updated by David Parker over 7 years ago

+1

#20 Updated by Eric Peterson about 7 years ago

+1

#21 Updated by xt zhang about 7 years ago

+1

#23 Updated by John Bart almost 7 years ago

+1

#24 Updated by Emidio Stani almost 7 years ago

+1

#25 Updated by loic Le Gallou over 6 years ago

+1

#26 Updated by Ian Medland over 6 years ago

+1

#27 Updated by Sam Garnham over 6 years ago

+1

#28 Updated by Albert M over 6 years ago

+1

#29 Updated by Anton Lukashev over 6 years ago

+1

#30 Updated by Andrea Colleoni about 6 years ago

+1

#31 Updated by Andrew Lansdowne about 6 years ago

+1 this is a real issue for me moving from JIRA, I really don't mind how it is implemented (whether it updates the list when issues are amended or whether the list is static from your results) but just having to go back using the browser between viewing each issue just doubles the amount of clicking/waiting when you are trying to look through your issues.

#32 Updated by Etienne Massip about 6 years ago

  • Target version set to Candidate for next major release

#33 Updated by Marcel Ritter over 5 years ago

+1

#34 Updated by Jean-Philippe Lang over 5 years ago

  • Status changed from New to Closed
  • Target version changed from Candidate for next major release to 1.4.0
  • Resolution set to Fixed

Feature added in r8488 in its simplest form. The links show the previous and next issues as listed on the issue list without storing the query results.

#35 Updated by Maciej Maczynski over 5 years ago

I applied changes from r8488 over 1.3.0 installation (installed from tarball) hoping it would be enough to change only files mentioned in this release.
Looks it is not: I have the following error in log when clicking on issue from the list:

Rendering /var/www/redmine/public/500.html (500 Internal Server Error)

Processing IssuesController#show (for 192.168.115.8 at 2012-03-01 22:05:22) [GET]
  Parameters: {"action"=>"show", "id"=>"24", "controller"=>"issues"}

NoMethodError (undefined method `issue_ids' for #<Query:0xb560f1d4>):
  app/controllers/issues_controller.rb:289:in `retrieve_previous_and_next_issue_ids'
  app/controllers/issues_controller.rb:124:in `show'
...

The issue is not mentioned in 1.3.1 Changelog, so it is not included there, right?
Is there some kind of minimal-manual-changes to make it work with 1.3.0?

#36 Updated by Etienne Massip over 5 years ago

See r8487.

#37 Updated by Maciej Maczynski over 5 years ago

Yes you're right - it was necessary. But one more change was needed:
In r8488, show.html.erb line 42 is:

<td class="spent-time"><%= @issue.total_spent_hours > 0 ? (link_to l_hours(@issue.total_spent_hours), {:controller => 'timelog', :action => 'index', :project_id => @project, :issue_id => @issue}) : "-" %></td>

I changed it to original 1.3.0 version (not using "total_spent_hours":

<td class="spent-time"><%= @issue.total_spent_hours > 0 ? (link_to l_hours(@issue.total_spent_hours), {:controller => 'timelog', :action => 'index', :project_id => @project, :issue_id => @issue}) : "-" %></td>

Now it works!!! Thanks a lot for your help. After ten years using Bugzilla I missed this functionality VERY much.

#38 Updated by Sanjay Kashalkar over 5 years ago

After adding r8487 and r8488 onto Redmine 1.3.2.stable.6570 I can see the next/prev navigation links. However, deleting an issue fails with the following error.

Processing IssuesController#destroy (for 172.23.41.54 at 2012-03-21 11:28:34) [POST]
  Parameters: {"back_url"=>"/redmine/projects/opl/issues", "ids"=>["5589"], "action"=>"destroy", "authenticity_token"=>"Oe6ubDyrsKmGc7wRP6Qofw3XjpuUJwTTcWG5am5TF94=", "controller"=>"issues"}
Filter chain halted as [#<Proc:0x05646a98@C:/Program Files/BitNami Redmine Stack/ruby/lib/ruby/gems/1.8/gems/actionpack-2.3.14/lib/action_controller/verification.rb:82>] rendered_or_redirected.
Completed in 68ms (View: 6, DB: 31) | 405 Method Not Allowed [http://abcdef/redmine/issues/destroy?back_url=%2Fredmine%2Fprojects%2Fopl%2Fissues&ids%5B%5D=5589]

Any ideas why?

To reproduce simply select one or more issues and right click 'delete'.

#39 Updated by Maciej Maczynski over 5 years ago

I have exactly same problem: after applying those changes I cannot delete issues any more.
I did not report it so far as I had no time to verify 100% if this is really caused by this change or maybe some plug-in I've installed.
But your post seems to confirm that the problem is related revisions mentioned hare: I also have this "Method Not Allowed" error now.

#40 Updated by Maciej Maczynski over 5 years ago

Solved: you have to apply changes from r8150.

Also available in: Atom PDF