Ticket #465 (closed Defect: fixed)

Opened 8 years ago

Last modified 8 years ago

The result of a plugin Installation seems to vary by the current state of the DB

Reported by: Malte Owned by: jri
Priority: Major Milestone:
Component: DeepaMehta Standard Distribution Version: 4.1
Keywords: Cc: dgf
Complexity: 3 Area:
Module:

Description

When installing a plugin during a "cold start", as part of the initial DeepaMehta initialization (which is most often the case during development and after a deepamehta-db reset) everything works as expected.

When installing a plugin into an existing, already initialized DeepaMehta installation, the outcome of the installed plugin differs in the following ways from the expected outcome:

  • The "Plugin Type" set to "show_in_create_menu" does not show up
  • The "View Configuration" and the "Plugin Types" cannot be edited by "admin"

Change History

comment:1 Changed 8 years ago by jri

  • Status changed from new to accepted
  • Cc dgf added

comment:2 Changed 8 years ago by jri

Yes, I can reproduce the problem you described with a 4.1 binary distribution and your Twitter plugin.

Indeed, when the plugin is installed subsequently on an existing DM installation the plugin's types do not appear in the Create menu. This is due to missing Access Control information. This in turn is due to the type instruction mechanism (IntroduceTopicTypeListener?) as utilized by the Access Control plugin. The finding is: the plugin activation order matters.

To solve the problem the installation of the Twitter plugin must wait for the Access Control plugin to be ready. Otherwise your plugin's types get no Access Control information assigned.
To let your plugin wait for the Access Control plugin add de.deepamehta.accesscontrol to your importModels plugin property:

importModels=de.deepamehta.webclient, de.deepamehta.workspaces, de.deepamehta.accesscontrol

(BTW: its best to have NO spaces arround the equals sign. Furthermore, when your plugin provides a server-side plugin main class you're not required to set the pluginPackage plugin property.)

You've already described a similar issue and workaround (related to workspace assignments) on your https://trac.deepamehta.de/wiki/Malted/PluginDevelopmentNotes
page. You could add this ticket's issue there.

Bottom line: when your plugin provides its own types you should add de.deepamehta.accesscontrol to your importModels plugin property. Otherwise your types could lack access control information. As a consequence types supposed to appear in the Create menu will not do so. This is particularly an issue when the plugin is installed subsequently on an existing DM installation.

Thank you very much, Malte, for reporting this crucial issue!

Last edited 8 years ago by jri (previous) (diff)

comment:3 Changed 8 years ago by Malte

  • Status changed from accepted to closed
  • Resolution set to fixed

Thank you for investigating this stuff so quickly. I just re-released my two plugins after adjusting the importModels-Property, this indeed solved the ACL-Issue I described above and I will see how I can integrate this ticket into my personal development notes.

Cheers!

Note: See TracTickets for help on using tickets.