> Feature : A way to add a numerical field that can be managed in bulk. > This field will be our priority for about 300 tickets. (It will > basically order the list).
So Steffen tried to help you with a technical solution to the problem... but I think you might have a different problem entirely. Why exactly do you need to have a priority for all 300+ tickets? As Steffen mentioned in his thoughts about a technical solution related to the large number of ticket change updates, the fact that there would be this huge number of updates (lets say I insert a ticket at slot 150... I now have to update all of the tickets after it...). The fact that horrible and ugly things like this are happening makes me suspect there's probably an issue with the process that your using. If you need finer grained management of the tickets... why not make use of Trac's existing grouping capabilities? You can group tickets in a variety of ways using Milestones, Components, Priorities, Severities to achieve an extremely fine grain classification of your tickets. And if this is for a software development project... are you really working through 300+ tickets in such a short period of time and with enough developers that keeping order across the ticket pool is even necessary? Investing the time to develop a custom Trac plug-in is a liability[1,2]... maybe a change to your processes could be made that would save you the trouble since what you're currently proposing sounds overly complex to me. Ben [1] http://teddziuba.com/2010/10/taco-bell-programming.html [2] http://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
