When creating reports with barcode labels, there is simply no space
for excessive quiescence zones. Let's give control of layout to the
report template, not to the barcode renderer.
Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
t-att-src="'/report/barcode/?type=%s&value=%s&width=%s&height=%s'
% ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``
This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.
When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.
This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.
Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).
Fixes#10621
opw-667797
It looks like reportlab doesn't handle well
UPC-A barcodes.
As UPC-A barcodes became EAN13 barcodes when
adding a `0` to the beginning of the barcode,
and the render is the same, we ask reportlab
a EAN13 barcode type when a UPC-A barcode is asked,
making sure to add the `0` automatically first.
From Wikipedia:
```
The EAN was developed as a superset of UPC,
adding an extra digit to the beginning of every UPC number.
[...]
the original rules for UPC are treated as a '0'
if read as EAN-13.
A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX.
It is possible to prefix a UPC barcode with a 0;
they become EAN-13 rather than UPC-A.
This does not change the check digit.
All point-of-sale systems can now understand both equally.
```
opw-670560
session.get_file appends the json to the body of the generated iframe and
then tries to json.parse it by reading contentNode on the body.
Exceptions from `report_download` method may contain `<` and `>`, so when
json.parse tries to json.parse the contentNode, it reads only a part of
the original json string. htmlescaping the json string solves the issue
by preventing the content of the json string to be interpreted as html.
There's a little magic inside the website enabled route modifying the
context's lang, thus breaking the logic to print the report in the
current user's lang. The direct route to display the report should
stay in website_enabled mode, as it allows to switch lang, use the
website translator and so on.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
[REM] dead code: pos_box_entries.py/xml, pos_box_out.py/xml, pos_return_view.py/xml
[ADD] lines, invoice, cashbox of the day, payment, receipt, users product reports converted to QWeb. Added YML tests for the bank statement reports.
[FIX] closed cashbox of the day sql using old fields in its queries, yml test not correctly generating an invoice from a pos order
bzr revid: sle@openerp.com-20140414104954-xj10wi640tyr3ufe