1) The save should be reliable. I haven't tested it on large numbers of tickets, but changes are saved in a single transaction.
2) Currently the columns resize to the height of the largest column when dragging tickets. They do not scroll independently, but this is something I could look at. Also, realistically you cannot display more than 5 columns at a time. Any more than that and you start getting a horizontal scroll bar on each column. I'm not sure what the best way to handle this is yet. I anticipate there will a fair amount of UI tweaking once I start getting some feedback. Trac 0.11.x support is coming as well. I just started working on porting it back to 0.11.x, but it doesn't quite work yet. I'm having some problems with the older version of jQuery. On Aug 30, 10:05 am, "David.Frahm" <[email protected]> wrote: > This is something that I think my team could really use. I need to > get us upgraded to Trac 0.12 anyway, and when I do I'll try it and > give you some real-world feedback. > > In the meantime, a couple thoughts/questions: > > 1. How reliable is the 'save' at the end? We would spend a lot of > time on that screen, pulling things from our Product Backlog. After > all that work, it would be really bad if something went wrong when we > tried to save it. > > 2. For managing something like Product Backlog, we would have a really > long list. Your screenshots show only a few tickets, so I couldn't > tell how that would display. If each doesn't scroll independently, I > would think you'd tire of scrolling around so much. I used a tool > called ScrumWorks that handled this very well (it just didn't have > other features we needed so we went with Trac). -- You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en.
