Custom Fields
I know this has been requested by others in the past with no fruition, but I find myself needing to ask for it now. One of the things I like about Lighthouse over the very complicated and expensive other bug tracking systems I've used and evaluated is that it achieves so much of what I need with so little and stays simple -- so I resisted making this request until I needed it enough that I'd likely have to switch to another solution, which is the point I'm at now.
Tags can be used (to varying degrees of success) where custom fields would be used in other issue tracking systems, and we have done so. However, there is a class of information that can't be adequately represented this way. For example, we track our time for billing purposes in another system, and so we need a way to know which billing project a given Lighthouse ticket should be associated with. If we could create a custom field (say, "billingProject") then we could do the following:
- have this information in a uniform place in each ticket
- search for tickets which do or do not have a billing project associated with it (so that one can be assigned, or perhaps to consider those which do not have one to be lower priority)
- use the API to automatically populate that field or pull from that field
I don't think this can be adequately solved using existing Lighthouse functionality. The options I can see are:
- Use tags Problems:
- Our billing system is dumb, and generates long and crazy project IDs
- There are lots of billing projects, so there would be hundreds of these tags to wade through
- Just put it free-form in the description or a comment Problems:
- Unless we force a rigid notation convention (like "Billing Project: <asdfdsfasdf-8484>" on a line by itself or something), we can't search for the presence of one, nor pull them easily with the API.
Or am I missing a solution?
Thanks.
Discussions are closed to public comments.
If you need help with Lighthouse please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Will Duncan on 03 Sep, 2008 06:48 PM
Dan, I was clearing spam out of the forums and I believe I accidentally deleted another post from you. My sincere apologies.
2 Posted by Dan Moore on 03 Sep, 2008 06:49 PM
I think so too.
You can make it up to me by implementing custom fields ;)
3 Posted by Dan Moore on 08 Sep, 2008 05:51 PM
Incidentally, there are a couple API-related projects I'd like to do which would be very hard without custom fields...
4 Posted by Raymond Brown on 04 Nov, 2008 07:37 PM
I support this request also. Just one additional customizable field makes all the difference when needing a hook for integration.
5 Posted by Dan Moore on 04 Nov, 2008 08:10 PM
I think two of us constitutes a mandate ;)
6 Posted by Will Duncan on 06 Nov, 2008 10:45 PM
Haha... well thanks for the input. If such a feature does happen, it won't be in the near future though. I'll let you know more when we discuss it again though.
7 Posted by James Huggett on 13 Nov, 2008 04:41 PM
I'm a QA engineer that just joined a small development company using Lighthouse. Lighthouse is pretty lean compared to the heavier issue trackers I'm used to at larger companies, but I do like it.
However, as others have expressed here, tags are weak for certain types of data (prone to noise/duplicate variants) and a couple of custom fields would be a lot of use - for severity for instance, or differentiating between bugs/new feature work.
I understand that the lighthouse paradigm is use tags but some attributes just need more enforced gatekeeping/formality than tags provide....tags are too 'voluntary' and hard to manage.
Certainly among QA and management types, appeal of this issue would increase with custom fields (and reports/report export.... EVENTUALLY a client or upper management type is going to ask for a pretty graph :-)