Project

General

Profile

Actions

Defect #7819

open

REST API Populating issue field enumerations + Issue list filters

Added by Orcun Gok about 13 years ago. Updated over 10 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
REST API
Start date:
2011-03-09
Due date:
% Done:

50%

Estimated time:
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.


Files

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

Related issues

Related to Redmine - Feature #7180: List of statuses in REST APIClosedJean-Philippe Lang2010-12-27

Actions
Related to Redmine - Feature #7402: REST API - EnumerationsNew2011-01-21

Actions
Related to Redmine - Feature #11159: REST API for getting CustomField definitionsClosedJean-Philippe Lang

Actions
Actions #1

Updated by Rodrigo Recio almost 13 years ago

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

Actions #2

Updated by Bevan Rudge almost 13 years ago

  • % Done changed from 0 to 50

It would be great to get this reviewed and committed.

Actions #3

Updated by Bevan Rudge almost 13 years ago

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

Actions #4

Updated by Jean-Philippe Lang over 12 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
Actions #5

Updated by Etienne Massip over 12 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) ?

Actions #6

Updated by Jean-Philippe Lang over 12 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.

Actions #7

Updated by Etienne Massip over 12 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?

Actions #8

Updated by Jean-Philippe Lang over 12 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?

Actions #9

Updated by Etienne Massip over 12 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.

Actions #10

Updated by Jean-Philippe Lang over 12 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 :-)

Actions #11

Updated by Etienne Massip over 12 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

Actions #12

Updated by Etienne Massip over 12 years ago

Not 405, 406 is right.

Actions #13

Updated by Etienne Massip over 12 years ago

  • Target version set to Candidate for next major release

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

Actions #14

Updated by Alex Last over 12 years ago

I think this should be moved to version 1.3.0

Actions #15

Updated by Jaap de Haan over 10 years ago

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

Actions #16

Updated by Toshi MARUYAMA over 10 years ago

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

Also available in: Atom PDF