View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004451||mantisbt||custom fields||public||2004-08-31 23:49||2007-07-11 09:14|
|Summary||0004451: Populating options through a function call|
It would be handy to have the option of custom fields options being populated through a function call, instead of preset values.
By doing this, issues where people would like custom fields such as 'users' (0003790), 'counter' (0003792) and 'version' (0003791) are all made much easier, as the user just needs to create a function that returns that list, which can change dynamically.
|Tags||No tags attached.|
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:
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:
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.
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.
|2004-08-31 23:49||Narcissus||New Issue|
|2004-08-31 23:55||jlatour||Status||new => acknowledged|
|2004-08-31 23:56||jlatour||Relationship added||child of 0004297|
|2004-08-31 23:58||jlatour||Note Added: 0007348|
|2004-09-01 01:28||Narcissus||Note Added: 0007351|
|2004-09-01 06:21||vboctor||Note Added: 0007352|
|2004-09-01 17:40||jlatour||Note Added: 0007378|
|2004-09-15 19:31||Narcissus||Note Added: 0007615|
|2004-10-05 18:27||vboctor||Relationship deleted||parent of 0004297|
|2004-12-07 16:43||gtomlin||Note Added: 0008531|
|2004-12-07 17:03||jlatour||Relationship added||child of 0004181|
|2005-01-29 08:41||vboctor||Relationship added||related to 0005180|
|2005-01-29 08:42||vboctor||Note Added: 0009140|