Feature #7180

List of statuses in REST API

Added by Mark Kofman almost 7 years ago. Updated about 6 years ago.

Status:ClosedStart date:2010-12-27
Priority:HighDue date:
Assignee:Jean-Philippe Lang% Done:

50%

Category:REST API
Target version:1.3.0
Resolution:Fixed

Description

Now it is impossible to get the list of all available statuses through Rest API.


Related issues

Related to Redmine - Defect #7819: REST API Populating issue field enumerations + Issue list... New 2011-03-09
Related to Redmine - Feature #7402: REST API - Enumerations New 2011-01-21
Related to Redmine - Defect #8596: Make possible to obtain issue_priorities and issue_status... Closed 2011-06-13
Duplicated by Redmine - Feature #7866: Get all issue statuses for project Closed 2011-03-15

Associated revisions

Revision 7878
Added by Jean-Philippe Lang about 6 years ago

Adds API response to /issue_statuses to get the list of all available statuses (#7180).

History

#1 Updated by Alex Last almost 7 years ago

  • Assignee set to Jean-Philippe Lang

Jean-Philippe, I hope you don't mind that I'm assigning this request to you. Maybe you could find some time to implement this in 1.1.0.

#2 Updated by Rodrigo Recio over 6 years ago

I've made a pull request on edavis10's github (my github is rrecio) of a code that expose issue_statuses through REST (I did for trackers too), can anyone do something about this?

#3 Updated by milki milk over 6 years ago

I believe I have a better patch than rrecio:

https://github.com/milki/redmine/compare/master...issue-status-api

I've exposed index/show for issue-status - no longer needs admin access
index will list all the statuses
show will allow you to retrieve one either by id or name

I've added 3 tests for each one of them.

#4 Updated by milki milk over 6 years ago

milki milk wrote:

I've exposed index/show for issue-status - no longer needs admin access

I should clarify this. Index is only exposed via api for everyone. Only admin can access the web interface still.
Show only exposes an api interface since its not useful otherwise.

#5 Updated by milki milk over 6 years ago

#6 Updated by Ewan Makepeace over 6 years ago

+1

This is a bit of a showstopper for my friend's iPhone App RedminPro: http://itunes.apple.com/us/app/redminepro/id415596033?mt=8

I can use it to reject my developers work, but as soon as I find an issue that is completed I am stuck - he is only able to populate the status menu with options seen in the list of issues I pull - and since I only get open issues, he never sees a Closed status, and so it is not on the menu...

Clearly populating menus with the values seen in a small sample of records is no way to be writing a UI but until REST provides enumeration of Status (and other fields) all developers of plugins and desktop software will be similarly stuck.

Related: #7402, #7506, #7819

#7 Updated by milki milk over 6 years ago

I guess this should be moved to patches instead of feature. Maybe patches are actually seen by developers? Is it stands, the assignee seems too busy or doesn't care about the REST API.

#8 Updated by Bevan Rudge over 6 years ago

  • % Done changed from 0 to 50

This is related or duplicate of #4968 and/or #7402.

It would be great to get this or one of those reviewed and committed.

#9 Updated by Bevan Rudge over 6 years ago

I meant #7819, not #7402.

#10 Updated by Jean-Philippe Lang over 6 years ago

Ewan Makepeace wrote:

Clearly populating menus with the values seen in a small sample of records is no way to be writing a UI but until REST provides enumeration of Status (and other fields) all developers of plugins and desktop software will be similarly stuck.

Populating the menu with all existing statuses that /issue_statues would return is (maybe slightly better but) not the right solution. All statuses are not applicable to all issues.

I think the API should offer a way to retrieve the statuses that a particular issue can be changed to by the user. Something like /issues/:id/edit that would return an xml/json representation of possible statuses and all other properties that can be changed (assignee, priority...).

#11 Updated by Jean-Philippe Lang over 6 years ago

Or maybe a way to include optionnaly all this information in the response to /issues/:id.

#12 Updated by Alex Last over 6 years ago

in some cases I need to retrieve "*what are the available statuses for this issue*",
but sometimes I need to get "*what are all possible statuses in this project*" - that is if I'm building a search form for issues in some application...

#13 Updated by Etienne Massip about 6 years ago

  • Priority changed from Normal to High
  • Target version set to Candidate for next major release

REST-blocking for instances which don't set a default Status.

#14 Updated by Rodrigo Recio about 6 years ago

Why don't you just create a json/xml response for a path like this projects/:project_name/issues/new.json so its response is all current project available trackers and statuses?

#15 Updated by Jean-Philippe Lang about 6 years ago

  • Status changed from New to Closed
  • Target version changed from Candidate for next major release to 1.3.0
  • Resolution set to Fixed

The list of all statuses is now available, see r7878.

Rodrigo Recio wrote:

Why don't you just create a json/xml response for a path like this projects/:project_name/issues/new.json so its response is all current project available trackers and statuses?

Similar to my proposal in note-10. Could you try to design this response so we can get some feedback?

Also available in: Atom PDF