Issue
- Install "Contacts" and "Studio" modules
- Go to "Contacts" and switch to Studio
- Go to "Reports" tab
- Create a new report
- Select "External" layout
Header and footer are missing on report.
Cause
Header is displayed if 'company' has a value.
However, here, we only check if 'company_id' is available
in current record fields, not checking if also set.
Solution
Check that 'company_id' is set on current record, else,
fallback on 'res_company'.
opw-2443234
closesodoo/odoo#65210
X-original-commit: 7c4510042ec35a7da10741595a4da56c3b3c4cdf
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closesodoo/odoo#56995
X-original-commit: c121a246f16899735306266a3a12b526e08e7620
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
when user create a report using basic layout and at download time, it gives warning that
the template doesn't contain the attributes 'data-oe-model' and 'data-oe-id' on
the div with the 'article class name so this issue is fixed in this commit.
closesodoo/odoo#56511
X-original-commit: c58400a1d27f0994a620108af476813bf654e879
Related: odoo/enterprise#12658
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
QR-BILL report has no margin so we can position things exactly where
they needs to be according to standard.
For example the form must stick at the bottom and have 100% width, so we
can't use paperformat margin that would not allow to have 100% width.
With this change, we set default padding on header so it match
better "European A4" paperformat (that has 5mm top margin and 7mm right
and left margin) for stylistic purpose.
This is currently not configurable so for custom header size still need
view editing to change current values, but this at least make the
edition easy.
opw-2267041
closes#54717closesodoo/odoo#54725
X-original-commit: b758a02ae50fa13f090190accce1fa6d1dbde7d2
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 13.0, the current company selected in the company switcher can be
different than self.env.user.company_id value.
Wizard "Configure Document Layout" (model base.document.layout) is using
the company in company switcher:
```
company_id = fields.Many2one(
'res.company', default=lambda self: self.env.company, required=True)
```
But the "Preview Document" button is using user company_id, so if you
change the layout then preview, you may see the report layout of another
company which make it seemed broken.
note: also improve code of point of sale added in 59f5e57 (in case of
point of sale, company maybe should be point of sale company but you can
print several ones and the company used on point of sales is the one of
company switcher).
opw-2269849
closes#53712closesodoo/odoo#53730
X-original-commit: bbb45e3412a5653d78aacc92903e95d1353ed60a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, the company address was aligned to the left in a column.
closesodoo/odoo#51626
Taskid: 2198488
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Avoid messing up with style by translating it
closesodoo/odoo#50251
X-original-commit: 6151757a8357693e189ff1ab31ece5efdbac65d6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In 10.0 having a `section`, `subsection` or `subsubsection` on a footer
element would replace the content with the page top three level of
headings.
This was removed in 11.0 with b446930dc after which only `page` (current
page number) and `pages` (total number of page) classes would work.
This commit reintroduces the above-mentionned classes.
opw-2226700
closesodoo/odoo#48888
X-original-commit: 14c6b947ecf222524a577ec6a40d4a6e283aa2ad
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Before this commit, the company specific colors and font were
implemented by systematically overwriting a "virtual" report SCSS
asset file before rendering each report.
This caused many issues, forced frequent asset bundles recomputations
(performance problem + cache invalidation causing random bugs).
And it could simply not work in a multi-company setup where multiple
styles are involved, as the asset management could be made not
thread-safe.
PR #44225 was a first attempt to mitigate the numerous problems by
making the asset bundle invalidation less frequent. But the problems
were still present and a more complete solution was necessary for
multi-company setups.
Besides, the design of the bundle forbade making company specific assets.
This commit uses a different approach: instead of having a
company-specific asset that needs to be constantly updated, a global
"multi-company" asset is maintained and included in the report assets.
It only needs to be generated when a company style changes, not for
every rendering operation.
Unfortunately this change cannot be fully performed without updating the
template declarations, so it will require an update of the `web` (or
`base`) module to be operational.
As this represents a rather invasive change in a stable branch, extensive
testing was conducted to minimize the effects and ensure proper
degradation of features for production deployments where the new code
would be deployed without forcing an update of the `web` module:
- The report SCSS files were left untouched, to prevent any bundle
invalidation, ensuring that old cached assets would remain valid. This
means that single-company setups should not see any visible difference
after pulling the code (with or without updating `web`).
SCSS cleanup will be done later.
- Existing Python methods were kept but emptied, to make sure that
old templates and code would not crash.
- For multi-companies, the last used colors will be applied for all
reports until the `web` module is updated. The old behavior was not
working correctly anyways, so the degradation is actually limited.
- For all setups, changing the colors after deploying this patch will
have no effect unless the `web` module is updated.
/UPDATED FOR master on top of #44393/:
- removed the `res_company.update_scss()` method entirely
- fixed the report SCSS styles, as the variable names referred to the old
behavior, e.g. "$o-company-primary-color" is nonsense.
Renamed to "$o-default-report-primary-color" etc.
--
Improves #44225
Forward of #44393
opw-2168623
opw-2171040
closesodoo/odoo#46647
X-original-commit: a5b1421aecf27b1de408434d3bb6d7ac81f57dc3
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Purpose of the task is to reduce the content of the footer by
removing the phone, email, website labels as those are implicit.
In this commit,
-Removed 'Phone:', 'Email:', and 'Web:' in web.external_layout_standard
-Removed 'Tel:', 'Mail:' and 'Web:' in web.external_layout_boxed
Task-1942363
closes odoo/odoo#43381
Closes: #43381
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 4d64e553b8 introduced an 'mt-3' in the address layout of the
external background layout to fix a problem related to the display of
phone numbers.
That fix introduced an error with the pingen external post service. It
requires the area where the destination address is printed to be blank,
due to the mt-3, the background image was visible instead of that blank
area.
As removing solely the mt-3 doesn't break the first problem and solve
the second, it is safe to remove it.
Before this commit, no message was logged to help finding out why the
test was failing.
The `requests.raise_for_status` method raises an error on both 400 and
500 status code. We don't want the test to break in case pingen screw
up their side so 500 errors are just logged. 400 errors still raise an
exception.
closesodoo/odoo#36504
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- This commit fixes invoice reports header and footer:
The header was half displayed and "Phone Number" was
displayed on two lines
- This commit also add a link in report preview to go back
to the backend:
When account was the only module installed there was no
link to go back to the backend
task-2032586
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Commit 42530b02fe was fixing a bug in reports that were using the standard
bootstrap fonts instead of the changes we made in $font-family-sans-serif
To solve this, 42530b02fe replicated the change in the file
web_editor/static/src/scss/bootstrap_overridden.scss
which is imported in report_assets_common **before** web._assets_bootstrap
This was solving the issue for the report but had also the side-effect of
changing body font-family in enterprise as the bootstrap_overridden.scss file
is also used in web_editor._assets_backend_helpers and
web_editor._assets_frontend_helpers
42530b02fe had effect only on enterprise where the desired font is Roboto/Noto
Create a new bootstrap_overridden (6th of the name) file only for report
closesodoo/odoo#32902
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* im_livechat, survey, website_forum
When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).
This PR also questioned several other similar issues which will be
handled later like:
- website should maybe not depends on portal but only on http_routing
- part of portal should be moved to http_routing and http_routing
should be renamed (especially for frontend layouts, etc) so that apps
like survey can reuse some common code
Part of https://github.com/odoo/odoo/pull/29442
task-1932066
Following revision 61eef73b52
the fallback to the standard external layout when
the external layout is not set on the company has been removed.
It therefore leaded to the raise of the exception
```
The report's template '%s' is wrong, please contact your administrator.
Can not separate file to save as attachment because the report's template
does not contains the attributes 'data-oe-model' and 'data-oe-id'
on the div with 'article' classname.") % self.name)
```
when the external layout was not set,
which could happen quite easily in a multi-company environment,
if you do not set the company external layout after having created it.
This revision simply puts back the fallback as it was before.
opw-1931195
closesodoo/odoo#30687
Following 4a3fd02af4 on the portal when displaying an invoice we may get
a report_type variable (with value 'html' or 'pdf') on the portal.
This was used to not display the page number when checking the report,
but when the report is printed in the backend this report_type was unset
so the page number was mistakenly removed too.
With this changeset, the report alway know if he is pdf, html or text
and only print the page number if it is of type pdf.
opw-1924729
closes#30095
In case you are printing in html a report with minimal layout, you will have an error
since the function is not defined, but called by the onload of the body tag.
Now we don't call subst if it is not needed (and so not declared)
closesodoo/odoo#29341
This assets has a lot of JS that is loaded by wkhtmltopdf without any reasons.
Wkhtmltopdf don't like long js to load (it is why subst has been write inline)
This commit allow to print again (on slowly server) several documents in the
same pdf. Before this commit, the JS was not loaded before the default js-delay
and so the subst function never called with as result a pdf of only 1 page.
After this commit you can again print several documents in the same pdf and
subst function is applied.
opw-1909000
courtesy of @beledouxdenis that help to debug this error since it is only
reproductible on paas server.
This commit follow the same logic that commit odoo/odoo@3c61ee5
And issue wkhtmltopdf/wkhtmltopdf#2083 is not yet fixed
* survey, website_slides
While not changing their name or their amount, this commit reorganizes
the assets helpers to:
Avoid all file duplicates in different helpers
----------------------------------------------
Before, we had to put some files in different helpers, like our
bootstrap mixin overrides which were in the _assets_utils template and
in the _assets_bootstrap template.
Enforce the use of an helper when using bootstrap
-------------------------------------------------
Bootstrap functions, variables and mixins are now out of the
_assets_bootstrap template, which now only contains bootstrap css rules
and our bootstrap fixes and extensions.
Allow using the correct bootstrap utils in all assets
-----------------------------------------------------
In some assets (especially editor ones), we may want to use bootstrap
variables even though bootstrap is not included in those. This worked
before but using *default* bootstrap variables. Now, our overrides can
be properly included if necessary.
Note: this commit may also be a first step to allow for backend
bootstrap and frontend bootstrap to co-exist.
closesodoo/odoo#28204
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
Currently, the RTL/LTR direction of a report is the language direction
of the current user printing the report.
So for example a customer invoice in french can be RTL and a customer
invoice in arabic can be LTR.
With this changeset we keep a reference to the body language and use it
to choose direction later on.
opw-1890833
closes#27878
- Add a method for generating an image data URI, and expose it in QWeb context
- Fix reports, website templates or mail templates with data hardcoded
data URIs, to use the helper (Python cases), or the existing
kanban_image helper (for JS cases)
This will gracefully handle SVG support in addition to classical image
formats.
Closes#26635
In order to ease the integration with the snailmail posting service provider,
We will generate specific reports with a layout that fits their
criteria.
In short,
* we specify the postition of the recipient's address on the
document
* we force the A4 format
This also support the din5008 type B report.
Reverting some changes introduced in
f29df7fb2e.
By changing the html tag from 'article' to 'page' we were losing the
style on the body of the document. The problem it was supposed to tackle
will be addresed in the future.
a7a89f3174 introduced a change that broke the invoice iframe.
The #wrapwrap corresponds to the client body, therefore the container must be inside it, and the scrollbar will now be on it instead of on the iframe body.
PR: #26801
task-1876864
The <!DOCTYPE> declaration must be the very first thing in an HTML
document, otherwise you may experience that the preference is given
to the "user agent stylesheet".
This is the case while printing PDF reports using the 'minimal_layout' template.
For example, layout for 'Picking Operation' report will be different in HTML and
and PDF reports. Text inside <th> will be aligned left in the HTML report, while
center in the PDF one. The issue is there since a long time, but was not obvious
enough to catch till now. (For example, in previous BS versions, explicit rule
was present to align text to the left inside <th> tag, and so the layout did not
break by luck. BSv4 afterwards, this rule was removed, shedding light on this
issue).
This commit improves the behavior while printing PDF reports by placing
<!DOCTYPE> declraration at the very beginning so that preference will be
given to custom stylesheet over "user agent stylesheet".
Task: 1880709
Closes#26846
A new exception has been added to detect inconsistent reports. However, many are not structured as expected. Thus, the change consists mainly of checking only when the print has to be separated in part to attach it to the respective documents.
We now take the page tag instead of the article, because the article tag is in the layout, so to separate the file, the t-call had to be inside the t-foreach (for the separation) and so possibly read the assets several times. Since all templates have the first tag (in the t-foreach) tag page, the choice is more sensible.
The javascripts files used in readonly were taken out of the editing assets.
A turn was made but not activated, it works locally, but on the runbot, an error is triggered when generating assets after choosing the settings.
The goal of this commit is to fix the various views and reports of sales and invoices.
======
Portal
======
Fix breadcrumbs
Fix BS4 issues, alignment of various elements
Better auto resize of the invoice iframe
Fix invoice list for draft invoices
Fix previous/next document pagers
Remove unnecessary monetary widgets (not needed when using t-field if the field is Monetary)
Standardize invoice and sale routes:
- especially when related to displaying: html, pdf (print and download), text
- by using the get_portal_url() also for invoices
Add the total on the left column of sales order
================
Section and note
================
Improve general style:
- notes in italics
- sections: less padding, darker background, no borders
=========
Demo Data
=========
Fix sales order demo data to appear for the admin (instead of system)
PR: #25997
task-1869469
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
Before this change, the reports were generated in editable mode for branding
to be applied. The branding is used to cut the report and add on each
selected record for generating the pdf.
Applied branding and editing options takes a useless time and branding
was also applied by widgets even if branding was not requested.
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677