Topic: General / Server funkiness

In the last week or so I’ve been getting a lot of page timeouts (and the occasional RoR ‘Spawn’ error page) when accessing my account. Seems to be worst when I’m browsing the repository. Have also noticed that my API connections (when I’m sync’ing up my ticket list to vBulletin) are starting to grind real slow.

When things are working, they seem to be quicker and slicker than they were up till your recent server changes.

Topic: Feature Requests / commit hook for global rev?

As per my head scratching in this thread:

http://unfuddle.com/community/forums/5/topics/209

... concerning getting the latest global rev# (not file rev#, which can be done with SVN propertied) substituted into a given file, say version.php, such that …

$latest_rev = $LATESTREV$;

... would commit as …

$latest_rev = 675;

I’m not 100% sure, but I think this could possibly be achieved with a commit hook in SVN. But of course we don’t have access to commit hooks.

Would this be possible to add as an Unfuddle feature?

-- hugh

Topic: Subversion Help / svn comments in code

OK, this one is still driving me crazy. To recap, I need to get the global repo revision number into a PHP file (like version.php) at commit time. I can get individual file revs inserted easily enough using SVN properties.

But it seems like getting the global revision for the repo inserted into a file within the repo is somewhat problematic. There are tools like svnversion, and TortoiseSVN’s SubWCRev, but these are only useful for code which is built with some local ‘make’ style tool into a deliverable executable.

But this being a PHP project which our users simply checkout directly from Unfuddle, there is no ‘make’ or local build step involved. We (the authors) commit our changes, the users grab the latest SVN with something like Tortoise.

I think the closest I’m going to get is by using something like an Ant script in my IDE, to do the ‘svnversion’ post-commit, modify my version.php accordingly, then separately commit version.php. But of course this means that the version I poke into version.php will automatically be out of date, as the global rev will increment when I commit version.php. I guess I could just increment the rev I get back from svnversion, but it’s still a big old kludge.

The other problem with this approach is, we have as many IDE’s in use as we have developers … I use Komodo, others use Eclipse, and so on. So we’d need to code up the kludge separately for each IDE.

Anyone got any ideas? I had hoped that I might be able to use repo hooks, but a quick search of the forums tells me these are not available to us for security reasons, which is quite understandable.

-- hugh

Topic: Subversion Help / REPORT request failed

As per the thread I pointed at (were you able to see that?), that was the first thing I had him check.

We have another clue now, which is “non ASCII byte 243: unable to convert to/from UTF-8”.

I’ll get him to try with https, but I think this may be a language problem? He’s running Spanish language Tortoise.

-- hugh

Topic: Subversion Help / REPORT request failed

One of our customers is having problems with SVN, getting a “REPORT request failed” error in both Tortoise SVN and RapidSVN. See this thread in our support forums (I think you should have access without having to register):

http://fabrikar.com/forums/showthread.php?p=39986#post39986

Any ideas?

-- hugh

Topic: Unfuddle API / vBulletin API product

Joshua,

Thanks for taking the time to walk through the new vBulletin stuff with me. It was indeed good to put a voice to a name.

It’s still very much a work in progress, but you definitely got the idea of what I’m trying to do. I’ve added a few more features in the last few days, like setting Resolutions, and being able to edit (almost) all the fields of a ticket.

I liked your description of the new meta-data feature, and am looking forward to it. You can obviously see why I really want that feature, now you’ve seen what I’m working towards. A tight integration of support threads (and users) in the forums with Unfuddle ticket(s). Coupling our support activities with our development track.

-- hugh

Topic: Unfuddle API / Location response on PUT?

Cool.

I’m really happy with the API. It’s working flawlessly, and I hope to finally have our vB forum integration stuff live by the end of today.

Thanks for all your hard work, and as always your quick responses to my questions.

-- hugh

Topic: Unfuddle API / Location response on PUT?

Should the API return a Location header after a PUT, as it does after a POST, giving the ID of affected record?

Not a biggie, obviously we already know the ID of the record we just edited, just wondering if I’m missing something.

-- hugh

Topic: General / View recent comments?

My apologies, I realize you did indeed fix this. It’s just that our commit messages are crowding them out of recent activity. We’re in Beta on v2 of our product, and committing changes at a fearsome rate. So I just wasn’t seeing the wood for the trees.

Pilot error once again. Mea Culpa.

-- hugh

Topic: Unfuddle API / vBulletin API product

I’ve pretty much finished the vB API package I’ve been working on in my Copious Spare Time, based on SirAdrian’s original API code. I may release it on vbulletin.org at some point, but would like to find a brave volunteer to help Beta test it first.

If you use vBulletin for your end user support forums, you may well find this useful. What it does is lets you (the configured ‘unfuddlers’, i.e. staff members with associated Unfuddle logins) easily create new Unfuddle tickets and ticket comments (optionally based on a forum post), and associate existing tickets with forum threads. It supports multiple Unfuddle projects, with optional project default based on forum ID.

Any threads with associated tickets show a table at the top of the ‘showthread’ page, listing the associated tickets. Likewise on the ticket display page, it lists all threads associated with that ticket. Also, on the ‘forumdisplay’ page, any threads with associated tickets get a little ‘bug’ icon next to the thread title.

For vbA CMPS users, there is also a module (“Tickets of Interest”) which lists all threads the logged on member has posted in which have associated tickets. Also a module which lists the last X SVN changesets (revision number and commit comment) for each configured project. An optional template edit also lets you show the latest SVN rev for each project at the top of every vB page.

What I’m aiming at is twofold:

1) To provide a simple way for users to see progress on tickets associated with their support threads, and keep tabs on the SVN change history. I’m also working on a module to list all revision comments between checkpoints, i.e. to act as a “Change History” when you release a new version.

2) To provide a simple way for staff to create and update tickets directly from the support forums. So when a user posts a bug report, a staff member confirms it as a bug, posts a response to the thread, and then can just click a button on the postbit of their reply, creating a new Unfuddle ticket based on that response, and automatically associating the thread with the new ticket. Or if a ticket already exists for that bug, associating the thread with that ticket.

If you are interested, post a reply, and we can arrange to show you round my test site, see this stuff in action, and take it from there.

-- hugh

Topic: Unfuddle API / Bad Request, No Donut

Pilot Error.

An old config value had crept in, and my assignee-id didn’t exist.

Would have been nice to get some feedback in the response, though!

-- hugh

Topic: Unfuddle API / Bad Request, No Donut

Can someone tell me whats wrong with this request data? I’m trying to create a new ticket. I had the same code working in Joomla, using JSON, now I’m doing some back porting into vBulletin, using XML.

Unfuddle is telling me “400 Bad Request”. Unfortunately, no actual errors in the content of the 400 response.

<?xml version="1.0" encoding="UTF-8"?>
 <ticket>
     <assignee-id type="integer">8861</assignee-id>
     <component-id type="integer">9397</component-id>
     <description><![CDATA[Some random test text.]]></description>
     <milestone-id type="integer">0</milestone-id>
     <priority>3</priority>
     <severity-id type="integer">11903</severity-id>
     <status>new</status>
     <summary><![CDATA[A test title]]></summary>
     <version-id type="integer">12890</version-id>
 </ticket>

-- hugh

Topic: General / View recent comments?

Bumpity bumpity bump.

Joshua – is this one at least on y’alls radar?

-- hugh

Topic: General / Scrum and Unfuddle

So does this make you guys Scrumfuddlers?

Sounds … slightly perverted … :)

-- hugh

Topic: General / Billing

No PayPal?

Isn’t that like unconstitutional or something? I distinctly remember an amendment along the lines of “the right to bear arms, watch NASCAR, and pay online with PayPal.”

-- hugh

Topic: Feature Requests / Configurable ticket fields

See the bottom of this thread:

http://unfuddle.com/community/forums/6/topics/70

Bottom line, Unfuddle are obviously very aware of the number of people needing this ‘custom meta data’ feature, and are working on exactly what you and I need.

It may not happen as quickly as we would like, but from what Joshua has described so far, it will be a comprehensive solution, rather than a band-aid. Well worth the wait.

-- hugh

Topic: Unfuddle API / Additional ticket fields

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

Topic: Subversion Help / svn comments in code

Well, we he have two ‘tracks’ for our code. The ZIP’s and SVN. It’s a Joomla app, so when its time to build a new release, we do the usual Joomla specific ZIP build (by hand) for use with Joomla’s component installer. We only do this 2 or 3 times a year, so it’s not a problem remembering to update our FABRIK_VERSION definition.

Between ZIP releases, we simply make our SVN code available direct from Unfuddle, using an anonymous login. There is no ‘packaging’ involved for this, they just update from SVN using something like Tortoise, then export and upload to their Joomla server via ftp, overwriting existing files.

As we typically commit several changes per day to SVN (Fabrik is a large and excruciatingly complex application builder!), remembering to update our version definition every time we commit a change is a problem.

Just to clear up my terminology. We tend to call our users ‘admins’, as the have their own users, and it gets confusing. So they are Joomla admins, using Fabrik to build applications for their users.

-- hugh

Topic: Unfuddle API / Additional ticket fields

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

Topic: Subversion Help / svn comments in code

How do I get SVN to put the version info for each file in those cute header / footer comments?

On a related note, is it possible to maintain something like a version.php file, which automagically updates a simple define when we commit, like …

define(‘FABRIK_VERSION’, xxx);

We have a working API call in our app so admins can get the current SVN rev from Unfuddle, but that is of limited use unless we can establish what rev they are actually running. At the moment, we try to remember to update our version define manually, but that’s kinda hit or miss, LOL!

TIA for any assistance.

-- hugh

Topic: Bug Reports / all about notebook markups

Here’s an idea … there’s a new fangled markup language that comes with this interweb thingy called HTML. I think Al Gore invented it. It’s making some headway in the world of markup languages and standards.

Of course, being a somewhat powerful language, it does need to be cleaned up a little if users are allowed to enter HTML directly. Something like HTMLpurifier (http://htmlpurifier.org/) is a must. All you’d have to do to use HTMLpurifier would be to rewrite Unfuddle in PHP. :)

Are there any HTML purifiers for RoR?

-- hugh

Topic: Feature Requests / Branding

Hendy … I really hate to see that evil cuss word “sue” used on these forums. Unfuddle is like any hosted service – they don’t guarantee that your data is safe (unless they specifically offer disaster tolerance, which Unfuddle clearly don’t).

What they do provide an obvious and easy way to download a backup of your projects, and it’s entirely up to you to take advantage of that. If some disaster took out Rackspace’s operations center, or some Black Hat messed with your code, and you didn’t have a recent backup … that’d be your problem. Expecting to “sue them easily” because you chose not to backup your data would be ridiculous. Classic modern day American “I’m not responsible for myself, it’s all someone else’s fault!!” mentality that just makes my flesh crawl.

That said, I would certainly like to see a “Disaster tolerance” feature as an optional extra in the higher level packages offered by Unfuddle, whereby they provide nightly offsite backups to some other provider the other side of the country from the primary site. I’d be more than happy to pay a few extra bucks a month for this.

But as things stand … if your data is mission critical … “request a comprehensive archive” is your friend!

-- hugh

Topic: Feature Requests / Thread starter on forums

I just noticed you added the thread starter … thanks!

-- hugh

Topic: Unfuddle API / Additional ticket fields

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

Just a reminder …

-- hugh

Topic: Unfuddle API / reported_by and assigned_to changes

Grrrrrrrr.

:)

-- hugh