Assign a ticket a specific number?

[yoh...@gmail.com]

Hi all,

I am migrating some information we have into a fresh trac. I know
it's A) a bad idea and B)at best, a pain, if not impractical, and C) a
bad idea :D

but, it is possible to create tickets with a specific number, or to go
back and modify the ticket db to give specific numbers to individual
tickets. (i.e., migrating tasklist item #130 into a trac ticket,
ideally want the ticket to be #130) It's a crutch to easy the
transition from the highly productive combination of word documents,
spreadsheets, and sticky notes a project currently has......

If this is easy, maybe I'll do it..

[Chris Mulligan]

This is pretty easy, as long as you access the database directly and
aren't trying to change any links in wiki pages or anything. There are
two or three places you need to change if you're modifying a ticket.
If you're just making a new one all you need to do is specify the
correct ticket number as the ID when you insert into the ticket table.

You could write a fairly simple python script to insert the tickets
based off a CSV, with hard coded ticket numbers.

[yoh...@gmail.com]

On Jun 24, 9:33 am, "Chris Mulligan" <chris.mulli...@gmail.com> wrote:
> This is pretty easy, as long as you access the database directly and
> aren't trying to change any links in wiki pages or anything. There are
> two or three places you need to change if you're modifying a ticket.
> If you're just making a new one all you need to do is specify the
> correct ticket number as the ID when you insert into the ticket table.
>
> You could write a fairly simple python script to insert the tickets
> based off a CSV, with hard coded ticket numbers.
>

That is pretty much exactly what i think I should do. In this case, I
actually COULD start my insertion at a sequential point, our list
happens to be numbered form 1-N, in order, and also has no gaps, so,
technically I don't think I even need to force ticket numbers.

THAT said, any pointers? I am lazy, and am sure someone has done
this(this is why I migrated to python....the efficiency makes up for
my general laziness)

[Chris Mulligan]

I used the little wrapper I wrote around Trac that I used in my
tracmerge script (the code of which is also online, but without
documentation). You'll need ptrac.py, but all it does is implement a
database insert command for you.

Check out http://trac-hacks.org/browser/tracmergescript/yoheeb

[yoh...@gmail.com]

On Jun 24, 11:35 am, "Chris Mulligan" <chris.mulli...@gmail.com>
wrote:

> I used the little wrapper I wrote around Trac that I used in my
> tracmerge script (the code of which is also online, but without
> documentation). You'll need ptrac.py, but all it does is implement a
> database insert command for you.
>
> Check outhttp://trac-hacks.org/browser/tracmergescript/yoheeb
>

awesome, I was in process of writing something atm so I could dump my
tickets database and figure out the field order (I wasn't sure how
trac merged the ticket_custom table in exactly. As it turns out, my
sql skills have bit rot and I was getting frustrated (I could NOT dump
the field names, I just dumped a ticket and mapped the entries to the
fields on a scrap of paper)

Thanks! I now have to go play with it so I can learn from it. My
next endeavor, will possibly, to try and attach comments/change
status, as some of these in "the list format" are closed with
resolution comments. That said, for this exercise, just getting the
numbers to match, then going in and editing the information in trac
is sufficient as the list is rather small, and the other members need
a "intro" to trac exercise anyway :D

Man, this group of users rock. I just hope I can contribute as much
as I have taken from in the near future here!

[Chris Mulligan]

If it's not clear, it will take a list of dictionaries for ticket
changes. The dictionaries look like this:
'ticket_change': [{'author': u'jamie',
'field': u'component',
'newvalue': u'something',
'oldvalue': u'general',
'time': 1131496921},
{'author': u'jamie',
'field': u'status',
'newvalue': u'assigned',
'oldvalue': u'new',
'time': 1131591197},
{'author': u'chris',
'field': u'status',
'newvalue': u'closed',
'oldvalue': u'assigned',
'time': 1135038571},
{'author': u'chris',
'field': u'resolution',
'newvalue': u'invalid',
'oldvalue': u'',
'time': 1135038571},
{'author': u'chris',
'field': u'comment',
'newvalue': u"Doesn't matter anymore...",
'oldvalue': u'',
'time': 1135038571}],

[Jennifer A. Drummond]

On Tue, Jun 24, 2008 at 11:57:27AM -0700, yoh...@gmail.com wrote:
> Man, this group of users rock. I just hope I can contribute as much
> as I have taken from in the near future here!

+1!

=-=-> Jenn Drummond // je...@rice.edu

[yoh...@gmail.com]

> =-=-> Jenn Drummond // j...@rice.edu

Wow, cool. OK, I do have one question. The input csv file, the
sample you had. the first row and the list of fields:
id,cc,changetime,component,description,keywords,milestone,owner,priority,reporter,resolution,severity,status,summary,time,type,version

what I think i am seeing in ptrac is that, I can modify this list (or
in my case, add to it) custom fields, as it reads the first row (well,
from the CSV module) and maps the column headings to the ticket
fields, but I am not 100%. so, if i have a custom field, say
"custom_field", I could insert it into the appropriate place, and it
would handle in automagically (tm) ? anyway, i have a local test trac
I am going to play with, so I will know shortly anyway..

[Chris Mulligan]

Nope, sadly it does not handle custom fields. Those are the columns in
the ticket table in the database (and the values are hard coded, so
they need to be exactly that), and it only works with those. You need
to have that exact set (plus the attachment and ticket_change lists
that I add in yoheeb.py), no more columns and no less. If you look at
how ptrac handles Project in the addTicket function it should be
possible to add them yourself though.

And yes, don't play with this on your live database :)