Validating and loading the bundle¶
Loading is done by Specivo, not by this tool. It needs Specivo 0.11.0 or later. The import command is the same for every migration tool; this page shows what matters for an RT bundle. The full guide is Importing from another tracker in the Specivo user guide.
Back up first
Back up your Specivo database and data directory before a real import.
Copy the bundle to the Specivo server, in a folder that is writable by the app (an import keeps a small links file next to the bundle). Then run, in this order:
# 1. Check the bundle. Reads only the bundle: no database is touched.
python -m specivo.cli.import_data --source bundle --path rt-export --validate
# 2. Rehearse. The whole import runs in a transaction that is always rolled back.
python -m specivo.cli.import_data --source bundle --path rt-export --dry-run
# 3. Import.
python -m specivo.cli.import_data --source bundle --path rt-export
With Docker, prefix each command with docker compose exec api and use the path inside the container.
Attachments kept apart¶
A bundle written with --files-path has no files/ folder. Copy the files folder along and name it
on every command:
rsync -a --partial rt-export rt-files specivo-host:/srv/import/
python -m specivo.cli.import_data --source bundle --path /srv/import/rt-export \
--files-path /srv/import/rt-files --validate
Several bundles of one RT¶
Bundles of one RT installation (one per queue, or a later export before the switch) share the
--instance they were written with. Load the first as above, and every later one with
--continue-import:
Records already imported are skipped; links and references between the bundles are made once both
ends are in Specivo, whichever bundle came first. Keep the links file Specivo writes next to the
bundles (specivo-links.rt.<instance>.sqlite) and give every load the same one.
Options worth knowing for RT¶
| Specivo option | When |
|---|---|
--import-admins |
Make RT's superusers Specivo administrators. Without it they are imported as ordinary accounts and listed in the report. |
--merge-duplicate-statuses |
Specivo already has statuses named like RT's (new, open, resolved): use those instead of adding a second one of each name. |
--project-key-map support=SUP |
Choose a project's key instead of the one derived from the queue's identifier. |
--project <refs> |
Load only some projects of the bundle (by the queue's RT id). |
Reading the report¶
The import report lists what it created, what it skipped, and the bundle's not_carried_over: what
RT had that the bundle could not hold (see What is not carried over). It also
lists every user who is not active (RT's unprivileged and disabled users are locked), every account
RT marked as an administrator, and every account without an email address.
After the import:
- give the roles Manager, Developer and Reporter their permissions: Specivo creates them without any, and each role's import data names the RT rights that led to it;
- check the projects of article classes (Articles: ...): a class applied to several queues has a project of its own;
- requestors who should sign in (a customer portal) need their accounts unlocked, or an export with
--activate-unprivileged. - check the group RT privileged users, if the bundle has one: it stands for RT's Privileged group, with every privileged user carried as a member;
- check what RT's Everyone group could do (below).
RT's Everyone group and public projects¶
Every imported project is private: only its members (directly or through a group) can open it.
The report's not_carried_over names the rights RT's Everyone group held, on every queue and queue
by queue, and each project keeps its list in extra (rt_everyone_rights). Everyone in RT includes
requestors and anyone who mailed a ticket in, so a right such as ShowTicket there seldom means the
queue was meant to be open to all (see What is not carried over).
If a project really should be readable by everyone with an account, make it public after the
import. A public project shows its content to every signed-in user who is not a member, with the
permissions of the built-in Non member role: by default it may view issues, and an
administrator changes that under Administration → Roles. Specivo's web pages show a project's
visibility but have no switch for it; an administrator, or a user whose role in the project has the
manage_project permission, changes it through the REST API:
curl -X PATCH https://your-specivo-host/api/v1/projects/SUPPORT/ \
-H "Authorization: Bearer spv_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{"is_public": true}'
{"is_public": false} makes it private again. Reading without an account is separate: an instance
administrator opts a public project in under its Settings and turns on anonymous access for the
whole instance.