Project

General

Profile

Actions

Refactor #12747

closed

Provide some kind of central store or consistent way to manage dynamically registered objects from plugins

Added by Stephen Benjamin over 8 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Plugin integration
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Currently, there are number of things you can register for plugins - compute resources, dashboard widgets, etc.

Dashboard widgets stores plugin registered widgets like this: https://github.com/theforeman/foreman/blob/develop/app/services/dashboard/manager.rb#L3
Compute resource store plugin registered resources like this: https://github.com/theforeman/foreman/blob/develop/app/models/compute_resource.rb#L13

It's all very inconsistent. We should standardize on a single way, perhaps even having some kind of central store to put this kind of data.

The problem when we re-invent this for every new dynamically registered thing, we introduce potential problems, like #12746.


Related issues 4 (0 open4 closed)

Related to Foreman - Bug #12746: Compute resources can disappear in a development instanceClosedDominic Cleal12/08/2015Actions
Related to Foreman - Bug #14300: after removing dashboard widgets none are listed to add backDuplicate03/21/2016Actions
Related to Foreman - Bug #14742: Template kind friendly names from plugins can be reloaded and lost in developmentClosedDominic Cleal04/21/2016Actions
Related to Foreman - Bug #14969: Custom status is not reloaded correctlyClosedMarek Hulán05/09/2016Actions
Actions #1

Updated by Stephen Benjamin over 8 years ago

  • Related to Bug #12746: Compute resources can disappear in a development instance added
Actions #2

Updated by Dominic Cleal over 8 years ago

The plugin classes should be stable in the development environment, so using an approach like we just did in #12624 (merging them on use) may be best: https://github.com/theforeman/foreman/commit/51685ba80898aa6835a2396c14c02d8af52aec13#diff-2d53894341fd1cf84a823e3bd0855495R552

Actions #3

Updated by Dominic Cleal about 8 years ago

  • Related to Bug #14300: after removing dashboard widgets none are listed to add back added
Actions #4

Updated by Dominic Cleal almost 8 years ago

  • Related to Bug #14742: Template kind friendly names from plugins can be reloaded and lost in development added
Actions #5

Updated by Dominic Cleal almost 8 years ago

  • Related to Bug #14969: Custom status is not reloaded correctly added
Actions #6

Updated by Dominic Cleal almost 7 years ago

  • Status changed from New to Resolved

Tentatively setting as resolved, as the app/registries/ directory added in #19317 should provide a standard location which is immune to autoloading in the development environment. It also provides a small amount of documentation about how best to implement registry-type objects.

However, per comment 2, the plugin classes are in stable in a development environment (they use this directory) and so new registries/stores/dynamically registered objects should not be added to app/registries/ unless absolutely necessary. They should return a built in list of entries, then append the list from plugins at runtime.

Actions

Also available in: Atom PDF