Redmine

h1. Issues

h2. Listing issues

  GET /issues.xml

Returns a paginated list of issues. By default, it returns open issues only.

+Parameters+:

* @page@: page number (optional)

Optional filters:

* @project_id@: get issues from the project with the given id

* @tracker_id@: get issues from the tracker with the given id

* @status_id@: get issues with the given status id only (you can use @*@ to get open and closed issues)

* ...

+Examples+:

<pre>

GET /issues.xml

GET /issues.xml?project_id=2

GET /issues.xml?project_id=2&tracker_id=1

GET /issues.xml?assigned_to=me

GET /issues.xml?status_id=closed

GET /issues.xml?status_id=*

</pre>

+Response+:

<pre>

<?xml version="1.0" encoding="UTF-8"?>

<issues type="array" count="1640">

  <issue>

    <id>4326</id>

    <project name="Redmine" id="1"/>

    <tracker name="Feature" id="2"/>

    <status name="New" id="1"/>

    <priority name="Normal" id="4"/>

    <author name="John Smith" id="10106"/>

    <category name="Email notifications" id="9"/>

    <subject>

      Aggregate Multiple Issue Changes for Email Notifications

    </subject>

    <description>

      This is not to be confused with another useful proposed feature that

      would do digest emails for notifications.

    </description>

    <start_date>2009-12-03</start_date>

    <due_date></due_date>

    <done_ratio>0</done_ratio>

    <estimated_hours></estimated_hours>

    <custom_fields>

      <custom_field name="Resolution" id="2">Duplicate</custom_field>

      <custom_field name="Texte" id="5">Test</custom_field>

      <custom_field name="Boolean" id="6">1</custom_field>

      <custom_field name="Date" id="7">2010-01-12</custom_field>

    </custom_fields>

    <created_on>Thu Dec 03 15:02:12 +0100 2009</created_on>

    <updated_on>Sun Jan 03 12:08:41 +0100 2010</updated_on>

  </issue>

  <issue>

    <id>4325</id>

    ...

  </issue>

</issues>

</pre>

h2. Showing an issue

  GET /issues/[id].xml

h2. Creating an issue

h3. Using XML

<pre>

  POST /issues.xml

  <?xml version="1.0"?>

  <issue>

    <subject>Example</subject>

    <project_id>1</project_id>

    <priority_id>4</priority_id>

  </issue>

</pre>

Other available tags:

* description

* category_id

* assigned_to_id - ID of the user to assign the issue to (currently no mechanism to assign by name)

* status_id

* ...

h3. Using JSON

  POST /issues.json

  {

    "issue": {

      "project_id": "example",

      "subject": "Test issue"

    }

}

h2. Updating an issue

h3. Using XML

  PUT /issues/[id].xml

h3. Using JSON

  PUT /issues/[id].json

  {

    "issue": {

      "subject": "Example issue (was: Test issue)"

    },

    "notes": "Changing the subject"

}

h2. Deleting an issue

  DELETE /issues/[id].xml

h2. Authentication

To interact with issues that are not open to the public you _must_ use your API key or username/password.   The API key is a handy way to avoid putting a password in a script.  You can find your API key on the My account page ( /my/account ) when logged in, on the right-hand pane of the default layout.  The API key may be attached to the GET request as a "key" parameter or it may be passed in as a username with a random password.  (Note that at the time of this writing, the "key" parameter will not be able to retrieve a specific issue.)

+Examples _(not real keys)_+:

<pre>

GET /issues.xml?key=1a022b4661da64e5dca53ebab0c94ad7

GET /issues.xml?project_id=2&key=1a022b4661da64e5dca53ebab0c94ad7

GET /issues.xml?project_id=2&tracker_id=1&key=1a022b4661da64e5dca53ebab0c94ad7

</pre>