Hi

Unfortunately I only had an example for ticket_created, and I do not know
how things are supposed to be handled in ticket_changed, but hopefully
someone else will now let us know..

Regarding sqlite: sqlite does only handle one transaction at a time, so if
you need multiple simultaneous connections to the db you will be better of
with postgres. Performancewise I've been told that sqlite and postgres are
about the same, but with postgres you get better throughput since you don't
need to wait for locks..

Cheers / Erik

On Thu, Mar 6, 2008 at 11:46 AM, Daniel Abel <[EMAIL PROTECTED]> wrote:

>
> Hi!
>
> I am working a plugin which would help time-related ticket
> activities. The functionality I would like to have is to
>
> 1) e-mail notifications / warnings if a ticket spends too much time in
> a given state.
>
> 2) have automatic transitions, i.e. tickets get transfered from status
> A to status B after a given time.
>
> 3) show the dates/time involved in the features above on the ticket
> view pages, allow searching based on them, etc.
>
>
> My implementation plan is to create a plugin that implements
> ITicketChangeListener, and in ticket_changed() check whether the
> ticket entered one of the states which have a time-limit
> configured. If yes,
> 1) store the current time in a custom foo_state_entered_date field
> 2) set a callback by invoking 'at', which will run a small script
>
> The part where I got stuck is setting a field's value from
> ticket_changed(). Following erikand's suggestion (on #trac) I thought
> the following would work:
>
>    ticket[fieldname] = datetime.date.today().isoformat()
>    ticket.save_changes('auto-script',None)
>
> which would be simple, and it would store such automatic changes in
> the ticket's changelog. However, this throws an exception:
>
>
> Traceback (most recent call last):
>  File "$pkg/trac/web/main.py", line 398, in _dispatch_request
>    dispatcher.dispatch(req)
>  File "$pkg/trac/web/main.py", line 195, in dispatch
>    resp = chosen_handler.process_request(req)
>  File "$pkg/trac/ticket/web_ui.py", line 159, in process_request
>    return self._process_ticket_request(req)
>  File "$pkg/trac/ticket/web_ui.py", line 459, in
> _process_ticket_request
>    self._do_save(req, ticket, action)
>  File "$pkg/trac/ticket/web_ui.py", line 943, in _do_save
>    cnum=internal_cnum):
>  File "$pkg/trac/ticket/model.py", line 276, in save_changes
>    listener.ticket_changed(self, comment, author, old_values)
>  File "/home/abeld/WORK/trac-for-internal-inventory/trac-install/
> plugins/proba.py", line 54, in ticket_changed
>    ticket.save_changes('auto-script',None)
>  File "$pkg/trac/ticket/model.py", line 264, in save_changes
>    (self.id, when_ts, author, cnum, comment))
>  File "$pkg/trac/db/util.py", line 50, in execute
>    return self.cursor.execute(sql_escape_percent(sql), args)
>  File "$pkg/trac/db/sqlite_backend.py", line 58, in execute
>    args or [])
>  File "$pkg/trac/db/sqlite_backend.py", line 50, in
> _rollback_on_error
>    return function(self, *args, **kwargs)
> IntegrityError: columns ticket, time, field are not unique
>
>
> (where $pkg in the filenames is
> /home/abeld/temp-trac-install-dir/lib/python2.4/site-packages/
> Trac-0.11b1-py2.4.egg
> as I am using a locally-installed 0.11b1; and the trac instance is at
> /home/abeld/WORK/trac-for-internal-inventory/trac-install/)
>
>
>
> So, how should I be doing this? (I would like to store the date
> explicitly, even though it could be figured out by parsing the
> ticket's changelog, as well. However, having it stored in a seperate
> field means it is possible to show in the ticket view page / search
> for, and that manual editing of it can be allowed.)
>
> Should the above, or some variation of it work? Or do I have to open a
> new connection to the database? If the latter, are there any issues
> with multiple simultaneous connections to the db? (I am using sqlite
> db backend)
>
> Thanks in advance,
> Daniel Abel
> [EMAIL PROTECTED]
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to