Since the framework's navbar uses the hamburger_menu in community too,
the `navbar_mobile.scss` code initially shared between frontend and
backend is now needed for the frontend only.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Prior to this commit the topbar responsiveness was exclusive to
enterprise.
This commit moves to community the mobile logic for navbar, burgermenu,
user_menu and company_switcher.
The design has been adapted to v16, reviewing font size/colors and
icons. This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Description of the issue/feature this PR addresses:
When you want to add/select new skills, it could be more clear.
Current behavior before PR:
When you want to change a skill level, you have to select a skill level to see its progression value
Desired behavior after PR is merged:
- The progression value is displayed beside the skill level in the dropdown list.
- In the appraisal module, the same thing applies to skills, which also feature the skill type in the dropdown list.
task: #2719642 [Skills] Overwrite name_get()
skill dropdown
[IMP] hr_skills: do not display skill option if skill_type is unselected
closesodoo/odoo#82202
Related: odoo/enterprise#23237
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Current: Some tax fields are missing from the tax report
Should be: missing tax fields should be added
Part of task ID: 2694161
[IMP] l10n_lu: add tag_names and improve tax calculation
Currently:
- Taxes 094 and 095 cannot be modified and added in line
- Calculation of tax 472 is not complete
Desired:
- Taxes 094, 095 have tag_name and can be modified
- Calculation of tax 472 is full
closesodoo/odoo#84177
X-original-commit: 7acd384ba62be945b360bccc11455ddbc6a32cb4
Related: odoo/enterprise#24150
Signed-off-by: Olivier Colson <oco@odoo.com>
In mass_mailing, when clicking the media button in the toolbar, the
image would end up being added to the media button itself rather than
at the selection. That is because the selection had been replaced by
the button. This fixes it by preventing default behavior of the
mousedown event on toolbar (thereby preventing the change of selection).
task-2745984
closesodoo/odoo#84218
X-original-commit: da55a5fa6344734bf751a5976e0dc5bdacd4e119
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In ae4435af, two fonts were added without a clear licensing.
With this commit, they are replaced with more recent and better fonts
with a clear OFL license.
closesodoo/odoo#84223
X-original-commit: bec81ca1870f0dcedcc781a7dbb907bdade78e69
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Co-authored-by: Elisabeth Dickinson <edi@odoo.com>
Steps :
Go to a Task > Sub-Tasks > Assignee
Issue :
You can assign a portal user
Fix :
Add ('share', '=', False) to user_ids domain
closesodoo/odoo#84214
Opw: 2759085
X-original-commit: 6a2936c700d19c109db8f1adb06c7de1b8cf2403
Related: odoo/enterprise#24169
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The test was failing because of the hardcoded date in the expected test
values, whereas the real values gotten were using today's date.
The test should also be running when installing only `l10n_fr_fec`, so
we should be installing a chart template from `l10n_fr`, not the generic
one.
closesodoo/odoo#84196
X-original-commit: d9b56e9eda5ce1d93e4f8cfe16233850a3b39de9
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In preparation for OWL-2, we introduce a new tooltip service that replaces
the hook useTooltip used by the webclient. The main reason for that is
that the implementation of useTooltip had to access el on the components
calling it. Since this won't be possible anymore in OWL-2 (el is ill-defined
in presence of multi root components) we had to find something else.
Another reason is that the useTooltip hook had no reason at all to be a
hook (as attested by the fact that only the webclient needs to call it
to have tooltip on every dom elements).
closesodoo/odoo#84160
Related: odoo/enterprise#24152
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Hide and rephrase "You have gained access to the following course(s):"
message if the product is not a course when website_sale_slides is
installed.
Task-2737404
closesodoo/odoo#84197
X-original-commit: 91eaa2cdc1a546e5358e19918fdc0ba1a7f498b2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since the introduction of the strikethrough button, the text toolbar
overflowed website's sidebar. This reduces their size so they don't
overflow.
task-2758967
closesodoo/odoo#84190
X-original-commit: 896c64cdf74e5c602a92a28f95f79e20c08ffd87
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
Also simplify _is_valid_product method to make use of _get_valid_products.
As it uses filtered_domain is more efficient than a search_count.
closesodoo/odoo#84175
X-original-commit: 71132ce3472ea7e85aab07061ce20352d2ab895d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When saving a mailing (mass_mailing) with invalid fields, the mailing
ended up having a height of 0. This is because some changes from
convert_inline are applied inline and may be incompatible with the grid
structure of the mailing. This was the case with height=0 applied on the
mail layout element as a result of it having a child with a height
expressed in percents. Rather than set the height to 0, we now set it
to whatever the height was measured to be.
task-2734605
closesodoo/odoo#84174
X-original-commit: 5c606188d1a57a0702213298f5ffa3ace8fd5523
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
l10n doesn't depend of stock so move it to l10n_stock to have
correct dependencies
closesodoo/odoo#84173
X-original-commit: f1c55ec86102bfd52730f34eb19d002d4e22a3d2
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Backport from the master-httpocalypse-juc test suite in order to observe
the perf of the master branch and to compare them with the httpocalypse.
closesodoo/odoo#84156
Task: 2571224
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
It's configurable from the website editor itself.
Keep the default fields on the website model in case someone
changes its mind though.
closesodoo/odoo#82999
Related: odoo/upgrade#3210
Related: odoo/enterprise#23612
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, when adding a product to the cart, this is possible to:
- Force the user to stay on product page
- Redirect the user to the cart page
Also, when there are configurable products (with variants), or when
there are optional products, a dialog is opening to let the user
finalize his choice.
This commit adds a new option to "Let the user decide" to be redirected
to the cart, or to stay there. For this, we reuse the dialog that was
previously reserved to the use cases explained above.
Part-of: odoo/odoo#82999
Purpose
=======
On the res.config.settings model for example, calling execute without
having changed a single parameter will make several writes on
ir.default records.
However, even if the written and the current values are the same,
the cache will be invalidated several times.
Part-of: odoo/odoo#82999
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
This commit introduces our own icons meant to be extended over time and
to coexist with FontAwesome 4.7.
The goal is to provide a wider range of icons specifically made for our
UI and cover FontAwesome's lack of iconography for specific businesses
and functionalities.
Classes' names are available in our documentation website and the SVG
source files can be found in our `design-assets` repo.
This new bundle mirrors fontAwesome architecture; icons are rendered
applying classes to standard HTML flow-tags (normally an `<i>`), eg:
`<i class="oi oi-odoo"/>`
This implementation applies size and alignment rules directly to the
`:before` pseudo-element rather than to the class itself. The aim is to
prevent misalignment when icon classes are applied to buttons and other
UI elements, eg:
`<button class="btn btn-success oi oi-arrow--right"/>`
Note: Despite being technically feasible, this approach is highly
discouraged and should be avoided.
This commit also introduces utility-classes specifically made for
our UI. In detail:
- Fours sizes: '.oi-small', '.oi-normal', '.oi-large', '.oi-larger'
Relative to the parent font-size, these classes cover a range from
`0.8em` to `1.77em`. Each size has been designed to match our default
text-fonts in the attempt to compensate font-icons common alignment
issues (https://css-tricks.com/icon-fonts-vs-svg/#aa-positioning ).
- Responsive classes: `.oi-[screen]-[icon_size]`
Responsive classes mirror Bootstrap ones and can be combined to
achieve different size results at specific resolutions, eg:
`<i class="oi oi-studio oi-larger oi-md-normal oi-lg-small"/>`
- Fixed width: '.oi-fw'
Mirrors FontAwesome 'fa-fw' by setting icons at a fixed width.
Our implementation adapts according to size and responsive classes.
- Animations: '.oi-spin', '.oi-pulse'
Mirrors FontAwesome default animations.
This commit is part of v16 overall restyle (task-2704984).
enterprise: https://github.com/odoo/enterprise/pull/23848
task-2745275
Part-of: odoo/odoo#83501
This commit reduces fontAwesome footprint by removing legacy font-files
(~750kb). It keeps WOFF(s) formats for browsers and TTF format for PDF
and ICON to PNG generations.
TTF format has been removed from the CSS [@]fontface rule, but it's
still called directly in python when needed[1].
This commit reviews the CSS too, removing obsolete vendor-prefix rules
and discontinued fontAwesome classes.
Part of v16 overall restyle (task-2704984).
task-2745275
[1] https://github.com/odoo/odoo/blob/15.0/addons/web_editor/controllers/main.py#L45
Part-of: odoo/odoo#83501
This commit "forks" fontAwesome into `src/libs` in order to allow
further customization.
Part of v16 overall restyle (task-2704984).
task-2745275
Part-of: odoo/odoo#83501
Purpose
=======
Allow to restrict note to users having access to a specific company
For example, when creating a new company, it create a "Useful Links" note
that is used on the payroll dashboard (With granted access to payroll officers
who belongs to this company).
This note should be restricted to people having access to the company,
and shouldn't be mixed all the time for people having multi company accesses.
closesodoo/odoo#84155
Related: odoo/enterprise#24128
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Allow the bill prediction when data like facturx is imported.
This revert #68311 stating prediction might cause traceback when no account_id is found.
Now, this error seems to not occur anymore.
When importing data like facturx and no account_id is predicted, the default account set on the
vendor journal will be set.
opw-2662158
closesodoo/odoo#84092
X-original-commit: 1acece31eaf1417dea6ed330ac25c3b8de162baf
Signed-off-by: William André (wan) <wan@odoo.com>
Gain of ~80% of the SQL queries & ~50% of execution time in a database
with test_main_flows & dependencies installed.
On a benchmark of 100 calls of (load_menus(True) + load_menus(False))
* 266 > 56 queries
* 0.38 > 0.21 sec of execution (mean)
Note that this only impacts the first request since this method is cached.
Unless user groups (or debug status) are different, the cached results
are returned.
closesodoo/odoo#83172
Signed-off-by: Raphael Collet <rco@odoo.com>
When we are only trying to know accepted raw values, there is no
need to fetch the translations for the description part of the
selection tuples.
This performance problem was first observed on res.config.settings
record creation, where the values are pruned to avoid writes and
invalidation for unmodified related values (cf create override
in base/models/res_config.py & 5a4e7b711e).
After more analysis, the 'problem' also impacts record updates on
any related field (readonly or not).
* Res.config.settings performance gains:
In a database with test_main_flows (& its diverse dependencies),
this reduces by ~50% the number of queries done when triggering
the creation of res.config.settings record through the interface
(aka with all the related updatable fields receiving their current
value as create value).
For the creation of 150 res.config.settings records, with full cache
invalidation between each record creation, we notice a gain of:
* 11853 to 6303 total queries
* 11.2s to 7.5s total creation time
Part-of: odoo/odoo#83104
* batch module data prefetch in res.config.settings flows.
* manipulate ir.module.module records instead of a strange list of tuples
* Only keep the missing module names logic where useful (useless for the
res.config.settings scope, modules must exists to be referenced by
a settings field).
* drop the support of module fields of type selection, they are not used anymore,
it's not even sure they still work and this feature doesn't bring much added value anyway.
Part-of: odoo/odoo#83104
Before this commit the target of options and nested options tour steps
could be hidden under an opened palette.
After this commit the tips of options and nested options tour steps
require that no palette is opened.
An 'allowPalette' parameter can be used to remove this condition, for
example if 'changeOption' is used to select an option within the
palette during a test tour.
A step is added to close the color palette - which, while opened,
prevents the next `changeOption` step from being activated.
task-2728994 (was task-2675252)
closesodoo/odoo#84093
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Delivery slip packages contains products not present in the package
Steps to reproduce:
1. Install Sales and Inventory
2. Go to Settings > Inventory > Operations and enable Packages
3. Create and confirm a sale order with product A, B and C
4. Click on the delivery smart button and create and assign different packages for products A and B
5. Set done quantities for products A and B
6. Validate the delivery with no backorder
7. Click on Print > Delivery Slip
8. Product C is in both packages
Solution:
Don't print empty moves when packages are used
Problem:
`_get_aggregated_product_quantities` returns all move lines related to a certain `stock.picking`, even the empty ones
It is called for each package so the same empty lines will be displayed for all packages
OPW-2727659
closesodoo/odoo#84138
X-original-commit: 1b39e170537d48a29a0dda06776cfacef41b9c8f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
The undo-redo buttons on top of the snippets menu of mass_mailing had no
icon when website was not installed. This was because there was css
forcing the font family to something other than fontawesome. This
ensures we don't do that for elements with the "fa" class.
task-2746002
closesodoo/odoo#84126
X-original-commit: b3a91899cd7e6772a241badfc0bd9699bb6e0e74
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The issue has been introduced by 1fe4b0cc1981382cc3d944ec44276f0aee90945d.
A simple example is an element with attribute "string" like
<field name="foo" string=" "/>
When the translation process is parsing the value of the attribute as
some HTML fragment html.from_string(" "), it raises an exception. This
was not a problem before the commit above, but it now is. For instance,
updating the view "event.view_event_form" triggers the error.
closesodoo/odoo#84144
X-original-commit: 5ffc1704162d8918985964b08f4b2b49e6054958
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.
This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6closesodoo/odoo#84139
X-original-commit: b83b465dd98345afeca3844a4796e4a83d15f72b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.
However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.
Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9
X-original-commit: a2363337355ccf4363249657000cd85bfcb3ab4e
Part-of: odoo/odoo#84139
This commit adds the 'consumeVisibleOnly: true' marker on the "+New"
step of the website_event tour, and requires the "new content menu" to
not be opened.
This is a part of [1] but for a tour that did not exist in 14.0.
[1]: https://github.com/odoo/odoo/commit/0fa40e37e596798665a098ee999f49749b6012a2
task-2728994 (was task-2675252)
closesodoo/odoo#84137
X-original-commit: 9c6d5c038a6d3888a329d2140169e52389b3b5c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Consistency in naming with other models.
Part of task-2694206, split from main PR to ease its diff
closesodoo/odoo#84130
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
stefanorigano (SRI)