Defect #7819

REST API Populating issue field enumerations + Issue list filters

Added by Orcun Gok over 6 years ago. Updated almost 4 years ago.

Status:NewStart date:2011-03-09
Priority:NormalDue date:
Assignee:-% Done:

50%

Category:REST API
Target version:Candidate for next major release
Resolution: Affected version:

Description

Our team have been using Redmine for more than two years. We are very happy with Redmine and we have decided to develop small visual studio add-in for Redmine in order to improve our productivity and give something back to the Redmine community.

Before beginning the development we have started investigating REST API and found some subjects that needs improvements.

The biggest problem that we have found is; REST API does not provide necessary functionality for populating issue property/attribute enumerations.

In order to provide useful GUI with bunch of combo boxes. We have to populate;
  • List of trackers (we can right now)
  • List of categories
  • List of statuses and their transition information
  • List of priorities
  • List of versions
  • List of custom fields of trackers and their meta information

If we can not populate these enumerations a proper issue editor GUI can not be developed. However, we can populate these fields from issue lists but if a enumeration is not set in any issue it wont be displayed.

In addition to these, to improve responsiveness and usability we have to filter issue list by using;
  • Assignee
  • Status
  • Priority
  • Category
  • Tracker
  • Start & End Date
  • Affected Version
  • Done

It can be done client side but it will reduce usability dramatically in big projects with 1000+ issues.

In our point of view, these requirements are necessary in order to develop various front ends for Redmine.

Best regards.

restadditions.diff Magnifier (4.05 KB) Rodrigo Recio, 2011-03-29 00:34


Related issues

Related to Redmine - Feature #7180: List of statuses in REST API Closed 2010-12-27
Related to Redmine - Feature #7402: REST API - Enumerations New 2011-01-21
Related to Redmine - Feature #11159: REST API for getting CustomField definitions Closed

History

#1 Updated by Rodrigo Recio over 6 years ago

This patch contains additions that lists issue statuses and trackers.
It does exposes assignable users and versions inside the issue.

#2 Updated by Bevan Rudge about 6 years ago

  • % Done changed from 0 to 50

It would be great to get this reviewed and committed.

#3 Updated by Bevan Rudge about 6 years ago

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

#4 Updated by Jean-Philippe Lang almost 6 years ago

Bevan Rudge wrote:

It would be great to get this reviewed and committed.

Quick review:
  • your patch makes the tracker and status lists accessible to administrators only
  • no tests

#5 Updated by Etienne Massip almost 6 years ago

Jean-Philippe Lang wrote:

  • your patch makes the tracker and status lists accessible to administrators only

Actually, lists are already accessible to administrators only (in admin screens) ?

#6 Updated by Jean-Philippe Lang almost 6 years ago

Indeed. But if the goal is to let users retrieve trackers and statuses in order to fill an issue form or set filters, it doesn't work.

#7 Updated by Etienne Massip almost 6 years ago

Sure. But it would be illogical to give read-only access to these lists by API and not by application screens, wouldn't it be?

I mean, to keep some consistency, this might be the concern of a second patch which would add a new read access to referential data permission which would also allow direct access to application screens via URLs like /issue_statuses?

#8 Updated by Jean-Philippe Lang almost 6 years ago

Etienne Massip wrote:

Sure. But it would be illogical to give read-only access to these lists by API and not by application screens, wouldn't it be?

Not so illogical if you consider that, unlike API users, web users do not need to access a simple read-only view of trackers or statuses.

I mean, to keep some consistency, this might be the concern of a second patch which would add a new read access to referential data permission which would also allow direct access to application screens via URLs like /issue_statuses?

Users with a view_issues permission already have access to ids/names of all trackers and statuses at /issues (look at the filters). Having a permission to give access to a different representation of the same information is far from ideal.

I think that /trackers and /statuses should be open to API calls by non-admin. But what would be the point to have an html view other than for admins?

#9 Updated by Etienne Massip almost 6 years ago

Jean-Philippe Lang wrote:

Users with a view_issues permission already have access to ids/names of all trackers and statuses at /issues (look at the filters). Having a permission to give access to a different representation of the same information is far from ideal.

Except that they can view issues of visible projects only, that's not exactly the same representation.

I think that /trackers and /statuses should be open to API calls by non-admin. But what would be the point to have an html view other than for admins?

I guess no point, you're right. I was just wondering if it was logical to get a 403 with /issues_statuses and the full issue statuses list with /issues_statuses.xml. That somewhat means handling rights depending upon required format.

Anyway, I'm discussing something that is not very useful, I agree with that.

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

Etienne Massip wrote:

Except that they can view issues of visible projects only, that's not exactly the same representation.

Not matter which issues or projects they can see, they can always see the list of all statuses and trackers in the filters.

I guess no point, you're right. I was just wondering if it was logical to get a 403 with /issues_statuses and the full issue statuses list with /issues_statuses.xml. That somewhat means handling rights depending upon required format.

Maybe a 406 would be more appropriate :-)

#11 Updated by Etienne Massip almost 6 years ago

Jean-Philippe Lang wrote:

Not matter which issues or projects they can see, they can always see the list of all statuses and trackers in the filters.

Oh, sorry, I thought they could only see statuses used in workflows tied to trackers of the project.

I guess no point, you're right. I was just wondering if it was logical to get a 403 with /issues_statuses and the full issue statuses list with /issues_statuses.xml. That somewhat means handling rights depending upon required format.

Maybe a 406 would be more appropriate :-)

405 ? :o

#12 Updated by Etienne Massip almost 6 years ago

Not 405, 406 is right.

#13 Updated by Etienne Massip almost 6 years ago

  • Target version set to Candidate for next major release

Pushed for complement of #7180 and #7402 for custom fields.

#14 Updated by Alex Last over 5 years ago

I think this should be moved to version 1.3.0

#15 Updated by Jaap de Haan almost 4 years ago

Relates to the newer ticket #11159, asking for the implementation of export of custom fields information.

#16 Updated by Toshi MARUYAMA almost 4 years ago

  • Related to Feature #11159: REST API for getting CustomField definitions added

Also available in: Atom PDF