Pagination variables are temporarly shared betweens user sessions in ReportModule

[farialima@…]

[6901] has added pagination handling for report. From looking at the code, it adds data attributes ('page', 'limit', 'num_rows', as well as 'asc', 'sort', 'USER') to the class "ReportModule" (see source:/trunk/trac/ticket/report.py@6901#L25​ ) . But, AFAIK, only one instance of each "Component" class (of which ReportModule inherits) is shared across all user requests, so I believe that these attributes will be shared across users. Or maybe I'm reading the code wrong…

The risk is low, but unpredictable: it will be a problem when two users request a (different) report at the same time; in that case, the result will be unpredictable.

It also makes it impossible to use the ReportModule.execute_report without first settings the 'limit' attribute (which is why I caught this issue: I had some automated tests that would call execute_report and that suddenly started failing…)

Why not instead add an optional parameter to execute_report instead, that would contain (and return, as attributes) the pagination information ?

I can propose a patch if you want,

Again, maybe I'm wrong and not reading the code correctly…

[francois@…]

the code is actually on line source:/trunk/trac/ticket/report.py@6901#L293​, not 25 as I wrote above

[Christian Boos]

Oh, you're completely right, this has been overlooked when cleaning up the #216 patch.

[Christian Boos]

([OT] looks like we also have a problem with eating up the blank lines of a ticket description, as the (diff) above happened without any expliciting editing from my part)

[Christian Boos]

Should fix the scoping issues for report pagination

[Christian Boos]

The patch above should fix the issue and apparently doesn't break things - but more tests are welcomed.

[Christian Boos]

Patch checked in as r7212 for 0.11 and as part of r7214 for 0.12.