View Issue Details

IDProjectCategoryView StatusLast Update
0020512mantisbtcustom fieldspublic2019-06-16 13:39
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.3.0-rc.1 
Summary0020512: Renaming custom fields breaks column configuration

Let's assume the user has custom field xyz and they have added it to some column configuration (e.g view issues page) using custom_xyz. If the user later changes the name to xyz2, all the configuration whether they global, project specific, or user specific need to be updated to reflect the new name.

This bug probably applied forever.

Tagsmantishub, schema


related to 0020305 new Create localization framework for user created objects 




2016-01-13 16:31

developer   ~0052306

internally referring custom fields by name is weak as seen here.
having already an unique id, this id should be used within the application, and only use the name for displaying purpose.
I'd like to see this done!

and somewhat related: store enumerated values in a more structured way, instead of pipe-separated strings.



2016-01-15 04:03

manager   ~0052316

+1 for serializing custom field ids. However, we may want to consider savings ids + names if we want to keep readability within Configuration Report page.



2016-01-15 05:29

developer   ~0052318

regarding custom fields ids and user preferences:
plugin provided columns have to be stored too as part of the columns configuration. Those don't have an integer id, but a string name. That name is less prone to be changed, though.



2016-01-19 04:10

developer   ~0052330

more thoughts:
field info in filters are also stored by name, including custom fields names as "custom_xxxx"

Then, an approach may be to separate CF "technical name" from "display name".
Technical name should be more strict as simple ascii/no_spaces/etc.
Hopefully the use case for changing technical name is very less frequent than changing display name.



2016-01-19 10:58

developer   ~0052331

I think we should only care about "technical name" when defining the custom field, and

  1. no longer allow characters that are not valid for php variable names (i.e. [A-Za-z1-9_] - no more spaces and other fancy stuff)
  2. possibly forbid changing this "technical name" once the CF has been defined

The "Display name" part should be handled via localization, as described in



2016-01-19 11:12

developer   ~0052332

1, 2, right

The "Display name" part should be handled via localization ...

The problem with that localization:

  • it's a static lang file, not manageable from inside the application.
  • and that CF names can collide with standard application strings (i wrote about that in some issue report, cant find right now)

a more generic related feature, on this issue: 0020305



2016-01-26 00:41

manager   ~0052388

+1 for @dregad's rules. I have always been recommending having custom fields follow the rules he specified. However, it wasn't enforced and often people needed them to look different and they didn't care about localization or necessarily new about it. They found a name and typed in what they need in it.

The question remaining is how do we go from current model to the new model:

  1. Create an internal name field in the schema.
  2. Calculate the name of the internal field from the current display name.
  3. Upgrade existing column configuration to refer to internal name instead of display name.
  4. Upgrade existing filter configuration to refer to internal name instead of display name.

As for the localization issue, it is a separate topic that we can discuss at 0020305.



2016-01-26 04:03

developer   ~0052391

The question remaining is how do we go from current model to the new model:
I'd say, wait if the localization solution gets into something.
Then, migrate current unsafe names into localized names, and downgrade current names to technical ones according to rules.
(still havent though about the evil details, though)



2016-05-27 09:39

developer   ~0053225

Last edited: 2016-05-27 11:40

View 2 revisions

The question remaining is how do we go from current model to the new model:

I think this would be less impact:

  1. Create a new "display_name" in schema
  2. Copy current "name" to "display name" as is
  3. Enforce "name" syntax for new fields and updates (but allow present names to be kept if not modified, for compatibility)
    and probably:
  4. Add warning of the implications of changing the "name" value, as it breaks columns configurations, custom functions, history consistency, etc

Regarding localization:
call to lang_get_defaulted with "name" as search string, and "display_name" as default
This way, if the names are defined in the language files, it would override the display name (keeping current behaviour). If not defined in language files, the "display name" is used for presentation

"Display name" as a custom-field property cannot be localized right now (from within the application), but this is consistent with other user defined objects, eg: project names.

Issue History

Date Modified Username Field Change
2016-01-13 11:10 vboctor New Issue
2016-01-13 11:10 vboctor Tag Attached: mantishub
2016-01-13 16:31 cproensa Note Added: 0052306
2016-01-15 04:03 vboctor Note Added: 0052316
2016-01-15 05:29 cproensa Note Added: 0052318
2016-01-19 04:10 cproensa Note Added: 0052330
2016-01-19 10:58 dregad Note Added: 0052331
2016-01-19 11:12 cproensa Note Added: 0052332
2016-01-26 00:41 vboctor Note Added: 0052388
2016-01-26 01:36 vboctor Relationship added related to 0020305
2016-01-26 04:03 cproensa Note Added: 0052391
2016-05-27 09:39 cproensa Note Added: 0053225
2016-05-27 11:40 cproensa Note Edited: 0053225 View Revisions
2019-06-16 13:39 atrol Tag Attached: schema