651478 - Add ability to deactivate custom fields

Status: NEW

(Bugzilla :: Bugzilla-General, enhancement)

Description

[:glob ✱]

Currently you can obsolete custom fields, which always removes them from the UI.  I'd like the ability to deactivate custom fields, which would remove them from the UI unless a value has been set.

Comment 1

[Max Kanat-Alexander]

That should be how obsoleting works, ideally. Perhaps display it read-only if it had a value set? Or some option? Not quite sure. I suppose it would help to know--what's the use case?

Comment 2

[:glob ✱]

(In reply to comment #1)
> what's the use case?

we're using custom fields as multi-state flags, so we need to be able to deactivate old ones but still have them visible on old bugs.

Comment 3

[Max Kanat-Alexander]

Okay. I think obsoleting should just work the way that you want. If the field is set to some value that isn't the "empty" value, it should simply be displayed, much like how flags work now.

Comment 4

[Frédéric Buclin]

This would be annoying, because if you have a custom field which you no longer use, it would be visible in the UI forever (you are not going to remove text from free text forms, and there is no empty value for single-select fields).

Comment 5

[Max Kanat-Alexander]

"---" is the empty value for single-select fields.

My suggestion (and this may be clearer now that I've thought about it more) is that they behave like disabled flags.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
> My suggestion (and this may be clearer now that I've thought about it more) is
> that they behave like disabled flags.

OK, but this should be a separate option from hidding them entirely. Because when you don't use a custom field at all and it has no historical interest, even displaying them as read-only may be confusing to users. So we would have both "obsolete" and "deactivate" as options.

Comment 7

[Max Kanat-Alexander]

I thought about that. I think that glob's case is actually more common--I suspect that in the case where a custom field isn't used at all, it will be set to the "empty" value on most bugs and thus will disappear. Also, you could do a mass-change to set all bugs to the empty value and make them all disappear if you really wanted to.

Comment 8

[:glob ✱]

(In reply to comment #6)
> OK, but this should be a separate option from hidding them entirely. Because
> when you don't use a custom field at all and it has no historical interest,
> even displaying them as read-only may be confusing to users.

if that's the case, why wouldn't you simply delete the field?

Comment 9

[:glob ✱]

(In reply to comment #8)
> if that's the case, why wouldn't you simply delete the field?

oh, because you can't drop the column if it has ever been used due to entries in the activity table.

Comment 10

[Max Kanat-Alexander]

  But you could still set them all manually to empty to make the field disappear, so we don't need a separate option.

Comment 11

[:glob ✱]

general consensus is to:
  - change 'delete' to actually remove the field from the database
  - change/rename 'obsolete' to hide the field from the UI unless there's a value set

when the field is removed from the database we still need to retain entries in the bugs_activity, which implies that the fielddefs row will also need to be retained (but marked as obsolete).

fielddefs has a uniqueness constraint on name, so to allow recreation of identically named fields we should also rename the fielddefs entry to something like 'deleted_cf_test', 'deleted2_cf_test', ...

Comment 12

[Max Kanat-Alexander]

>   - change 'delete' to actually remove the field from the database

  That's actually what delete does now.

>   - change/rename 'obsolete' to hide the field from the UI unless there's a
> value set

  Cool, that sounds great to me.

> when the field is removed from the database we still need to retain entries
> in the bugs_activity, which implies that the fielddefs row will also need to
> be retained (but marked as obsolete).

  For various reasons, if a field remains in fielddefs, you should not remove it from the bugs table.

Comment 13

[:glob ✱]

(In reply to comment #12)
> >   - change 'delete' to actually remove the field from the database
> 
>   That's actually what delete does now.

sorry, i'll rephrase:

- change 'delete' to remove the field from the database even if there are values set.

>   For various reasons, if a field remains in fielddefs, you should not
> remove it from the bugs table.

ah, that puts a spanner in the works then.