Defect #16302
closedCustom Fields settings broken when removing a plugin
0%
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'
Updated by Jean-Philippe Lang almost 11 years ago
- 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.
Updated by Darth Vader almost 11 years ago
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).
Updated by Bob Pack over 10 years ago
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.