report_sxw: wrong pageCount and pageNumber when attachments are not kept

Hello Xavier ALT,

Can you explain me in more in detail ?
Because i cannot understand in following statement:
2. Find a record with lot of invoice line (invoice must be draft,
otherwise report_sxw with force report per record and for all group)
3. Now select 5 invoices (but 1st invoice should be the record choosen
at step "2", other invoices must be draft too).

Can you attach the report pdf ?
Thanks.

I can confirm that putting <pageNumberReset/> just before the </story> resets the page count in a wrong way. I've just tried this on a custom report of ours.
The patch attached by Xavier ALT (AJM) seems to fix this problem.
To illustrate the misbehavior, Xavier was suggesting you print a report with at least 1 invoice spanning several pages, and watch the pagecount go wrong.
Lionel

Hello Lionel and Xavier,

I have printed 3 invoices worth 5 pages.

The Pages were like:
-- page 1-- -- page 2-- -- page 1-- -- page 1-- -- page 2--
--Invoice1- ---Invoice1-- --Invoice2----Invoice3----Invoice3--

It is working pretty normal.

Kindly make the problem clear that you want Paging Object-wse or documnet wise?
i.e. it should go like as I mentioned or as like page 1 2 3 4 5 ?

Thanks.

Jay, I just tried with the standard v5.0.7 and it works indeed. What I don't understand yet is why it doesn't work on my developpment branch, where i've merged everything up to 5.0.7...

Oh sorry, I just clicked on.

First, about the page numbering, you will notice that the behavior is not the same on invoices and sale orders - that's why I added a <pageNumberReset/> in the first place.
Invoices are numbered like you said, but orders are numbered as :
-- page 1/5-- -- page 2/5-- -- page 3/5-- -- page 4/5-- -- page 5/5--
--order1- ---order1-- --order2----order3----order3--
Maybe it's due to the fact that order PDF's are not kept as attachements? - I didn't check this yet.

Now to the main issue: Jay you're right, it works fine as long as you *don't* "Add <pageNumberReset/> just before the </story> tag", which is what Xavier and I did. If ever you do, then the page count will be wrong.
So basically I think the <pageNumberReset/> tag is broken (which may not be such a big deal after all).

Lionel

Sorry - by "which may not be such a big deal after all" I meant: if we can get the orders to have page numbers like the invoices.

Well Yes Lionel,

I need to figure out why the orders have no similar behaviour?

Thanks.

Hello Guys,

Sale Order Report behave differently , it's due to the fact that order PDF's are not kept as attachements.

It reloads the reporting process object-wise.

Thanks.

Jay (Open ERP) a écrit :
> Hello Guys,
>
> Sale Order Report behave differently , it's due to the fact that order
> PDF's are not kept as attachements.
>
> It reloads the reporting process object-wise.
>
> Thanks.
>
>
Yes, I just tried and I confirm that if you keep attachments, the page
numbering is right.
Lionel.

My humble opinion about this issue is:
- </story> should implicitly do a page number reset: it will give a uniform behavior not matter whether attachements are kept or not, and it will solve Bug #546918
- <pageNumberReset> should be fixed, so that we can use it in special cases when we really want to reset the page number in the middle of a story. For example, if I want to print a letter along with each invoice, I want both to based on the same object and be numbered 1/1.
Lionel.

duplicate of itself.

What do you mean with "duplicate of itself" ?
Lionel

Just To avoid the listing of bug under the same milestone.
Thanks.

I made an attempt at fixing this, and push my changes to lp:~numerigraphe/openobject-server/5.0-bug516966-wrong-pageCount-pageNumber.
Xavier ALT (AJM) could you please test this branch and comment on the merge proposal?
Lionel

My fix is not correct yet, I'll give it another try and let you know.
Lionel

I think it's better now. I'll submit the merge proposal again.
Lionel

Hello,

This issue has now been fixed in the development trunk of OpenERP.

Thanks.

Hello,

I'm re-opening this bug as confirmed because on latest trunk the <pageCount/> is always 0 (ZERO). (using "external" header and with <pageCount/> in coporate header).

Actually I've check the trunk code, and a didn't see any merge of the work of Numerigraphe.

Can someone confirm this bug still exist?

Re,

On standard installation <pageCount/> in not present in the "external" coporate header so bug not visible. If we add <pageCount/> inside it will always be 0 whatever the real number of pages.

See patch attached for a "one line" fix :)

Xavier's patch use _pageCount instead of _pageNumber works just fine...

I just check the openerp trunk and this bug is still un fixed..

josepato,

Why did you change from 'confirmed' to 'incomplete'?

'confirmed' means that this bug report is still in the loop.
'incomplete' means we are waiting for more information from the original person who did post the bug report.

Actually here, we are working on it, and we forgot to put it to 'in progress'.

Please don't change bug reports meta information such as its status unwisely, thanks.

Hello,

Thanks for reporting.

It has been fixed in lp:~openerp-dev/openobject-server/trunk-bug-516966-ysa.
Revision No:- 3426
Revision ID: <email address hidden> and It will be merged soon
in trunk server.

Thanks,

"It will be merged soon"

Does soon means 6 monthes? Are you kidding?

Fix it now! Thanks

I placed a patch for the version revison
lp:~openerp/openobject-server/6.1/
revision 4158