Defect #16302
closed
Custom Fields settings broken when removing a plugin
Added by Darth Vader about 10 years ago.
Updated almost 10 years ago.
Description
In the new custom fields implementation, if a plugin has its own type of custom field and a custom field was created, the custom field settings page fails to load:
Completed 500 Internal Server Error in 123.0ms
ActiveRecord::SubclassNotFound (The single-table inheritance mechanism failed to locate the subclass: 'DmsfFileRevisionCustomField'. This error is raised because the column 'type' is reserved for storing the class in case of inheritance. Please rename this column if you didn't intend it to be used for storing the inheritance class or overwrite CustomField.inheritance_column to use another column for that information.):
app/controllers/custom_fields_controller.rb:29:in `block (2 levels) in index'
app/controllers/custom_fields_controller.rb:27:in `index'
- Status changed from New to Closed
- Resolution set to Wont fix
You have to delete these custom fields with a custom subclass before removing your plugin. Now that you removed your plugin, the class definition for this custom field can not be found and an error is raised.
I know how to fix it. But usually, removing a plugin only entails removing it from the plugins folder and not having to remember to remove some fields from the database. If it were more complicated than just removing the folder, there would be a plugin uninstaller (maybe a "remove" plugin button on the plugin administration page).
I would expect the behavior of the main software to simply ignore custom field classes that don't have a definition (just like it did for tabs added in the previous version of the custom field implementation).
Darth Vader wrote:
I know how to fix it. But usually, removing a plugin only entails removing it from the plugins folder and not having to remember to remove some fields from the database. If it were more complicated than just removing the folder, there would be a plugin uninstaller (maybe a "remove" plugin button on the plugin administration page).
I would expect the behavior of the main software to simply ignore custom field classes that don't have a definition (just like it did for tabs added in the previous version of the custom field implementation).
FWIW, I totally agree with Darth here. Redmine is an amazing product, but it seems like it shouldn't make the plugin infrastructure (one of its greatest strengths) more difficult for end users to manage.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by