I'd say we should just present the user with a drop-down list of defined functions though, and also limit the selection of functions to only functions defined for this purpose (in the logic as well as the interface).

Maybe also allow for an argument to be defined?

I absolutely agree that we need to be careful with this option. This is the situation that I was thinking of:

• have a 'custom_fields_functions' file (or somewhere specific to add functions)
• each function thats created should begin with a particular string (eg. custom_field_fill_functionX(), custom_field_fill_functionY() )
• present custom field admins with a dropdown, populated with all function names that begin with the magic string (eg. dropdown has 'functionX' and 'functionY' as options)
• when populating the custom field, take the selected string and prepend the magic string before calling the function

By prepending the magic string, we ensure that people aren't calling any functions that aren't intended to be used as field fillers.

Also an argument is a great idea: I was wondering whether it should be considered a requirement to at least accept a bug ID?

This feature was planned since Custom Fields were introduced, and "custom functions" added one step in this direction. I think we need to do the following:

Populating fields:

• Option 1: Add a custom function to populate all custom fields based on their name.
• Option 2: Add a set of custom functions, and refer to which one to be used as part of the custom field definition.

Renaming/Deleting:
When a "version", "user", "category", ...etc is renamed, we need to rename the value in custom fields associated with it. This will require adding hooks for "version_rename", "version_delete", ...etc. We should also add hooks for "*_add" for completeness and it will probably be useful in other areas.

To know more about how custom functions work, see core/custom_function_api.php. This is basically a technique where Mantis core team can provide a set of hooks with no or default code, which can then be overriden by Mantis administrators.

Parameters:

• We can pass the issue id to the function, where id = 0 means reporting, and any other id means some sort of updating for the issue with the specified id.

Please also see my comments in 0003791.

I think I prefer Option 2 (although you could of course opt to offer both), because then the system administrator (or we?) can simply provide a number of functions, and the Mantis administrators (who don't necessarily have programming knowledge) can simply select the function they want.

I also think we should the admins pass an argument that remains the same for this field (i.e. select the behaviour, so you can make the functions more generic).

Regarding renaming custom fields and changing already set data, this could be dealt with by storing an index instead of the value, couldn't it? All we would have to do is provide a checkbox along the lines of 'Change values in issues when I change this field' and this would mean that we just store the index instead.

When we show the fields, if the data in the custom field has changed, then automagically the data in the bug has changed, as the index just points to the new value.

I would find this feature very useful.

I have a need to capture a customer identifier and a customer contact identifier when an issue is reported, and want to ensure the data is not subject to random variations, so I would like to present an enumeration for each of these fields. However it is not practical to do this with the existing custom field enumerations, since there are hundreds of customers and thousands of contacts. With a custom function, I would be able to populate the enumeration from a table.

Most of the ideas in here are implemented as part of 0005180.