Redmine

This should be added part of the individual issue's API. (e.g. /issues/123.xml)

I agree it makes more sense to do it that way, but it means that I'd have to perform 500 individual requests if I load 500 issues in my redmine->MSP importer - which kind of sucks.
maybe the REST API can do SQL join to provide the same info in "issues list" response if some "load_linked_issues_info" parameter is specified in the request?

I'd rather keep the API simple and not add a bunch of non-field options.

What I was thinking about was adding some counter fields to issues. So you can see <related-issues-count>0</related-issues-count> and know you wouldn't need to fetch the main issues' XML. This could also speed up a few other things in Redmine (counter cache)

that would work too.

Relations added to the individual issue XML output in r3729.

Concerning counter cache, remember that it doesn't take care of issue visibilty. If it's 0, we know that there is no related issue. But if it's > 0, we still have to count related issues that are visible to the user.

Eric Davis wrote:

I'd rather keep the API simple and not add a bunch of non-field options.

What I was thinking about was adding some counter fields to issues. So you can see <related-issues-count>0</related-issues-count> and know you wouldn't need to fetch the main issues' XML. This could also speed up a few other things in Redmine (counter cache)

I tried the last trunk version. It provides the related issues list in "issue.xml" - good! would be nice to have that <related-issues-count>0</related-issues-count> added to "issues list" response.
thanks, Eric.

btw, is there a chance to integrate those changes into 0.9 branch so we could get them in the next release (0.9.5)? it looks safe for me, although I'm not a redmine developer, of course.
Alex.

Jean-Philippe Lang wrote:

Concerning counter cache, remember that it doesn't take care of issue visibilty. If it's 0, we know that there is no related issue. But if it's > 0, we still have to count related issues that are visible to the user.

Good point, caching that would be a bad idea.

any plans to allow manipulating relations via REST API (feature #7366)?

+1