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 idtracker_id
: get issues from the tracker with the given idstatus_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