Project

General

Profile

Actions

Feature #2850

closed

Add next/previous navigation to issue

Added by Christian Zagrodnick about 15 years ago. Updated almost 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
Start date:
2009-02-26
Due date:
% Done:

0%

Estimated time:
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

Has duplicate Redmine - Feature #3337: Button Next/Previous on issue formClosed2009-05-11

Actions
Has duplicate Redmine - Feature #4028: Ability to navigate to next and previous issue from an open issueClosed2009-10-14

Actions
Has duplicate Redmine - Feature #4583: Add the ability to navigate in issuesClosed2010-01-14

Actions
Has duplicate Redmine - Feature #5361: Next / previous issue featureClosed2010-04-21

Actions
Has duplicate Redmine - Feature #7030: link issue which belong to the same custom queryClosed2010-12-03

Actions
Has duplicate Redmine - Feature #7050: Navigation bar for faster issues handlingClosed2010-12-05

Actions
Has duplicate Redmine - Feature #7323: Previous/Next issue breadcrumbsClosed2011-01-13

Actions
Has duplicate Redmine - Feature #976: add buttonClosed2008-04-02

Actions
Actions #1

Updated by Mischa The Evil about 15 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?

Actions #2

Updated by Christian Zagrodnick about 15 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 :)

Actions #3

Updated by Jens Goldhammer about 15 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

Actions #4

Updated by Christian Zagrodnick about 15 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.

Actions #5

Updated by Enderson Maia about 15 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.

Actions #6

Updated by Tom Burke almost 15 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.

Actions #7

Updated by Cyber Sprocket over 14 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.

Actions #8

Updated by Philippe Lafoucrière over 14 years ago

+1 !

Actions #9

Updated by Nanda P over 14 years ago

+1

Actions #10

Updated by Alex Last about 14 years ago

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

Actions #11

Updated by Eric Wasylishen about 14 years ago

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

Actions #12

Updated by Alexander Stehlik about 14 years ago

+1

Actions #14

Updated by Aron Rotteveel almost 14 years ago

+1

Actions #15

Updated by minkbear minkbear almost 14 years ago

+1

Actions #16

Updated by Andrew Sherman almost 14 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?"

Actions #17

Updated by Kioma Aldecoa almost 14 years ago

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

Actions #18

Updated by Ivo Abadjiev almost 14 years ago

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

Actions #19

Updated by David Parker over 13 years ago

+1

Actions #20

Updated by Eric Peterson over 13 years ago

+1

Actions #21

Updated by xt zhang over 13 years ago

+1

Actions #23

Updated by John Bart over 13 years ago

+1

Actions #24

Updated by Emidio Stani over 13 years ago

+1

Actions #25

Updated by loic Le Gallou about 13 years ago

+1

Actions #26

Updated by Anonymous about 13 years ago

+1

Actions #27

Updated by Sam Garnham almost 13 years ago

+1

Actions #28

Updated by Albert M almost 13 years ago

+1

Actions #29

Updated by Anton Lukashev almost 13 years ago

+1

Actions #30

Updated by Andrea Colleoni over 12 years ago

+1

Actions #31

Updated by Andrew Lansdowne over 12 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.

Actions #32

Updated by Etienne Massip over 12 years ago

  • Target version set to Candidate for next major release
Actions #33

Updated by Marcel Ritter about 12 years ago

+1

Actions #34

Updated by Jean-Philippe Lang about 12 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.

Actions #35

Updated by Maciej Maczynski about 12 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?

Actions #36

Updated by Etienne Massip about 12 years ago

See r8487.

Actions #37

Updated by Maciej Maczynski about 12 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.

Actions #38

Updated by Sanjay Kashalkar almost 12 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'.

Actions #39

Updated by Maciej Maczynski almost 12 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.

Actions #40

Updated by Maciej Maczynski almost 12 years ago

Solved: you have to apply changes from r8150.

Actions

Also available in: Atom PDF