Redmine

• Web app encounters an error, it can submit an issue automatically into your redmine instance and have context information submitted along with it.
• Within your app, create a custom form so that your users do not have to interact with redmine to submit issues. This form can contain app specific info to help you get better context surrounding the feedback. So, your web app would get the form post, but turn around and submit it to redmine via the REST API.

Good idea. If you have Ruby on Rails applications, you can use the hoptoad plugin to send errors directly to Redmine. I think the forks might have some additional features.

Eric Davis

Our apps range from PHP/Perl/ASP.Net so its nice to have an API interface to log them; currently i'm cheating and using a PHP script on the same server to do the job direct to the database.

Eric Hulser I think ideally you need to release the spec for your API development mid-development so we can all start working on things with the spec in mind. Rather then post-release. :o) Cool though

If you build it, we will use it. Keep it simple, keep it REST and we will be able to accomplish almost anything.

For example, simply exposing the TimeEntry objects with REST GET /time_entries/:id we could easily implement a time logger feature using :created_on and :updated_on. This may require allowing creation of time_entries without an :hours attribute.

Alternatively, add a "timer" attribute to TimeEntry. Returning and accepting "on" or "off", where a change in state from :on to :off updates the hours based on "hours += Time.now - timer_started_at; timer_started_at = nil". And :off to :on sets the "timer_started_at = Time.now". The "timer" attribute would just be "timer_started_at.nil? ? 'off' : 'on'". No new routes are needed, no complicated API, just PUT /time_entries/:id with {timer: on}.

I would also love to see the ability to use GUIDs instead of auto-increment ids; would make it much easier for aggregating multiple redmine instances. But I think this change is just my own little pipe dream.

Chris McKee wrote:

Eric Hulser I think ideally you need to release the spec for your API development mid-development so we can all start working on things with the spec in mind. Rather then post-release. :o) Cool though

What you don't want a 1000 page document for the API ;). I'm planning to follow the lead the other major Rails applications have used for their APIs; Highrise, Basecamp, Lighthouse, etc. Basically something ActiveResource can connect to and just work.

Andrew Briening wrote:

I would also love to see the ability to use GUIDs instead of auto-increment ids; would make it much easier for aggregating multiple redmine instances. But I think this change is just my own little pipe dream.

I'm following another Rails project that has been using GUIDs and they just decided to drop them. GUIDs ended up taking a lot of effort for the development to manage and was confusing to the users. To aggregate multiple Redmine you might just be able to prefix each ID with the url: redmine.org:5 projects.littlestreamsoftware.com:5...

Eric Davis

It's can be usefull for developing plugins for some IDE.
Example Visual Studio

I'm using the REST API to set up issues based on test results and todo comments (from subversion/nunit/teamcity):

http://www.tqcblog.com/archive/2010/01/28/adding-test-failures-and-todo-comments-to-redmine.aspx

I think we would be using it for Reporting integration with other tools such as Quickbooks etc...

Oh and one other thing. It would be amazing if we could set up a badge type system for fluid running redmine just like it does with google reader. It would certainly be an adventure as you would need some mark as viewed code, and a way to determine what is worth declaring a badge (things I watch, things the system emails me about, specific queries)..

I will definitely use the APIs to

• Create reports for management (who for some reason do not like web-interfaces and like reading/printing a PDF)
• Timesheet entry from the desktop

Those are the two biggest use-cases for me.

Just going to chime in here.

If the API is flexible enough, I might be willing to develop an Android application for Redmine. I have already built an app that access GitHub (Google "Hubroid"), so this should be quite an easy task.

With the basic REST support that's in the current trunk, I've written a .NET UnhandledException handler which posts user comments, system and environment information and the exception/stack trace into a specified Redmine project. I'm currently adding this in to all of our internal apps and it's already started paying dividends for tracking down and fixing bugs. It'll even fall back to creating an issue via email (using Redmine markup in the body) if the Redmine server isn't reachable. I'm waiting for the ability to add attachments to issues (for screenshots) via the API and it'll be complete. The library also allows users to log feature requests and non-crashy bug reports directly from the app.

After the REST API has fleshed-out a bit, I plan to write an Outlook add-in to pull ticket start and due dates into a user's Outlook calendar. It could even provide the option to post Outlook calendar changes into Redmine as either a new issue or as an update to an existing issue.

Lastly, like others, I'd like a desktop app for time tracking, and possibly for 'quick' issue submission and editing. I'm imagining a background app that responds to system-wide hotkeys to perform Redmine actions (Ctl+Alt+N - new issue, Ctl+Alt+S - search issues, etc)

Hi, i'm developing my own redmine's desktop client, but i need some help for continue with my personal project.

Chris, maybe we're in the similar situation, I'd like a desktop client for connect it with a time tracking system and update 'info' or 'hours' easily.

At this moment i can to create, edit and delete projects/issues but api has limited functionalities. I'm having problems with some things and some of them requires some aditionaly features for rest api. Basically are, send time, attachments, notes, etc, but this things aren't implemented yet, no?

In fact, i will appreciate a little more information of rest api features, i think wiki info or the examples could be more extended.

Eric, as an idea, another usefull thing for me can be issue's category control.

Sorry, basic question: if I'm interested in the current REST API support in Redmine, what files (or dir) should I look in to see what's exposed, etc? Thanks!