-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.02.2012 22:59, wrote Jean-Francois Bouchard: > Answers inline ! Sure.
>> Am 20.02.2012 20:00, wrote Jean-Francois Bouchard: >>> Hello, ... > Is a good way to get attention is to make a bounty of the feature ? > Or Even a bounty does not get much attention ? The best pre-requisite is a developer, that needs it, so it's reasonably sure, that he/she will take the time. Or pay one. Anything else is not very reliable, because any active Trac developer I know of already has a backlog of pending issues. >> About your description: Do you plan to assign a given priority only >> once, so it's equal to a flexible index number, or do you appeal >> just for many levels assigned to one _or_ multiple tickets? > > Only one ticket would have a priority. Its a unique index. I see. > I think being able to get a logic to renumber that priority is quite > important because of the quantity of tickets. Of course. > I nice logic would be to use decimal to renumber. (ex : while doing > a ticket, but 10.1 in priority. After submit, that ticket would get > priority 10 and all ticket that was 10 and < would now be 11 and <. Whatever. Given the uniqueness constraint I still would go for an int-only solution and only renumber ON ins/mv/rm, not afterwards, so that you never end up with invalid decimal entries. >> It looks like you describe the requirements for a ticket ID/group >> ID custom ticket field and corresponding plugin capabilities. > > yeah, for us its a way to know what bug we like to close next. And > our product management team can use that tool to drive ticket > closing ! Well, just beware this could tend to generate rather messy change history with one more comment for every change on every affected ticket, if you go with the recommended recording of every ticket field change. A so nice little plugin development then. Just some random implementation ideas: Add a line with some drop-down fields into ticket property editor section or even TicketWorkflow to trigger plugin actions: raise above <select nr>|drop below <select nr> Remove would be done automatically on closing a ticket via ITicketChangeListener. /newticket would have to add before <select nr> with default to just append with the lowest, next number, but could even be configurable, i.e. to always inserting at the top or at another fixed position by number in-between. Yours, Steffen Hoffmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9CzigACgkQ31DJeiZFuHeTngCeMrzaC37lHLKyBL4I9G05m6Rn zzkAnRYQEApr2jBrjs5IpCUbpiaOPxBM =smd1 -----END PGP SIGNATURE----- -- 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.
