project.issues does not return all issues about python-redmine

[maxtepkeev]

Hi,

Not exactly, see:

>>> len(redmine.project.get('foobar').issues)
464

>>> len(redmine.issue.filter(project_id='foobar'))
464

>>> len(redmine.issue.filter(project_id='foobar', status_id='open'))
464

>>> len(redmine.issue.filter(project_id='foobar', status_id='closed'))
1243

>>> len(redmine.issue.filter(project_id='foobar', status_id='*'))
1707

So yes, the default behaviour is to return all open issues, absolutely no limiting comes into play unless you ask for it via object slicing syntax, i.e.:

>>> len(redmine.project.get('foobar').issues[:105])
105

[idokasher]

Some more details:
python 3.1.2 is used.

The kwargs dict in Redmine.request seems to hold the right values.
However, the response received from the redmine server has limit set at 25 (instead of 100 and the desired offset).

kwargs just before calling: response = getattr(requests, method)(url, **kwargs).
{'verify': False, 'params': {'project_id': 1, 'limit': 100, 'offset': 0}, 'data': {}, 'auth': ('my_user', 'my_pass'), 'headers': {}}

[maxtepkeev]

Hi!

I can't reproduce it here. Are you using a real Redmine or some fork like ChiliProject ? I'm asking because the problem you described exists exactly in ChiliProject fork.

If you are using a real Redmine, can you also reproduce this problem if you issue a raw request to the API through your browser directly, like http://your-redmine-url/projects/your-project/issues.json?limit=100

Does it return 100 issues or also 25 ?

[idokasher]

Hey,

I think we use a real Redmine. Can check with our IT guys.
I have made the following change to the code of the request method in the
Redmine class to include the request directly in the URL.
This seems to have bypassed the problem.

def request(self, method, url, headers=None, params=None, data=None):
    """Makes requests to Redmine and returns result in json format"""
    kwargs = dict(self.requests, **{
        'headers': headers or {},
        'params': {},
        # 'params': params or {},
        'data': data or {},
    })

...

    if (params):
        url += "?"
        url += "&".join("%s=%s" % (key, val) for key, val in

params.items())
response = getattr(requests, method)(url, **kwargs)

On Tue, Sep 2, 2014 at 12:57 PM, Max Tepkeev [email protected]
wrote:

Hi!

I can't reproduce it here. Are you using a real Redmine or some fork like
ChiliProject ? I'm asking because the problem you described exists exactly
in ChiliProject fork.

If you are using a real Redmine, can you also reproduce this problem if
you issue a raw request to the API through your browser directly, like
http://your-redmine-url/projects/your-project/issues.json?limit=100

Does it return 100 issues or also 25 ?

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[maxtepkeev]

Hmm... So it looks like it is the requests module that is giving you this problem, what requests version do you use ?

[idokasher]

2.3.0

On Wed, Sep 3, 2014 at 9:51 AM, Max Tepkeev [email protected]
wrote:

Hmm... So it looks like it is the requests module that is giving you this
problem, what requests version do you use ?

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[maxtepkeev]

I did some more testing and now I think it is not connected with the requests module. I believe it is a bug in the Python 3.1.2 itself, because I managed to reproduce this problem with it, but have no idea where it is coming from. I also tried the latest version from 3.1 branch (3.1.5) and it doesn't have this problem anymore.

Also neither python-redmine nor requests doesn't officially support Python 3.1 branch so there won't be a fix for this from me because it is not the type of bug I can fix (it is not even in my code and looks like it is not in the requests code either). I can only recommend you to upgrade at least to Python 3.1.5, or if you can to Python 3.2 or higher.

[idokasher]

Sure.

Thanks for looking into it.

On Wed, Sep 3, 2014 at 10:55 AM, Max Tepkeev [email protected]
wrote:

I did some more testing and now I think it is not connected with the
requests module. I believe it is a bug in the Python 3.1.2 itself, because
I managed to reproduce this problem with it, but have no idea where it is
coming from. I also tried the latest version from 3.1 branch (3.1.5) and it
doesn't have this problem anymore.

Also neither python-redmine nor requests doesn't officially support Python
3.1 branch so there won't be a fix for this from me because it is not the
type of bug I can fix (it is not even in my code and looks like it is not
in the requests code either). I can only recommend you to upgrade at least
to Python 3.1.5, or if you can to Python 3.2 or higher.

—
Reply to this email directly or view it on GitHub
#45 (comment)
.

[maxtepkeev]

You're welcome.

Also, if for some reason it is impossible for you to upgrade your Python version, you can create your own Redmine class and inherit it from the Redmine class, redefine the request method and use the fix you provided if it works for you.

[bellefab]

I use Redmine 2.5.3 and it seems that a code like this :

project = redmine.project.get("my_proj")
issues = project.issues

returns the set of 'open' issues in the limit of 100 elements.
As is I was using
redmine.issue.filter(project_id="my_proj",
status_id="*", limit=100)

The messages in the log files seem to say the same thing.
Is that true ?
Is it possible to update the documentation to explicit the 'project.issues' behavior ? I think it is a bit confusing without doc.

Thanks

[bellefab]

Humm ... ok, I see.

My problem was that when I used

>>> redmine.project.get('foobar').issues

I though I will get the whole set of issues but I get only the 'open' ones.
That is why I think a comment in the documentation would be helpful.

Anyway, thanks for the quick answer.
And thanks for python-redmine :)

[maxtepkeev]

Returning only open issues is the default behaviour of Redmine API itself, but I can add a note in the documentation of course.