Latest custom field revisions

[Sean McAfee]

Joel Peshkin <bugreport at peshkin.net> wrote:
>In general, this looks very good.  There are a few details not yet 
>addressed which I think should be ....

>1) What happens when a bug is moved to a product on which the custom 
>field is not relevent and then is subsequently moved to a product where 
>it is?  (I suggest that the field be made invisible while in the product 
>where it is not irrelevent but not lost)

I'd rather keep it simple and say that a field which is not shared by
both the old product and the new one is lost.  In a straightforward
implementation, custom fields are contained by products or field groups,
not by individual bugs.  Also, consider the extreme case:  If a bug is moved
among each product, it ends up carrying around a copy of every custom field
in the installaion.

An alternative approach might be to provide a "Store custom fields
in comment" checkbox when a bug is moved from one product to another.
If it's checked, fields which are not shared between the old and new
products are stored in a human-readable form in a comment.

>2) Which name is used for the activity log?

I dunno..."Custom Field Activity Log", I suppose.

>3) What happens to the activity log on field rename?  (It should stay 
>consistent)

Yeah, that's what one would reasonably expect.  DB references to fields will
be by ID number, so this shouldn't require any special handling.

>4) In the standard templates, there will no doubt be a routine that 
>handles the custom fields.  If a site customizes the templates, can they 
>indicate that a field is "already done" so the routine skips a specific 
>field and leaves it to template customizations?

Yeah, that could be done via a reserved variable, or implicitly, as I
proposed earlier:

------------------------------------------------------------
<p>
  Here are some really important fields:
</p>

[% PROCESS custom_field name = 'important_field_one' %]
[% PROCESS custom_field name = 'important_field_two' %]

<!-- other text -->

<p>
  Here are the run-of-the-mill fields:
</p>

[% PROCESS show_custom_fields
   #  important_field_one and important_field_two are implicitly skipped,
   #  since they were already processed via the prior custom_field blocks
%]
------------------------------------------------------------

-- 
Sean McAfee -- etzwane at schwag.org