We know you! You’re the guy wit da javascript api! That’s cool that you’re posting/sharing, thanks for that. Per the cache comment, I think Mustafa is going to be in touch with you. Per the Chrome extension, might I suggest “Chome Dome” as a name. Not really. But maybe. Also, if you’re getting through your initial prototype and want to collaborate on some UI/UX together, give a holler. We’re here. Doing DoneDone, and obviously happy to chip in.

Cheers,

Craig

Not terribly clean yet, just a proof of concept, but its working for what I need it to do.

One major note: Requests to the same resource are rate limited to one request per 5 seconds. That can lead to headaches if you don’t cache responses. Right now my code overly caches, and needs to have better cache management.

I don’t even mind the smiley :)

Sorry about that one, it’s being addressed as we speak, and most likely will be released in our 5:30 CST build today. Also, going up … this documentation will be available inside of the app, so no more clicking over to the blog :)

Thanks for the bug report, and chat soon.

Cheers,

CB

I managed to get this working with Beanstalk, except for Example B (where only an issue number is specified). When I tried this, no comments appear in DoneDone – but as soon as I add a status change, it works!

Any ideas what I may be doing wrong?

Thank, Rob

We’re aware of an army of passionate Bitbucket users as well. This is a service we can and will get up and running soon. Thanks for the ding.

Cheers,
Craig

Thanks for the Bugshooting bump. That’s absolutely right. You can take a screenshot and create a new issue directly from the Bugshooting app. It’s pretty straight forward and well supported.

Cheers,
Craig

Thanks for checking in, that’s a good question. You can currently create new issues and add comments via email, but we don’t have immediate plans for updating issues. Let me get back to you on this though, as it may be something we can get in queue since the hooks are already there.

Chat soon,

Craig

Good to hear from ya. If I’m understanding you correctly, are you thinking that we’d create a way for Account/Project admins to create their own alerts which post to a project/account dashboard?

Cheers,

CB

This would allow the project administrator to put out a statement when the project is started, when the project has reached a certain phase, etc.

thank you for your help!

- eike

Dates should be returned as the number of milliseconds since Unix epoch time. Divide by a thousand and you should be able to use the PHP *date* function (http://php.net/manual/pt_BR/function.date.php) to create the date in any format you choose – just remember to divide the value we pass back to you by 1000 before doing so.

Mustafa

Thany you !

–eike

Sorry for the delay in getting back to you.

That’s great to hear that you’ve finished up the API wrapper for PHP – would love to link back to it from our site once you publish it on github. Drop us a line when you think it’s ready.

Ahhh…rate limiting. I confess that I knew going in that we may have been a little strict with the way it’s been implemented. Currently – the API uses a combination of the API method you are calling on your domain name (such as mycompany.wearemammoth.com/issuetracker/api/projects) and your requesting IP address to determine whether you’re allowed to call the method. As you noticed, it only permits you to call the same method from your IP address once every five seconds.

As mentioned in a previous post about the API – I’m open to changing this limit or how it’s implemented as we get a feel for how it’s being used. I’m not sure if using the parameters passed in to a method, however, is enough to protect our side from being flooded with requests. If we rate limited method calls with their incoming parameters originating from the same IP address, we open ourselves up to a situation where someone could call mycompany.mydonedone.com/issuetracker/api/peopleinproject/[ANY_NUMBER] however many times they like within any period of time, thus essentially bypassing the ratelimiting.

With all that being said, I also understand that this seems unnecessarily paranoid and I’d love to hear any ideas you may have as to how you think the rate limit should be implemented. Feel free to email me directly at mustafa.shabib[at]wearemammoth.com for what I promise will be a much faster response.

Thanks again for writing.
Mustafa

Thanks for the comments. You’re absolutely right – thanks for catching the mistake in the post re: the example hash! Really sorry about the confusion. I’ve updated the post above with the correct value, which matches what you’re getting.

In the spirit of transparency, let me explain why we opted to require signatures on incoming requests from API users.

As far as the signature requirement being redundant or frustrating, I’m not in disagreement with you. The reason we opted to make it required was because when we started development, we hadn’t decided if all accounts would be running over SSL. While we will initially be rolling the new version out to all users with SSL, we may someday have a plan that may not run on SSL and rather than create a set of rules to use the API that further complicated things (as in: if you’re using SSL, you don’t need to sign your messages, if you aren’t using SSL then you are required to sign your requests), we opted to make it a requirement from the beginning, both to give us the most leeway and to prevent further changes to the API requirements for client library developers.

To that point – with client libraries that we’re hoping will soon start appearing (we’ll release a .NET library soon after the new DoneDone’s release), the signing of messages will be transparent to most developers using the API. Hopefully, this cuts down on the frustration.

So, mostly, it’s a throwback to a time we weren’t sure about the SSL options we’d be providing to everyone and additionally it provides us with the most flexibility to offer as many people as possible access to the API in a secure manner regardless of which plan they’re on in the present or in the future without requiring anyone to change the code they’re using to integrate with the new API.

Thanks for writing.
Mustafa

Also, is your example accurate? If I base64 encode an hmac sha1 using http://wearemammoth.mydonedone.com/issuetracker/api/projects as the data to sign (no extra params appended because it’s a GET request) and 5F4CAC0C16977B21F4CE3766D913FE74 as the key, the output I’m seeing is L1Zb6/R1byxutuhgj49RMXcZgok=

Thanks!

We set you guys up for your test account … you’ll want to check in w/ your account admin to make sure he gets you added, up, and running.

Thanks, hope ya like what you see, and let us know what ya don’t.

-Craig

that’s great to hear!
Depending on the amount of phrases to translate, I can help with Russian localization (eventhough what we need most is Japanese one :). Just let me know at my email from this comment when you have the phrase list ready!