Improvements : external tracker and zero client rate

[Aurélien Bompard]

I have written two improvements (well, at least I think they're improvements ;-) ) to ClientsPlugin :

• make it possible to set the client rate to zero
• add an "external tracker" field for each client (optional) when the client has its own bugtracker.

The two features are independant, except on 1 file where they overlap, otherwise I'd have provided two patches.

To understand the motives behind the patch, I must explain how I use Trac. I'm responsible for a shared project in a rather big organization, so I have internal clients : other projects using my shared project. As a result, my clients are not "billable", and they always have their own tracker where they open bugs for my project. When they do, I open a bug in mine, assign it to someone in my team, and forward the resolution to their tracker. Thus, I must track the bug reference in my client's tracker.

No client rate

The first part of the patch makes it possible to set the default client rate to zero. In this case, a small piece of javascript hides the field in the ticket form. It does not affect the previous feature : if you don't set a default client rate, the field is not hidden and you can set it manually. No default rate and a default rate of zero are two different things.

I have thought of another way to do it : on the client form, add a checkbox to set it to "not billable". I did not do that because it was more invasive in your code, but I think it may have a better usability.

External tracker

The second part of the patch adds an optional field to the client form (and the database) where an URL to the client tracker can be set. This URL may contain the "%s" string, which will be replaced by the bug number on the ticket form.

The ticket form has an extra custom field where the client bug number can be set. On ticket display, an href link is created using the template client tracker URL.

Please tell me what you think of this patch, if you agree to include it, if it needs more work, etc.

Thanks

[Colin Guthrie]

Hi there,

Firstly thanks very much indeed for the the patch.

I have to confess that I actually had to make a zero-rated client locally not that long ago and forgot to push the change live :s So a little duplicated effort there for which I apologise. Your patch seems to go a little further than mine with some JS cleverness so I'll look to incorporate that.

Your external tracker patch is also interesting, but perhaps a bit too involved for my own personal tastes. We also use an external tracker for clients to use (www.zendesk.com) and then allocate internal Trac tickets to track the time and commits to implement their request/fix the bug.

Now in order to integrate with the external tracker, we use the InterTrac system to define our external tracker and then simply put ZenDesk:1234 in the ticket description and it's magically turned into a link to the bug on our tracker. While this is simpler and built in, I can see some value in your approach as it would allow for some degree of automated integration (i.e. use some kind of API to close the upstream report when the trac ticket is closed). But I also like the relative simplicity of my current approach.

I'd be interested in hearing your comments on the two approaches.

[Aurélien Bompard]

Your external tracker patch is also interesting, but perhaps a bit too involved for my own personal tastes. We also use an external tracker for clients to use (www.zendesk.com) and then allocate internal Trac tickets to track the time and commits to implement their request/fix the bug.

That wouldn't work for me because the external tracker is GForge-based (client choice).

Now in order to integrate with the external tracker, we use the InterTrac system to define our external tracker and then simply put ZenDesk:1234 in the ticket description and it's magically turned into a link to the bug on our tracker. While this is simpler and built in, I can see some value in your approach as it would allow for some degree of automated integration (i.e. use some kind of API to close the upstream report when the trac ticket is closed). But I also like the relative simplicity of my current approach.

Yes, I also like the fact that it's a separate field in the database, this way I can setup reports and queries without having to parse the description. I agree it's more invasive, because it changes the database model, however it doesn't feel like "highjacking" the ticket description. And the code isn't very complicated either (which means more likely to be stable).

As you mentionned, some extra features may be available eventually. Updating the remote ticket, or even displaying the remote ticket status would be nice. It's not my priority though, but having the foundations set right is always good to have.

[Aurélien Bompard]

New version of the patch, fixes two bugs related to ticket previewing

[hju]

This is a nice enhancement. We face a similiar challenges. We are using trac also to track tickets at 2nd level support of different sw developers.

The 'external tracker' is helpful.

Unfortunately there is a bug in the patch if you try to insert a new client:

Trac detected an internal error:

TypeError: not all arguments converted during string formatting

File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 450, in _dispatch_request
  dispatcher.dispatch(req)
File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 206, in dispatch
  resp = chosen_handler.process_request(req)
File "/usr/lib/python2.5/site-packages/trac/admin/web_ui.py", line 114, in process_request
  path_info)
File "/usr/lib/python2.5/site-packages/trac/ticket/admin.py", line 44, in render_admin_panel
  return self._render_admin_panel(req, cat, page, version)
File "build/bdist.linux-i686/egg/clients/admin.py", line 62, in _render_admin_panelFile "build/bdist.linux-i686/egg/clients/model.py", line 87, in insertFile "/usr/lib/python2.5/site-packages/trac/db/util.py", line 64, in execute
  return self.cursor.execute(sql_escape_percent(sql), args)
File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 80, in execute
  PyFormatCursor.execute(self, *args)
File "/usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py", line 57, in execute
  sql = sql % (('?',) * len(args))

Its located in line 82 of model.py

        cursor.execute("INSERT INTO client (name, description,"
                       " default_rate, currency, external_tracker) "
                       "VALUES (%s,%s, %s,%s)",
                       (self.name, self.description,
                        self.default_rate, self.currency,
                        (self.external_tracker or None)))

there is a %s missing

                       "VALUES (%s,%s, %s,%s,%s)",