| Age | Commit message (Collapse) | Author |
|---|
|
When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.
To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
- Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries
Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).
The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.
OPW-2478311
closes odoo/odoo#70746
X-original-commit: 88a10bdd8f1d46a8b52be59fe3284cbe284a74f2
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
|
|
*: web, mass_mailing, website, website_form, website_sale
New CSS design of the editor (step 1/x).
This work is unfortunately far from perfect but is a first step towards
what we want. In particular, much CSS linked to elements that are meant
to be removed/moved in the upcoming weeks was done in a huge rush but
will thus hopefully be removed/reviewed before the 14.0 release.
As the design is now far more complex including gradients and other
"complex" elements, it was also very difficult to keep a design based on
css-variable so this system was removed, which means that the editor now
appears the same everywhere (backend, frontend, ...). The original goal
of this system was to have an adapted style for backend, frontend and
website visitors. Unfortunately, the current result was a very good
frontend editor design, a not-so-good backend editor design (for mass
mailing at least) and a totally unadapted design for the website
visitors. Making this perfect will be achievable by loading different
assets for those 3 areas and hopefully those assets will only differ by
the values of editor scss variables.
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
|
|
Steps to reproduce:
- install timesheet
- go to general settings > set documents layout to use 'external_layout_boxed'
- go to timesheets > list view > select all > print > timesheet entries
Previous behavior:
the first line of the report's table is missing a border
Current behavior:
borders are consistent
opw-2230710
closes odoo/odoo#49432
X-original-commit: a70437c0fc8127976ce00b5ec1ef4ae006b28e15
Signed-off-by: Nicolas Lempereur (nle) <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
closes odoo/odoo#46647
X-original-commit: a5b1421aecf27b1de408434d3bb6d7ac81f57dc3
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
|
|
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>
closes odoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
|
|
|
|
closes odoo/odoo#34091
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
|
|
Arabic customers are complaining the Lato font is very odd looking for
Arabic scripts. Furthermore, since #32312 Noto is used as the prefered
font to display arabic scripts.
The classes are used by the "Company Tagline" configured along with the
template in use in the general settings.
opw-1946109
closes odoo/odoo#33141
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
While printing the reports using boxed layout, the font-size is bit smaller
and the report does not look so good. This commit improves the boxed layout
by slightly increasing the font-size.
Task id: #1931768
closes odoo/odoo#30497
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Following BS4 migration and adding sections and notes.
=====
Document templates:
- Remove margin from <p> in "informations" to allow them to be
correctly centered vertically on their container.
- Also add a mt- and mb- on their <div> to better handle them going to a new
line when there are too many of them.
- Add class for section and note to be able to customize them in layouts.
- Add class for price_total to be able to customize it in layouts instead
of relying on :last-child.
- Add "page-break-inside: avoid;" on the "total" table to not split it
between pages when it can be avoided.
- Fix sale report template "Informations" to use col-auto just like invoice
See 6b8d7bb6d68221f77dabb223de4160fdfb87a6f8
=====
Boxed layout:
- fix section & note style
- fix borders in general
- fix the total table
Background layout:
- fix section style
- fix the total table
Clean layout:
- fix page number vertical align
task-1889346
closes odoo/odoo#27782
|
|
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
|
|
col-lg-* -> col-xl-*
col-md-* -> col-lg-*
col-sm-* -> col-md-*
col-xs-* -> col-*
col-lg-offset-* -> offset-xl-*
col-md-offset-* -> offset-lg-*
col-sm-offset-* -> offset-md-*
col-xs-offset-* -> offset-*
col-lg-pull-* -> order-xl-1
col-md-pull-* -> order-lg-1
col-sm-pull-* -> order-md-1
col-xs-pull-* -> order-1
col-lg-push-* -> order-xl-2
col-md-push-* -> order-lg-2
col-sm-push-* -> order-md-2
col-xs-push-* -> order-2
|
|
Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.
BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.
The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:
$gray-darker -> gray 900 (unused before)
$gray-dark -> gray 900
$gray -> gray 700
$gray-light -> gray 600
$gray-lighter-darker -> gray 400 (the old variable was created by us)
$gray-lighter-dark -> gray 300 (the old variable was created by us)
$gray-lighter -> gray 200
Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.
|
|
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
|
|
*account_payment, l10_in(_sale), sale(_stock), web
With this commit:
The invoice preview in portal (/my/invoices..) is now the HTML version of the
PDF report.
The HTML preview is based on the invoice report to closely match what is
already done in Odoo.
The invoice preview is displayed in an 'iframe', it is mandatory since:
1. Reports are rendered as a separate page as it returns the whole page after
rendering, which has tag <html>, <head> etc
2. Reports are having their own layouts and their own assets that we we cannot
load in the page directly or it will break the website layout.
3. We can not use report template with t-call because internally reports are
using extra params like context_timestamp, company, DateTime, user etc which
is used in header/footer
--
There will be a chatter (as a modal) to display/see the history of the document
--
For responsive purpose, we use new tables with limited column (Description,
Quantity and Amount) for responsive purpose (small screen).
It also adds some bootstrap classes to reports for responsive purpose.
--
The 'Pay Now' button remains if you already paid with 'wire transfer'.
--
Add margin after the header and before the footer to look like the real printed
document, without alterating the real printed version
Task ID: 39876
|
|
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
|
|
This is a simple renaming without adaptation.
|
