Project

General

Profile

Actions

Defect #16302

closed

Custom Fields settings broken when removing a plugin

Added by Darth Vader about 10 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Custom fields
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix
Affected version:

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'

Actions #1

Updated by Jean-Philippe Lang about 10 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.

Actions #2

Updated by Darth Vader about 10 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).

Actions #3

Updated by Bob Pack over 9 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.

Actions

Also available in: Atom PDF