Making tickets' custom fields available in the sprints' ticket lists. #12
Conversation
… Custom fields do not show by default, and can be activated in the preferences pane.
|
On the whole, this looks pretty good. Unfortunately, I have a lot happening over the next week. Ping me again in a couple of weeks if you haven't seen any activity. |
|
That's fine |
|
Bump? |
|
Thanks for the nudge! Unfortunately, I can't get to it this week, but it's my top priority for next week. |
|
Cool! Really looking forward to this :) |
|
@filipefigcorreia Do you mind fixing up the log messages so that it follows the guidance in Tim Pope's blog post here? Otherwise, I think the patch looks good. Thanks! |
|
Hi. Is it ok to change it after pushing it to github? I think might break other people's repositories if I do so. |
|
Sorry to be persistent on this point, but I believe it's worth the effort. If anybody has pulled this into their repo, it's on them to deal with the fact that the commit has changed. My expectation is that contributors be willing to squash and fix-up things as needed. I realize others work differently, but this is the way I like to run my ship. :-) I hope you understand. Thanks! |
|
Perfectly :) I can try to look into it next week (no promises though...) |
|
Bump! |
|
Sorry, I never got around to improving the commit message as @jszakmeister suggested. And it's unlikely that I will be able to in the coming weeks :( |
|
No problem :) I was just worried that this had slipped everyones mind :) |
|
Bump! |
This is a pull request for the topic that I originally submitted as issue #9.
Custom fields do not show by default, and can be activated in the preferences pane for each user. This is something that may be worth to rethink in the future, as it may be useful to decide which fields should be shown by default when installing/configuring the plugin.
I tried making the code as DRY as possible, and took the chance to refactor a couple of details. I see more that can be improved, but I'd leave that for a future refactoring.