trac-admin - ticket export import

[steverweber@…]

We are attempting to use trac on a large scale at an university. We have multiple projects and one main project where most tickets enter from.

Everything is working out well but for one exception. If a ticket comes in on the main trac instance.. lets call it [Support].. some times we need to 'move' this ticket to another project..

There is some trac hacks.. DatamoverPlugin and TicketmoverPlugin.. However these are largely out of date and don't work.

What I propose is this function be included in trac-admin as well as the API.

Like the wiki.. wiki export <page> [file]

Export wiki page to file or stdout

wiki import <page> [file]

Import wiki page from file or stdin

Have a simple… ticket export <id> [file]

Export ticket to file or stdin. Note attachments will be ignored and whatever else that is tricky to handle…

ticket import [file]

Import ticket as new id from file or stdin.

ticket append <id> [file]

Add more information to a ticket..

This will allow us to do something like… trac-admin /project/Support ticket export 1232 /tmp/1232 trac-admin /project/Webpage ticket import /tmp/1232 output created ticket: 321 trac-admin /project/Webpage ticket append 321 "Moved ticket from Support to Webpage"

Or create a simple module that uses API under the hood to do more or less the same thing.

The export, import, and append parser could be based off the email2trac plugin. And perhaps while at it merge email2trac into trac since its almost a requirement for issue tracking systems.

[Jeremy Metz <metz.jp@…>]

I think the ​TicketImportPlugin is a more up-to-date version of the old hacks you mentioned. It apparently (I haven't used it) works with csv and xls files.

[steverweber@…]

Interesting plugin but not to helpful for this use case.

It might be helpfull when importing a massive collection of old tickets over… but not good for our use case.

If i have a boring weekend Ill try and add what I feel is needed to trac-admin and perhaps clean up and integrate the email2trac_custom.py as a module.

Here is one that we been using… ​https://subtrac.sara.nl/oss/email2trac/attachment/ticket/296/email2trac_custom.py

its not to hard to setup… I was kinda surprised that I could not respond to the trac ticket i received from edweall.org. Perhaps trouble with spam?

[Remy Blank]

Preparing for 1.0.

[Ryan J Ollos <ryano@…>]

Related: a similar trac-admin ticket add feature was requested in #10049, and the ticket import / export functionality was also suggested in comment:7:ticket:10049.

[szybalski@…]

I would use this plugin. As long as trac is in same server and all of them are in lets say /home/trac/project1 /home/trac/project2

then ticket move plugin will recognize them. You give permission to who ever and they will have a new option "move ticket" and a pulldown list with project1, project2… the option will be right below fix or reassign.

​TicketMoverPlugin

[Peter Suter]

attachment:T10699_ticket_import_export.diff​ is a proof-of-concept for ticket export to and import from csv.

Ticket export to csv actually already exists twice as a feature in Trac:

• TicketModule.export_csv()​
• QueryModule.export_csv()​

I mostly modelled this patch after the permission import and export feature from #9336 though. But it may make sense to unify or align these more at some point.

Export:

• Exports all ticket properties.
• Each ticket is one row of csv.
• Only the current values are exported. No editing history or comments are exported.
• An optional query selects tickets to export.
• Example: trac-admin ticket export tickets.csv "status=new&milestone=milestone1"

Import:

• Imports the provided ticket properties.
• Except id, which is silently ignored if provided. Each imported ticket gets assigned the next available id instead.
• Again no history or comments, just one row of initial values per ticket.
• Datetime properties (and others?) are probably not yet parsed correctly.
• Example: trac-admin ticket import tickets.csv

(Also there's no append command.)

[Jun Omae]

That patch seems to be almost good. However, I don't think export and import commands always are executed on same machine, e.g. export on Windows and import on Linux. So that:

1. Encoding of the files should be utf-8.
2. Line separator of the files should be CRLF.
3. Format of timestamp in the files should be iso8601 with timezone offset and micro-seconds resolution.

Other suggestions:

• The import command:
  • Should use db transaction.
  • Should raise an exception with all of invalid fields. e.g. Invalid field names: foo, bar, baz.
  • Should skip time and changetime fields. Those fields are protected fields.
  • Should check existence of milestone, version, ticket type, etc… and raise an exception (or report warnings).
  • Should check existence of summary field and non-empty values in the file.

[Peter Suter]

Thanks for the review. All your suggestions sounds good to me.