Hi Edward,

this seems to be an issue with the meetings plugin. Can you provide us your Gemfile.plugins file so we can look into the issue, please?
It might be that the plugins need an update too so that they match with the OpenProject core again.

cheers,
tessi

I’ve attached my Gemfile.plugins file.

Thanks.

Hello Edward,

as you have been writing you try to migrate from an pre stable 3.0 release and in an early version of 3.0 it was not possible to run the migrations directly from the plugins bundler path. The “old” way was to copy the plugin migrations from the plugin path to “db/migrate” path of the OpenProject core. Now you don’t have to take care about the plugin migrations because they will be used automatically.

Can you please check if the “db/migrate” folder of the OpenProject core contains any migrations with ‘meeting’ in the filename?

Best
Ratzi

It looks like what you said is my situation as the following files were found in the db/migrate path:
20130926130758_create_meetings.openproject_meeting.rb
20130926130759_create_meeting_contents.openproject_meeting.rb
20130926130760_create_meeting_content_versions.openproject_meeting.rb
20130926130761_create_meeting_participants.openproject_meeting.rb
20130926130762_add_lock_to_meeting_content.openproject_meeting.rb
20130926130763_create_initial_meeting_journals.openproject_meeting.rb
20130926130764_merge_meeting_content_versions_with_journals.openproject_meeting.rb
20130926130765_remove_meeting_role_id_from_meeting_participants.openproject_meeting.rb
20130926131309_create_meeting_journals.openproject_meeting.rb
20130926131310_legacy_meeting_journal_data.openproject_meeting.rb
20130926131311_legacy_meeting_agenda_journal_data.openproject_meeting.rb
20130926131312_legacy_meeting_minutes_journal_data.openproject_meeting.rb

All migrations start with a timestamp (e.g. 20130924114042_legacy_meeting_minutes_journal_data.rb) and this timestamp is used as the indicator whether the migration has already been executed or not. Now the old copied migrations have a different timestamp than the “new” migrations located in the plugins path but they have the same content. And if you re run the same migration (same content) with a different timestamp it will break because the tables already exists.

You can do the following:

Add the following entries to the ‘schema_migrations’ table in the database to prevent re-execution for the migrations:

20111605171865
20130731151542
20130822113942
20130924091342
20130924093842
20130924114042

Than delete the files from your list above, located in the ‘db/migrate’ folder from OpenProject core.
Run RAILS_ENV=production bundle exec rake db:migrate again and it should work.

As I can see in your Gemfile.plugins you have some other plugins installed and if you added these plugins in the same eraly state like you added the meetings plugin you will run in the same problems for each plugin. You can solve the problems the same way.

Add the new timestamps of all already performed migrations to the ‘schema_migrations’ table in the database. You can find this timestamps by different ways

Go to the github page of the plugin (make sure you view the stable-branch) and browse to the ‘db/migrate’ folder

OR

Go to the OpenProject core folder and run ls `bundle show PLUGIN_NAME`/db/migrate

Than add the timestamps to ‘schema_migrations’ table in the database for each plugin ecxept for openproject-plugins and reporting_engine because they have no migrations. Be aware that you only add the timestamp of migrations which you already copied. Compare the filenames (without the timestamp) of the migrations from the ‘db/migrate’ folder of the plugin and ‘db/migrate’ folder from the OpenProject core (old copied migrations).

If you added all needed timestamps to the database remove all plugin migrations from the OpenProject core ‘db/migrate’ folder than run the migrations again.

Best
Ratzi