ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Drag-and-drop issue (ticket) ordering (Feature #600)


Added by James Robertson at 2011-09-01 02:57 am. Updated at 2011-09-05 11:29 pm.


Status:Open Start date:2011-09-01
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:Issue tracking
Target version:-
Remote issue URL:http://www.redmine.org/issues/8016 Affected version:

Description

We would really like to be able to specify an exact order for the resolution of tickets, by dragging and dropping them into order.

Ideally priority should be automatically modified (ie. if an Urgent is moved 'below' a High it should be re-prioritised as High)

Alternatively, optionally the Priority of tickets (eg. Urgent, High, Normal and Low) should be respected (ie. can not drag a High beneath a Normal or above an Urgent). [Tricky]

New tickets should automatically be ordered at the bottom of their Priority.

Scenario 1:
We have several customer who websites/applications we support. We provide a fixed number of hours of support per month. In some cases there are many tickets (High, Medium (Normal) and Low) to be worked through over a period of months. The customer would like to be able to specify, and adjust, an exact order for these tickets.

Scenario 2:
We use Redmine to manage in progress, Agile projects. Our Agile methodology calls for all tickets (Stories) to be ordered and re-ordered as priorities change.

In neither of these scenarios are start or end dates used. Also, although there is an implied "precedence" between the tickets there is no technical basis for this. (Besides; setting and changing individual "precedes" and "follows" manually, would be very painful in these cases.)

Many thanks

[Copied from http://www.redmine.org/issues/8016, since we're now using Chiliproject :-]


Related issues

related to Feature #606: Update grouped tickets/issues using drag-and-drop Open 2011-09-05

History

Updated by Felix Schäfer at 2011-09-01 04:31 am

James Robertson wrote:

[Copied from http://www.redmine.org/issues/8016, since we're now using Chiliproject :-]

Glad to hear that :-)

Short answer: Not gonna happen, at least not soon, because having an order for tickets would need more granularity than there already is in ticket priorities.

Longer answer: But you might be interested in some plugins that could solve your problem. Have a look at the stuff to do plugin from Eric (should be supported in ChiliProject as Eric is a core committer here :-) ), or if you can wait a little, there might be a scrum plugin (more precisely: an internal fork of redmine backlogs) coming, can't say how soon though.

  • (deleted custom field) set to http://www.redmine.org/issues/8016
  • Category set to Issue tracking

Updated by James Robertson at 2011-09-01 10:17 pm

Hi Felix.

Really appreciate the feedback. Yes, I'm keen to use Redmine Backlogs and have started a separate conversation with friflaj (https://github.com/relaxdiego/redmine_backlogs/issues/205#issuecomment-1965504).

I've been thinking about this feature some more and realise that a firs-cut implementation can actually be a lot simpler than I first described:
  • New custom field data-type: "sort order" (?)
  • Store as integer (1 is highest sort order)
  • Must be unique within (open) tickets of a project
  • On save, if the sort order integer has changed, any (one) ticket with the same or higher sort order integer are deprecated by one.
  • Add drag-and-drop to any Issue (ticket) filter that is sorted on a "sort order" field.
  • new/re-opened tickets are assigned the next highest integer (i.e appear at bottom of list)
  • Forget about everything else! :-)

Lots more stuff could be added later, but this would be a great first step! What do you think? Any more likely now? :-)

Cheers
James

Updated by Felix Schäfer at 2011-09-05 06:08 am

James Robertson wrote:

Really appreciate the feedback. Yes, I'm keen to use Redmine Backlogs and have started a separate conversation with friflaj (https://github.com/relaxdiego/redmine_backlogs/issues/205#issuecomment-1965504).

(not the topic of this issue, so if you have more problems with this please open a new discussion in the forums. Regarding prawn or any gem backlogs needs: ChiliProject uses bundler to specify what gems it needs, which consequently also makes those gems only available to ChiliProject, prawn isn't one of the core gem set, so it isn't visible to ChiliProject. There's a mechanism to add gems to the "core" Gemfile from within a plugin, for this you just have to add a Gemfile to the root directory of the plugin, to add prawn just write gem 'prawn' in there)

I've been thinking about this feature some more and realise that a firs-cut implementation can actually be a lot simpler than I first described:
  • New custom field data-type: "sort order" (?)

Custom fields is one of the things we're not happy with and where there's probably not going to be any (big) development for until we have remodeled it :-/

  • Store as integer (1 is highest sort order)
  • Must be unique within (open) tickets of a project

What do we do when viewing a project with subprojects? The issue list then shows the whole issue list…

  • On save, if the sort order integer has changed, any (one) ticket with the same or higher sort order integer are deprecated by one.

This would mean updating a value on all tickets with a "sort order" higher than the one we're being put to, i.e. potentially all records. Not very efficient.

  • Add drag-and-drop to any Issue (ticket) filter that is sorted on a "sort order" field.
  • new/re-opened tickets are assigned the next highest integer (i.e appear at bottom of list)
  • Forget about everything else! :-)

So you see it's not that easy a matter…

Updated by James Robertson at 2011-09-05 11:29 pm

Hi Felix

OK, thanks for clarifying the complexity of this feature request. If/when anyone does want to work on this ticket, I'd be more than happy to come up with responses/use cases for the issues you present. :-)

For what it's worth [obviously very self interested here but ...] I reckon this, and a couple of other features I have requested recently (#606, #608), would go a long way toward meeting the goal of having Chiliproject be a great project management tool - for Agile-style projects.

(Also, thanks for the info re Chiliproject and Redmine Backlogs, which I have copied into the relevant Redmine Backlogs ticket thread (https://github.com/relaxdiego/redmine_backlogs/issues/205#issuecomment-1965504). Hope you don't mind.)

Cheers
James (Ponoko)

Also available in: Atom PDF