Project

General

Profile

Actions

Rest Issues » History » Revision 18

« Previous | Revision 18/70 (diff) | Next »
Álvaro Arranz, 2010-11-26 12:43
sorry, I tested it using an old version of redmine


Issues

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:

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=*

Response:

<?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>

Showing an issue

GET /issues/[id].xml

Creating an issue

Using XML

  POST /issues.xml
  <?xml version="1.0"?>
  <issue>
    <subject>Example</subject>
    <project_id>1</project_id>
    <priority_id>4</priority_id>
  </issue>
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
  • ...

Using JSON

POST /issues.json
{
"issue": {
"project_id": "example",
"subject": "Test issue"
}
}

Updating an issue

Using XML

PUT /issues/[id].xml

Using JSON

PUT /issues/[id].json
{
"issue": {
"subject": "Example issue (was: Test issue)"
},
"notes": "Changing the subject"
}

Deleting an issue

DELETE /issues/[id].xml

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):

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

Updated by Álvaro Arranz about 14 years ago · 18 revisions