Since 3d04e44880 [0], the class `article`
is used instead of `page`. As reports not using `external_layout` does
still manually used `page` class as wrapper, there were not rendered
properly. Force these reports to correctly wrap their content into an
`article` div by using a dedicated template.
Closes#15118
[0] more precisely https://git.io/vM58c
External layout for reports can be customized. 4 Layout are currently
proposed, selectable from General Settings.
An onboarding popup is shown to select the layout to used if none has
been shown nor a company logo chosen.
Joint works by Fabien Pinckaers, Antony Lesuisse and Christophe Simonis.
Design by Csaba Fazekas.
Impacted modules : base, base_setup,
account, report, and base_vat
The purpose is here to ease the creation
of the first invoice. To do so, we need to
ease the configuration of VAT, company data,
and report layouting.
This commits brings
- better labelling for TIN, VAT and Tax Id
for partner and companies (form view, ...)
- change settings for footer of report : allow
to use custom or standart footer, and display them
in settings view.
- always display TIN in standart report footer
- remove (demo) data of main company to not set
company logo on reports
Also, a message is display on the report when the
data company are not configured yet.
The invoice report is now regenerated each time
the user want to print it.
When clicking on the delivery order linked to the SO with a portal user,
a access right error was raised.
1. Due to this record rule: res_partner: portal/public: read access on my commercial
The portal user cannot read the fields of the partner linked to the warehouse of the picking.
The unreadable fields were in external_layout_footer.
2. The portal user is not allowed to read the field barcode on a product.
opw:693238
There is a confusion in name of menuitems 'Reports'. For example whe have a lot of printed reports containing reports (eg. Expenses Reports)
For the 'Analysis' reporting views, we should rename this into 'Reporting'.
A user portal cannot have the read access right on the res partner, except his commercial_partner_id (his partner or the root partner if he got a parent company). That would a big security flaw.
In the header we use the contact widget to print the company information. This widget uses sudo to get all the required fields to display.
But in the footer, we still access some fields like company.fax which is not allowed.
As the contact widget uses sudo to display the company information in the header, we did the same here for the footer.
=======
Purpose
=======
The company form should be heavily simplified. It's complex to have some settings on the company form, and others on the Settings menu of the related app. It would be much easier to have all settings in Settings menu (res.config) and nothing on the company, even if some of the Settings are multi company. (Stored on the company but set from the Settings menu).
Change the external_layout_header, with the use of
span tag and display inline-block property instead
of div tag, because without using it, the address
under-line occupied the whole col-xs-6 block, for
small address also. By using display inline-block
the length of address underline will same as length
of address. And col-xs-6 will increase the address
space for log address lines.
This change concerns reports of `qweb-html` type. Previously, they were
openned in a popup and it was not very practical. We chose to open these
reports in an iframe (as opposed to what's done in `account_report`) in
order to be the most close to the pdf version in terms of apperance.
The client action allows an integration with the control panel. Apart from
the breadcrumbs integration, we also add buttons to handle the web_editor
(save, discard, etc). We also add a button to print the pdf version.
As there is some security concern to communicate with an iframe, we use
the postMessage[1] technology and we fix the `targetOrigin` to the
`web.base.url` parameter, that means that if the window to which we send
the message does not match the `web.base.url` origin, the event is not
even dispatched.
In order to to that, the report module uses the ir_http `session_info`
override mechanism to add the `web.base.url` in the DOM of the webclient,
and the report module adds to the DOM of report the `web.base.url`
content. This way, both scripts (in the webclient and in the iframe)
have the information of the trusted origin.
The client action does not have a complicated logic: it opens the
report's url in an iframe to show the report or open the web_editor
(the editor is activated by using the `enable_editor` query string.
If you click on the control panel button (save/discard) it'll send
message to the web_editor in the iframe to ask for save and discard.
It also waits for messages to know if the edition is done / cancelled
and toggle buttons of the control panel accordingly.
To allow that, we override the web_editor mechanism if it's opened in
an iframe and we chain to the `save` and `cancel` method deferred that
send message to the client action's window. We also make the web_editor
waits for message to start and stop the edition (controlled by the
control panel buttons).
The override of the action manager has been refactored / improved in
order to open the clien action and not the popup anymore. This way
we are able to, in the client action, return the current action with
the type `qweb-pdf` and the report is downloaded.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
session_instance.js moved from framework/ to services/ and renamed into
session.js, which required to change the bundles in report and web_editor
addons.
PURPOSE
=======
I've seen this new improvement regarding the naming of the printed reports:
https://www.odoo.com/web?#id=10870&view_type=form&model=project.task&menu_id=3942&action=327
This makes the report have the pdf name being the name instead of the report_name of
the ir.actions.report.xml, which is already an improvement.
But why don't we allow the users to have their own naming conventions?
I mean, we could allow our client to create and name their pdf the way they want, as
they do regarding the attachment.
Not only when it's about saving it as an attachment on the record, but also when downloading
directly the pdf, such that the modification in the previous screenshot, would give the following
result when downloaded:
People need to have their pdf named automatically according to a convention. When you print 10 sales
order during an hour, you don't want to get lost in having the following:
Devis / Commande.pdf
Devis / Commande(1).pdf
Devis / Commande(2).pdf
Devis / Commande(3).pdf
Devis / Commande(4).pdf
Devis / Commande(5).pdf
Devis / Commande(6).pdf
Devis / Commande(7).pdf
especially when those are for different partners.
Since the website/web_editor split, the mt/mb definitions were not
included in reports anymore. Those were not the only rules that
were forgotten. In 9.0, as a fix, those rules were added back in the
report.css file.
As the assets have been refactored in saas-10, the fix here is to
link the missing file (unique in saas-10) in the report assets.
* Remove recursive assets inclusions (i.e. assets_editor was including
assets_common, summernote, ...)
* Better construct the assets (link, then script + type attribute)
* Better include the assets (split js / css, always use t-call-assets)
* Simplifies the number of assets
* Move bootstrap js to assets common
* assets_frontend is now created by web module to allow using it on the
connexion page but also in the web_editor, where colors have to be
bootstrap/theme ones. Note: if a module depends on website, then keep
using the inherit_id="WEBSITE.assets_frontend"
In some reports,
e.g. the sale order report(report_saleorder),
the browse record is set under `doc` instead of
`o`.
Therefore, when printing a sale order as a user
from another company than the SO company,
the header printed were the one of the user company
instead of the one of the sale order company.
opw-666306
Useless now that rev f26988c allows the use of asset.
Also, it was partly used to retrieve the content of the
`report.style` template that was removed by rev c9492f8.
The preferred way to add local style and stylesheets is to add them
directly in the assets.
Added two dummy reports to print an empty internal and external report
and added direct link to edit header/footers template in the form view
(in technical features) for convenience.
Also moved the 'preview rml report' under the rml configuration and
tried to make the company form as clean as possible but i think it's
failed.
In view inheritance, selecting an element based on the attribute `string` is
broken, since this attribute may be translated before the inheritance is
applied. This fixes existing views to avoid such selections.
This rev. is related to 439cdb6871.
The module datetime was already available in the reports,
and it was the entire datetime module that was imported,
not just the class.
This rev. is not recompatible with 439cdb6871,
but there is no other choice, since other existing
reports might already expected the datetime module
and not the class
opw-640299
In reports calling the internal headers layout,
e.g. the general ledger,
the print time was displayed in UTC,
while it should be in user tz.
closes#3341
opw-612043
This issue is related to the wkhtmltopdf issue
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2083
It seems there is a race condition in the Javascript file
loading in wkhtmltopdf 0.12.x.
The subst.js file put in the header/footer of reports
was not always loaded when the page was being rendered,
leading to the crash of the onload="subst()" attr in
the body node, leading to the non-rendering
of the header/footer.
Replacing the script file by its content solves
the issue.
Increasing the --javascript-delay of the wkhtmltopdf
executable (e.g. 1000 ms instead of 200 ms,
the default value) seems to solve the problem
as well, but will lead to obvious performance issues.
We therefore choose to put the javascript code inline,
as a workaround,
the time the issue is solved in wkhtmltopdf, at least.
closes #3047,#5548,#6207
opw-633161
When having a long, non-breakable, content
within a report column,
e.g. an invoice with a very long, pipe-separated, origin,
the content overflowed on other columns.
Set word-wrap: break-word; prevent this behavior,
and is not considered dangerous regarding the possible
side-effects on the design in the reports layouts.
In fact, we should even consider applying this change
on the webclient itself. A similar issue happens in the form view
when having a field with a long non-breakable content,
e.g. a long, pipe-separated orign in an invoice. Nevertheless,
we should avoid taking risks in stable releases,
and this change in the webclient should therefore be done
carefully in master release.
opw-629352
qsm-odoo