Failing to Migrate from Mantis

Added by Alan Chandler about 12 years ago

I have just installed a fresh version of Redmine from the stable download (ie 1.3.2) on a Debian Squeeze system running Apache. This contains Ruby 1.8.6 and Rails 2.3.5. I also installed gems (1.3.7) and rake (0.8,7) from the standard distribution.

For the migration only, I installed libmysql-ruby (2.8.2), as my main configuration has been set to run a sqlite3 database.

I followed installation instructions both from this web site getting as far as successfully completing

RAILS_ENV=production rake redmine:load_default_data

And the successfully checking with

ruby script/server webrick -e production

Before going any further I tried to migrate from an existing Mantis Solution I have set up

rake redmine:migrate_from_mantis RAILS_ENV="production"

and after entering the database credentials for my Mantis installation, I got the following

Migrating users......
rake aborted!
SQLite3::SQLException: columns project_id, tracker_id are not unique: INSERT INTO "projects_trackers" ("project_id", "tracker_id") VALUES (1, 1)

Before trying this, I also tried with a fresh installation installing the mantis2redmine plugin, but when I tried to use it, it just died on me, so had no idea what was happening. I completely blew that installation away and started again.

I am brand new to Ruby/Rails and Redmine, so I don't really know what I am doing - I am trying to set up an evaluation to see whether I should migrate from Mantis, but I seem to have fallen at the first hurdle.

Can someone tell me where I am going wrong, and how to complete a migration.


Replies (4)

RE: Failing to Migrate from Mantis - Added by Alan Chandler about 12 years ago

I am starting to look at this to try and figure out for myself what is going wrong, but I am stuck

Looking carefully at the output produced so far it says "Migrating Users" followed by 6 dots. This matches what I have found in my sqlite database. Namely there are now 7 users, the original admin user and the 6 from my Mantis database.

But the code then seems to output something else which doesn't appear.

      print "Migrating users" 
      User.delete_all "login <> 'admin'" 
      users_map = {}
      users_migrated = 0
      MantisUser.find(:all).each do |user|
        u = :firstname => encode(user.firstname), 
                     :lastname => encode(user.lastname),
                     :mail =>,
                     :last_login_on => user.last_visit
        u.login = user.username
        u.password = 'mantis'
        u.status = User::STATUS_LOCKED if user.enabled != 1
        u.admin = true if user.access_level == 90
        next unless!
        users_migrated += 1
        users_map[] =
        print '.'

      # Projects
      print "Migrating projects" 

namely "Migrating projects" Which as you can see from my dump of the problem above doesn't happen

So why - does Ruby/Rails buffer output, and its not flushed on the error? It certainly looks like the error occurs in Migrating the first project.

However when I look at the database there is already 1 project in there and if I look at table projects_trackers it already has 3 entries


Which I am presuming is a result of the following lines in the code

        next unless
        projects_map[] =
        p.enabled_module_names = ['issue_tracking', 'news', 'wiki']
        p.trackers << TRACKER_BUG
        p.trackers << TRACKER_FEATURE
        print '.'

However again I am puzzled - I think p.trackers << TRACKER_BUG creates the 1,1 entry and the p.trackers << TRACKER_FEATURE creates the 1,2 entry, but where does the 1,3 entry come from (and again I assume some output is buffered because '.' hasn't yet come).

The next piece of the code seems to create entries in what I assume is the members table. THIS TABLE IS EMPTY in my database after the crash, so I am assuming we didn't get that far.

        # Project members
        project.members.each do |member|
          m = :user => User.find_by_id(users_map[member.user_id]),
                           :roles => [ROLE_MAPPING[member.access_level] || DEFAULT_ROLE]
          m.project = p


Am I correct?

RE: Failing to Migrate from Mantis - Added by Alan Chandler about 12 years ago

I think I am getting there, having now discovered the --trace option.

The exception is created on this line

        p.trackers << TRACKER_BUG

(line 274 in the migrate_from_mantis.rake file in lib/tasks/)

which is part of this little run

        next unless
        projects_map[] =
        p.enabled_module_names = ['issue_tracking', 'news', 'wiki']
        p.trackers << TRACKER_BUG

As I said, I don't fully understand how rails/ruby works - and perhaps more particularly how ActiveRecord::Base works but as far as I can workout returns false when it fails validation.

Looking through the app/models/project.rb file I came across

  validates_associated :repository, :wiki

at line 74. Since the wiki link has not yet been set on the record then it fails validation. Am I correct? (and if I am then why bother with the next unless ?)

Finally at line 102

    if !initialized.key?('trackers') && !initialized.key?('tracker_ids')
      self.trackers = Tracker.all

Seems to me to say if when I initially do the

        p = :name => encode(, 
                        :description => encode(project.description)

at line 268 of the migrate script, that if I haven't set the key 'trackers' then I will automatically create all the possible trackers that there are.

If all my postulation is correct, then what is happening is that I create a new "projects" record and for that record I then create all possible records in "projects_trackers" table and then try and create a new one with the p.trackers << TRACKER_BUG statement and I therefore fall over with an unique index exception.

There are also two other problems I have come across.
  1. The project I migrated is set private, yet the migrated project is public.
  2. The "identifier" column of the projects table seems to have been set to the later characters of the project name rather than the first - not sure if this matters but it seems strange

Now the question becomes how do I fix it.

I presume that we have to leave app/models/project.rb as is. Therefore
  • We need to create the two trackers TRACKER_BUG and TRACKER_FEATURE as part of the new statement
  • I wonder if the next unless is trying to validate the names called in from Mantis for length and or uniqueness (although I can't see how) and therefore wonder if it can be removed

I'll try and teach myself some more ruby to have a go, although any help from more experienced users would be more welcome.

RE: Failing to Migrate from Mantis - Added by Alan Chandler about 12 years ago

I reported this as an issue #10501, and have offered a patch to fix it in that issue.

I now have another problem, further down the project migration code, with a failure to convert dates of versions. (I think Mantis is using an integer to hold seconds since 1970, not sure what redmine wants).

The code in question is

        # Project versions
        project.versions.each do |version|
          v = :name => encode(version.version),
                          :description => encode(version.description),
                          :effective_date => (version.date_order ? version.date_order.to_date : nil)
          v.project = p

It appears version.date_order.to_date doesn't exist according to the error message I get

I've reported this problem as #10504

RE: Failing to Migrate from Mantis - Added by Alan Chandler about 12 years ago

I eventually solved this with the patch in issue #10532

Does anyone here have any better way of getting support. No one has replied to this forum post, and its already on the second page and therefore would have been forgotten for ever. No one responded or even acknowledged any of the issues I raised in the issue list. A big piece of this application seems to be full of bugs that nobody cared about!.

As an outsider it makes me very nervous that I am going to be depending on it.

Or am I just looking in the wrong place?