Moving in from Blesta

For whoever is running the desk. One command, and it is safe to run more than once.

If your tickets are in Blesta’s Support Manager, the desk will read them straight out of Blesta’s own database, tickets, their replies, and the internal notes staff left on them. It does not go through Blesta’s API and does not need the module installed; it only needs to be able to reach the database and read it.

What comes across, and what does not

Tickets	subject, department, priority, status, dates, and the client they belong to
Replies	in order, client and staff alike
Internal notes	as notes, still hidden from clients
Clients	created as they are met, matched on their Blesta account
Staff	created as agents, with a random password nobody knows, they sign in by resetting it
Attachments	yes, if you bring the files across, see below

It is safe to re-run. Every imported ticket remembers which Blesta ticket it came from, and a second run skips anything already there. So an import can be done in stages, or repeated after a few more tickets have come in, without duplicating anything.

Try it first

Nothing is written, and it tells you what it found:

sixnix-deskctl blesta:import-tickets --dry-run \
  --host=BLESTA-DB-HOST --database=blesta --username=blesta

It asks for the password rather than taking it on the command line, which keeps it out of your shell history. Give --password= only if you are scripting it.

Add --files to the dry run too, and it looks on the disk for every attachment rather than counting rows, so the number it reports is the number that will actually arrive, and you find out about missing files before you commit to the import rather than after.

Attachments

The files are not in Blesta’s database; they are on its disk, under uploads/<company>/support_manager_files. So there is a step first: copy that directory to this machine. Blesta’s own server is left untouched, an import only ever reads.

rsync -az blesta-server:/path/to/blesta/uploads/ /tmp/blesta-uploads/

Then point the import at it, and it works the rest out from the company number:

sixnix-deskctl blesta:import-tickets --files=/tmp/blesta-uploads \
  --host=BLESTA-DB-HOST --database=blesta --username=blesta

Three things worth knowing:

• Files are copied, never moved. Nothing an import does can damage what it is reading.
• A row whose file was pruned years ago is skipped and counted, not fatal. That is the normal state of an old desk, and it is no reason to stop importing the other four thousand tickets.
• The brand’s rules about what may be attached do not apply. Those govern what people may send now; they should not retroactively reject your history.

Forgot --files on the first run? Run it again with them. The tickets are already there and are skipped, and the files are filled in behind them.

Departments

Blesta’s departments are matched to yours by name. Anything with no match lands in the department named by --department, which is “Support” unless you say otherwise, and you can pair the rest up by hand:

sixnix-deskctl blesta:import-tickets \
  --host=BLESTA-DB-HOST --database=blesta --username=blesta \
  --department=Support \
  --map="Presales:Sales" --map="Abuse:Support"

Got the mapping wrong and already imported? Fix the --map and add --remap, which also moves tickets imported earlier into their proper department.

When Blesta is on this same machine

This is where a container install differs, and it fails confusingly if you do not know:

• --socket cannot work. A MySQL socket is a file on the host, and nothing inside a container can see it. Use --host and --port.
• --host=127.0.0.1 means the container, not the machine. Use --host=host.docker.internal, which sixnix-deskctl arranges a route for.
• --files is a path on the host, which the container cannot see either. sixnix-deskctl mounts it, read only, and translates the path, so you give the path you can see and never think about the container’s.

sixnix-deskctl refuses both by name and says this, rather than letting you watch a connection time out.

Then

sixnix-deskctl blesta:import-tickets --host=… --database=blesta --username=blesta

Expect it to take a while on a large Support Manager; it shows a progress bar and finishes with a count of what it wrote and what it skipped. Afterwards, look at a handful of tickets, one long thread, one with internal notes, one from a client who had several, before you point anybody at the new desk.

Then go on to First run for the brand, the departments and mail.