Redmine

Just my first thoughts on this FR:

Christian Zagrodnick wrote:

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

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?

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 :)

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

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.

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.

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

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

+1 !

+1

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

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

+1

+1

+1

+1

+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?"

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

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

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

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

+1

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?

See r8487.

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.

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

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.

Solved: you have to apply changes from r8150.