History

owner should autocomplete with the list of all the existing ticket owners (254)

• owner set to jesse@bestpractical.com
• creator set to jesse
• original_replica set to 4AA041B6-E5C6-11DD-A0BF-4BB0457005E2
• status set to new
• reporter set to jesse@bestpractical.com
• created set to 2009-01-19 01:44:33
• component set to webui
• summary set to owner should autocomplete with the list of all the existing ticket owners
• milestone set to cavil

"add a comment" and "initial comments" boxes should be centered (253)

• owner set to jesse@bestpractical.com
• creator set to jesse
• original_replica set to 4AA041B6-E5C6-11DD-A0BF-4BB0457005E2
• status set to new
• reporter set to jesse@bestpractical.com
• created set to 2009-01-19 01:44:04
• component set to webui
• summary set to "add a comment" and "initial comments" boxes should be centered
• milestone set to cavil

Comment on: summary field shouldn't try to autocomplete (222)

• created set to 2009-01-19 01:43:07
• creator set to jesse
• original_replica set to 4AA041B6-E5C6-11DD-A0BF-4BB0457005E2
• content set to Got sorted out sometime over the past few weeks
• ticket set to B9FD0960-DEA8-11DD-A16D-3B073D5AF197

summary field shouldn't try to autocomplete (222)

• status changed from new to closed

owner field should default to "me" (220)

• status changed from new to rejected

Comment on: owner field should default to "me" (220)

• created set to 2009-01-19 01:41:31
• creator set to jesse
• original_replica set to 4AA041B6-E5C6-11DD-A0BF-4BB0457005E2
• content set to I've had a change of heart. I think that the "Take" button is perfectly sufficient for this
• ticket set to A59880BC-DEA8-11DD-A16D-3B073D5AF197

owner field should default to "me" (220)

Comment on: create/edit ticket forms need styling (221)

• created set to 2009-01-19 01:36:51
• creator set to jesse
• original_replica set to 4AA041B6-E5C6-11DD-A0BF-4BB0457005E2
• content set to They got a bit of basic styling
• ticket set to AE4C1CF0-DEA8-11DD-A16D-3B073D5AF197

create/edit ticket forms need styling (221)

• status changed from new to closed

common_ticket_props should be overrideable by a config file setting (243)

• summary changed from default_props_to_show should be overrideable by a config file setting to common_ticket_props should be overrideable by a config file setting

prop values should be able to be force-set with ! (249)

• owner set to spang@bestpractical.com
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• status set to new
• reporter set to spang@bestpractical.com
• created set to 2009-01-16 15:24:26
• component set to core
• summary set to prop values should be able to be force-set with !
• milestone set to cavil

Comment on: props with recommended values are not fully extensible (247)

• created set to 2009-01-16 15:20:25
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• content set to 09:46 < christine> what I was pointing out was: say your project wants to use a non-standard property a lot. and it wants that property to have a range of recommended values like status or milestone do now. you can't do that right now without editing sd's code. because every prop that has a list of recommended values has to have a _recommended_values_for_prop_$prop method. 09:47 < obra> oh, yes. I can totally believe that at some point in the glorious future we want an easy way to projects to define custom props with custom lists of recommended values 09:47 < obra> "not 1.0"
• ticket set to 32717AEC-E3E1-11DD-B38B-EC548232C628

props with recommended values are not fully extensible (247)

• created set to 2009-01-16 15:20:24
• summary set to props with recommended values are not fully extensible
• component set to core
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• status set to new
• milestone set to diana
• reporter set to spang@bestpractical.com

Comment on: template tests should compare lines not entire template (245)

• created set to 2009-01-16 12:26:07
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• content set to Refactoring this in would make debugging a lot easier when things don't match up. And maybe we want to unify the search-and-replace and regex templates to just all be regex templates while we're at it. Can we factor out any of the template comparison stuff to be shared between the create and update tests?
• ticket set to D929A2E2-E3C8-11DD-B8D2-23398232C628

template tests should compare lines not entire template (245)

• owner set to spang@bestpractical.com
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• status set to new
• reporter set to spang@bestpractical.com
• created set to 2009-01-16 12:26:06
• component set to core
• summary set to template tests should compare lines not entire template
• milestone set to cavil

sd should handle multiple dbs (237)

• owner set to spang@bestpractical.com

sd help init should redirect to sd help intro (231)

• status changed from new to closed

sd ticket create needs a verbose mode (178)

• status changed from open to closed

• content changed from [{"due":"when this ticket must be finished by (ISO 8601 format)","owner":"the email address of the person who is responsible for this ticket","reporter":"the email address of the person who reported this ticket","summary":"a one-line summary of what the ticket is about"}] to [{"due":"when this ticket must be finished by (ISO 8601 format)","owner":"the email address of the person who is responsible for this ticket","reporter":"the email address of the person who reported this ticket","summary":"a one-line summary of what this ticket is about"}]

Comment on: common_ticket_props should be overrideable by a config file setting (243)

• created set to 2009-01-14 20:27:53
• creator set to spang
• original_replica set to 9A3BFB90-B748-11DD-B155-797E8947A455
• content set to 13:07 < obra> christine: I'm not sure about making default_props_to_show a project-wide db setting rather than a config file setting. can you tell me about your rationale? 15:15 < christine> hmm. I hadn't actually considered config file setting vs db setting. I was just thinking it shouldn't be hard-coded/not changeable. 15:17 < christine> on the one hand it makes sense to be a db setting if e.g. a project uses a non-standard prop heavily, but on the other hand users might want to change it, I guess. 15:22 < obra> perhaps "db setting overridable by config file setting"?
• ticket set to D1EABE80-E279-11DD-BC55-CEB220C5F1DA