Feature #2850
closedAdd next/previous navigation to issue
Added by Christian Zagrodnick over 15 years ago. Updated over 12 years ago.
0%
Description
When opening an issue from an issue list there should be next/previous links on the ticket to navigate the list.
Related issues
Updated by Mischa The Evil over 15 years ago
Just my first thoughts on this FR:
Christian Zagrodnick wrote:
This could become a bit difficult and can lead to some confusion considering the fact that this could be understood as:...there should be next/previous links on the ticket to navigate the list.
- The next issue in the list (as in:
#2
is the next behind#1
) - 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?
Updated by Christian Zagrodnick over 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 :)
Updated by Jens Goldhammer over 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
Updated by Christian Zagrodnick over 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.
Updated by Enderson Maia over 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.
Updated by Tom Burke about 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.
Updated by Cyber Sprocket about 15 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.
Updated by Alex Last over 14 years ago
+1.
btw, can we have "votes" to avoid adding this stupid "+1"?
Updated by Eric Wasylishen over 14 years ago
+1.
It would make reading through a list of issues a lot easier.
Updated by Andrew Sherman over 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?"
Updated by Kioma Aldecoa over 14 years ago
+1 we also are moving from bugzilla, and the one thing everybody misses is the next/prev links
Updated by Ivo Abadjiev about 14 years ago
+ 1 we moved from JIRA and all the team is missing this feature
Updated by Andrew Lansdowne about 13 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.
Updated by Etienne Massip about 13 years ago
- Target version set to Candidate for next major release
Updated by Jean-Philippe Lang over 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.
Updated by Maciej Maczynski over 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?
Updated by Maciej Maczynski over 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.
Updated by Sanjay Kashalkar over 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'.
Updated by Maciej Maczynski over 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.
Updated by Maciej Maczynski over 12 years ago
Solved: you have to apply changes from r8150.