Certain fields should be able to have default values, or not have default values. If a field has no default value, it must be specified on enter_bug.cgi or Bugzilla will throw an error.

We are in "soft freeze" mode to prepare 3.0 RC1.

Here's what we did for PRACA, to give defaults to <select> fields. It won't all apply upstream, but it should be a good basis to work from. We should combine my previous WIP patch and this to get defaults for all fields.

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Max, I'm starting on this one as the pre-req to bug 449161. I'll see about adding your attachments from comment 3 to HEAD and add whatever else has to be done. I like the idea of using editvalues.cgi to maintain the values, or at least that's the direction it looks like your patch wants to go. :) Does that the correct interpretation of the goal? It also seems like we only want this to apply to drop-down and multi-select. True? I'd love to give every type a default, but that's more like "is_mandatory" functionality and not "is_default" functionality. Kevin

Note: from experience, watch out for ---, with this kind of patch,it may not even exist at all as a legal value.

(In reply to comment #5) > Max, I'm starting on this one as the pre-req to bug 449161. I'll see about > adding your attachments from comment 3 to HEAD and add whatever else has to be > done. I like the idea of using editvalues.cgi to maintain the values, or at > least that's the direction it looks like your patch wants to go. :) Does that > the correct interpretation of the goal? Yeah, that's right. It should be much easier now that it was when I did it for PRACA, since we've come a long way in terms of architecture since then. However, one new thing we do have is the "fields that control the value lists of other fields" option. I wouldn't worry about that in this patch, though. Just allow one is_default field for single-select fields for now, and if it doesn't show up, oh well! The first item in the list will be the default instead. (Or whatever ends up being the simplest to implement.) > It also seems like we only want this to apply to drop-down and multi-select. > True? True. > I'd love to give every type a default, but that's more like > "is_mandatory" functionality and not "is_default" functionality. Kevin Yeah, I don't think it's that important for freetext and textarea fields to have defaults--I think you'd probably just end up with a lot of people filing bugs with the default values instead of empty values, which isn't that helpful.

Taking, as we need it to fix bug 449161.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

I'm new to Bugzilla, running 4.4.6, and went looking for a way to create a default value for a custom list. Is this still in work? Or has it been resolved and I'm missing something? Thanks, and am pretty impressed by this so far. This is the only thing I'm stuck on before going live.