Defect #7819
open
REST API Populating issue field enumerations + Issue list filters
50%
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
Related issues
Updated by Rodrigo Recio over 13 years ago
- File restadditions.diff restadditions.diff added
This patch contains additions that lists issue statuses and trackers.
It does exposes assignable users and versions inside the issue.
Updated by Bevan Rudge over 13 years ago
- % Done changed from 0 to 50
It would be great to get this reviewed and committed.
Updated by Bevan Rudge over 13 years ago
Updated by Jean-Philippe Lang over 13 years ago
Bevan Rudge wrote:
Quick review:It would be great to get this reviewed and committed.
- your patch makes the tracker and status lists accessible to administrators only
- no tests
Updated by Etienne Massip over 13 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) ?
Updated by Jean-Philippe Lang over 13 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.
Updated by Etienne Massip over 13 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?
Updated by Jean-Philippe Lang over 13 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?
Updated by Etienne Massip over 13 years ago
Jean-Philippe Lang wrote:
Users with a
view_issuespermission 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.
Updated by Jean-Philippe Lang over 13 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
403with/issues_statusesand 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 :-)
Updated by Etienne Massip over 13 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
403with/issues_statusesand 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
Updated by Etienne Massip over 13 years ago
- Target version set to Candidate for next major release
Updated by Alex Last about 13 years ago
I think this should be moved to version 1.3.0
Updated by Jaap de Haan over 11 years ago
Relates to the newer ticket #11159, asking for the implementation of export of custom fields information.
Updated by Toshi MARUYAMA over 11 years ago
- Related to Feature #11159: REST API for getting CustomField definitions added