Every Bug Deserves Its Own URL

We use TestTrack Pro for bug tracking at my new job. Mostly i find it to be a ho-hum tool. I've seen better, and i've seen worse. But there is one thing about it that really bugs me. I want to be able to reference bugs -- in emails, in wiki pages, in documents -- and i want to make the links clickable: so anyone reading can click to see the actual bug report, along with any updates that have been made since. But TestTrack doesn't seem to support this.
I've gotten used to doing this kind of thing using Bugzilla and Jira and the tracker included in the SourceForge package. They all make it easy to access a bug report via a URL that embeds the bug number. See for your self with these examples using Bugzilla, Jira, and the SourceForge tracker. When compiling bug lists, whether to group related bugs or to pull together a release plan, i've gotten in the habit of including the URLs so that readers can immediately look up the details themselves. With time, the plan itself becomes a simple tool for tracking progress.
But i can't do this with TestTrack Pro, and it's driving me crazy. I have both a windows client and the web client for it. The problem with the web client seems to be that it uses a post to retrieve a particular bug record, and that means that the request can't be summarized in just a URL. The other tools don't have this problem because they use a get instead. I've been told that TestTrack violates web standards that stipulate that posts should only be used for transactions, whereas gets should be used for queries. All i know is that this is driving me nuts. This issue itself is making me start thinking that we'd be better off switching to another tool.
I want to make it easy to get people to look into the bug database. I want to get managers looking in there. I want to get everyone on the team looking at it, and fixing the bugs and updating the reports. I want it to be relevant and accurate. All too often documentation that is hard to reference and share and point people to is documentation that goes unread and unupdated. And if no one is looking at it, what's the point of taking care in keeping it up to date?
Am i crazy? What do you think? Does your tool allow you to reference a bug report using a URL? Do you use this "feature"? Put your details regarding the tools you use in comments, and i'll compile a matrix of which tools do and don't provide a URL for each bug report.
Update: December 28, 2005. Several commentors suggested i write a gateway script to convert a GET into a POST, but that didn't work out. In fact, as Danil suggested in comments, I found out that the Test Track interface actually works just as well with a GET as with a POST. That's good. However, one of the data items that needs to be submitted is a session variable named (misleadingly) "cookie", and there is no way for a gateway script to provide this. I was hoping that if it were omitted, Test Track would simply ask for your name and password, but it doesn't. And if you are already logged in, that still doesn't help, because there is no easy way to reuse your session id, because it really isn't a cookie, despite the name. So i'm giving up on this one.
(As i write this, i'm realizing that i could write a script that hard-coded my login and password in it, have it log into Test Track, get a valid and current session ID ("cookie") and then use that for the bug report. That would be hairy, insecure, and a long way off from my original goal of a simple URL. )
Here are additional tool details from comments:
Gives each bug a URLGeminiFogBugz
Isolates bugs from the worldPVCS TrackerMercury Test Director (previous release)