Vote #69433
未完了REST API Populating issue field enumerations + Issue list filters
50%
説明
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.
journals
This patch contains additions that lists issue statuses and trackers.
It does exposes assignable users and versions inside the issue.
--------------------------------------------------------------------------------
It would be great to get this reviewed and committed.
--------------------------------------------------------------------------------
This is related or duplicate of #7180 and/or #4968.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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) ?
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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@?
--------------------------------------------------------------------------------
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?
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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 :-)
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
Not 405, 406 is right.
--------------------------------------------------------------------------------
Pushed for complement of #7180 and #7402 for custom fields.
--------------------------------------------------------------------------------
I think this should be moved to version 1.3.0
--------------------------------------------------------------------------------
Relates to the newer ticket #11159, asking for the implementation of export of custom fields information.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
related_issues
relates,Closed,7180,List of statuses in REST API
relates,New,7402,REST API - Enumerations
relates,Closed,11159,REST API for getting CustomField definitions