After spending the weekend playing with the API (and getting a working first cut at a “Recent Tickets” module going in Joomla) there’s two extra fields I’d love to have for tickets:

1) An optional, configurable dropdown for “Reported by” which lets me add non-Unfuddle usernames. This way I can build a list of Joomla usernames for people on a home site who report bugs, but for one reason or another haven’t been let loose on Unfuddle itself. I could then add an option to configure the Joomla module to show only tickets “reported by” the logged on user. This would obviously apply to any CMS system, be it Joomla, or vBulletin with vbAdvanced CMPS, etc.

2) A “Report URL” field. Basically a URL to the thread on the home site where the bug was reported and is being discussed.

Replying to myself again! My Mom always said that’d make me go blind, or something.

Just to clear something up on my request 1) above. I used the term “Reported by”, but I really should have picked some other phrase which doesn’t collide with the existing “Reporter”. So call it something like “Originator”. The “Reporter” would remain unchanged, as the Unfuddle user who enters the ticket. The “Originator” would be the third-party username I described.

bump

I’d like to repeat my request for a “Report URL” field on tickets.

Here’s why it’s important to me. I’m building Unfuddle integration into our home site using the API. The whole point of the API is obviously to provide good linkage between Unfuddle and a “home site”. Like most home sites out there, we have forums where the users post their questions and bug reports.

So for each Unfuddle ticket raised via the API, there is typically going to be an associated thread on the home site forums where that issue was raised, and discussion continues.

A very obvious requirement (one might almost say a de-facto requirement) for the API is therefore linking the Unfuddle ticket to the discussion thread. Although I already do this by automagically inserting a link into the ‘description’ when a new ticket is created (using the referring URL if they click on the ‘new ticket’ button on a thread page), this is only really useful for human usage (clicking on it by hand).

Where this workaround falls over is when trying to do any kind of linkage on the fly. For instance, a plugin for the forum software which would look up it’s own URL in the ticket data, and show a ticket summary at the top of any thread that has an associated ticket. As you know, I’m maintaining locally cached Unfuddle data, so having an indexed column in the ticket table for the report_url would make this trivial.

I’m working round this right now when I sync the Unfuddle ticket data into my local db, by picking out the first thing that looks like a URL from the ticket description, and schlepping that into my own indexed report_url column. But that’s kind of hit and miss. It only really works well if the user hits the ‘new ticket’ page via the thread link, so I can put in a specific “Discussion thread: …” line, which can easily be regex’ed out when sync’ing.

Sorry to go on about this, but I see it as another fundamental requirement for an API which truly integrates a ‘home site’ with Unfuddle.

Replying to myself for the third time, LOL!

How about as a compromise simply (!) allowing us to add “user defined fields” to our ticket data? If dynamically adding extra fields is too much, maybe just a couple or three static ‘userX’ fields we can use for our own purposes?

On the Unfuddle GUI side, just allow us to set whether to display each field, and the display title to use for it. And maybe what size of text field to use for it. On the API side, they’d always just be , etc.

That would be enough to get me off y’alls back about this. I’d use user1 for storing the local userid of the person who submitted the ticket on my site, and user2 for the related thread URL.

Having the local userid stored in the ticket is vital for the API, because all tickets end up being submitted by the same Unfuddle user, the default we have to use to do the CURL connections from the server. There’s no sane way to provide individual end user credentials, so all API work is done using a single, configurable Unfuddle user.

Obviously it’s somewhat helpful to have the local userid in the ticket data, so I can do stuff like ‘show all my open tickets’.

Hugh,

Okay. We definitely hear your need here. We have considered adding support for custom fields to tickets in the past but for a number of reasons dismissed the idea.

With the advent of the API, it is probably time to re-evaluate this. We will most likely fall in on the side of this being a good idea. That being said, the earliest that it would realistically happen would be the beginning of 2008. Our development timeline is already pretty packed between now and Christmas.

Hugh, thanks again for being such a forerunner in the development and use of the Unfuddle API. It really is feedback like this that continues to evolve Unfuddle into such a useful product.

No problem, I can wait. I’ll be pretty busy with other stuff till the new year anyway. This is the busy season for musicians, I’ve got wall to wall gigs for most of the holiday season, which cuts into my evenings (when I do my fun coding, as opposed to my paying the rent coding).

Thanks for listening!

Hey, well lookee here, it’s 2008 already!

Just a reminder …

Bump. 2Q2008.

We’re within weeks of releasing our New and Improved support site, and really need to find some non-kludgy way of associating users and threads on our support site with Unfuddle tickets.

I can obviously get it going by inserting meta data in the ticket description using the API when we open the ticket for them on the support site.

The way this work is we have a button on the ‘postbit’ for each support forum post, which only admins can see. If we decide it’s a bug rather than Pilot Error, we hit the button, and use the API to add a ticket (as our Unfuddle ‘anonymous’ user). At the moment, I’m inserting metadata into the description field to show the support forum username and thread ID. This semi works, but is a pain in the rear when we want to let the users search for “their” tickets, as it involves full text searching on all tickets.

So as explained above, I’d really like to have a couple of custom fields I can search directly via the API.

Also as explained, regardless of the Party Line (“Unfuddle is for the developers, not the users”), the whole point of an API would seem to be to allow linkage of things like support forums and Unfuddle. Which is what I’m trying to do …

Hugh,

We appreciate the bump — it is well deserved.

Over the past 6 months, we have received all sorts of requests and suggestions as to how we could improve Unfuddle, especially in the areas of flexible ticket classification, categorization and attachment of meta data. Thank you to everyone who has weighed in.

Hugh, while we originally intended to implement your specific field, we have since opted to solve the problem once and for all. While our more comprehensive solution is taking a little more time, we believe that it will better serve our customers as a whole.

For now, I would suggest continuing to use the description field to store meta data for your ticket.

Thanks again for your patience as we truly strive to build the best product we can for our fellow developers.

I presume I’m not revealing any State Secrets by mentioning the custom meta-data we discussed in email.

Can you provide any more details on how this will work? I mentioned some kind of generic custom field mechanism in my fourth post on this thread, as an alternative to the specific . From what you’ve said so far, it sounds like you’d be providing a more flexible mechanism to add named custom fields / meta-data, rather than a simple fixed number of userX fields on ticket data.

Hugh,

That’s correct. We are, in fact, working on a flexible mechanism for both tagging objects within Unfuddle as well as attaching arbitrary meta-data. This system negates the need for custom fields (yay) as we have discussed previously.

The rest of the details are still State Secrets. If I told you, then I would have to … well you know ;-)

Have a great weekend.

Hi Joshua:
What is the current state-of-play on this?
Also, how do you support what people want to do with custom fields (provide slots for workflow-specific data, and then sort/filter on that), without providing custom fields?
Graham

Graham,

We are still working on a more flexible system for tagging objects within Unfuddle. However, we have some more big infrastructure modifications that have unfortunately stolen a lot of our time.

As the need for custom fields is so important for many of customers, we have been considering pushing out an intermediate update that just a static number of custom fields that we can later grandfather into the new system. These custom fields would work identically to the current fields on tickets.

Continued over here:
http://unfuddle.com/community/forums/1/topics/352

This topic seems to be getting no where – whats the current status as its an issue with us also?