Feature Proposal: Need to specify defaults on radio and checkbox fields

Motivation

As per Item11928 a recent change was implemented to ensure it's now WAD (working as designed).

However, it's also BAD (broken as designed).

Need to add option to specify defaults

Description and Documentation

We need a reasonably simple way to extend the existing radio/checkbox fields (any others?).

Solution: Add an optional Default column

Name	Type	Values	Description	Attributes	Default
Invoiced	radio	yes, no		M	no

in the absence of a value in the Default column, we fall back to undef for radio and checkbox, and first value for the others?

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: JulianLevens, MichaelDaum - 08 Jun 2012

Discussion

Hm, this also means that you won't be able to use the & in your values list, which might be quite a problem when the values are computed dynamically using some TML expression.

The most obvious way is to have another column holding the default value:

Name	Type	Values	Description	Attributes	Default
Invoiced	radio	yes, no		M	no

-- MichaelDaum - 08 Jun 2012

Adding a new column as Michael suggests adds better functionality while supporting the older ways.

nice.

-- SvenDowideit - 08 Jun 2012

The suggested alternative makes sense to me.

Michael you seem the obvious CommittedDeveloper to me :), you've done work recently here (+values) and it's urgent. Do you want to add yourself?

-- JulianLevens - 08 Jun 2012

Quick thought, why not yes, no=on, a mix of key-value and boolean value.

-- ArthurClemens - 08 Jun 2012

This would break +values definitions.

-- MichaelDaum - 09 Jun 2012

+1 for a new column. Semantics should be that if there is a default column, it overrides any implied default in the values column.

-- CrawfordCurrie - 12 Jun 2012

AcceptedBy14DayRule: we will go with alternative 2.

-- MichaelDaum - 22 Jun 2012

we really can't afford to implement such a thing in a 1.1.6 patch release, so I've reverted the Tasks.Item11666 change from the 1.1 branch - it has hidden consequenses for pretty much all users. This frees up this feature to be implemented in 1.2.0 - I may be the one that has to do it, as Micha is too busy with other work right now.

-- SvenDowideit - 22 Oct 2012

Was planned for 1.2.0. 1.1.x is fixes only.

-- MichaelDaum - 22 Oct 2012

Commenting is disabled while not logged in