View Issue Details

IDProjectCategoryView StatusLast Update
0004451mantisbtcustom fieldspublic2007-07-11 09:14
ReporterNarcissus Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
Summary0004451: Populating options through a function call
Description

It would be handy to have the option of custom fields options being populated through a function call, instead of preset values.

Additional Information

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.

TagsNo tags attached.

Relationships

related to 0005180 closedvboctor Support custom fields with dynamic possible values 
child of 0004181 closed Features in Mantis 1.1 release 

Activities

jlatour

jlatour

2004-08-31 23:58

reporter   ~0007348

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?

Narcissus

Narcissus

2004-09-01 01:28

reporter   ~0007351

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?

vboctor

vboctor

2004-09-01 06:21

manager   ~0007352

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.

jlatour

jlatour

2004-09-01 17:40

reporter   ~0007378

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).

Narcissus

Narcissus

2004-09-15 19:31

reporter   ~0007615

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.

gtomlin

gtomlin

2004-12-07 16:43

reporter   ~0008531

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.

vboctor

vboctor

2005-01-29 08:42

manager   ~0009140

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

Issue History

Date Modified Username Field Change
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