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
Description

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

Relationships

related to 0020305 new Create localization framework for user created objects 

Activities

cproensa

cproensa

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.

vboctor

vboctor

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.

cproensa

cproensa

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.

cproensa

cproensa

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.

dregad

dregad

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 http://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.customize.customfields.localize

cproensa

cproensa

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

vboctor

vboctor

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.

cproensa

cproensa

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)

cproensa

cproensa

2016-05-27 09:39

developer   ~0053225

Last edited: 2016-05-27 11:40

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.