Feature #10418


Issue mapping (external issues and data import/export)

Added by Michael Utech about 12 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


The related (closed) ticket #3647 imho addresses an important feature. Merging projects which have been managed in different repositories is something that happens (just happened to me after one week of using redmine).

My proposal to solve this problem and add another quite sexy feature would be to add an issue mapping table. This table maps the issue ID used by the current redmine instance to a source or external ID and a source system ID referencing a specification of the source system.

  • For local issues, the source ID is NULL.
  • For imported issues (originating from another redmine or alien system), the source contains their ID.
The source system specification defines the following information:
  • Repository; if defined, this is used to link issues belonging to this system. If the repository is not defined, the setting of the project is used
  • Repository/Issue link: same as for projects, defines how to parse issues. If not defined, setting from project is used. Setting is applied to system source repository or project repository.
  • Source system connector. If defined, issues can be contineously be imported/synchronized using some defined interface. If not defined, source is considered to be dead (migrated to local system)

This would even then work, if one existing redmine project is using multiple repositories (source ID = ID, 2nd repository comes from source system setting)

With that implementation in place, importing a project that was exported from another system shouldn't really be too tough. If we have an XML dump, the mapping can be done with a simple XSLT.

Granted, its a bit of work (2 weeks i would estimate), but it would open doors to a lot of quite interesting and important features.

Definitely not anywhere close to 'impossible' or even 'hard', is it?

No data to display


Also available in: Atom PDF