Redmine

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

Bevan Rudge wrote:

It would be great to get this reviewed and committed.

• 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.

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.