Usually, a user name is not translated, and will not be stored in another
translated field.
X-original-commit: 1c3d14a384d5e7b86c2304ee6061855c5f448048
Part-of: odoo/odoo#103031
make searching translated field language dependent
add an extra filter using trigram index to speed up '=' and 'like' search
X-original-commit: 5b6f0a9e5f9d60735e306709a3e7d7ac46a586be
Part-of: odoo/odoo#103031
Before: while upgrading to 16.0, the PO file is loaded before migrating
ir_translate. As a result, old translations from ir_translation
override the new translations imported by new PO files.
After: translations imported by the PO file take priority over the
translations migrated from the ir_translation table.
X-original-commit: 178270eff48221537a4efba1ad8fa0b53a1516f2
Part-of: odoo/odoo#103031
Before this commit, there was a conflict between 2 of the ways to open
the WebsitePreview iframe.
First, introduced with [1], when a user click on the 'edit in backend'
systray button, the URL he was on is stored to be used later if the user
click on the "Website Preview" breadcrumb. When he will click on that
breadcrumb entry, we want him to go back to where he was, not on the
homepage.
Second, some records in form views have a "Go to website" stat button
that will go to the website preview action, loading the iframe with the
URL of the record from the form view.
Before this commit, the second flow was not working if the user
previously click on "Edit in backend" on a record (first flow
described).
Indeed, if that "last url" was set, it would always be used, ignoring
the requested one from the second flow.
Step to reproduce:
- Go to a record in the website preview, like a product
- Click on edit in backend
- You land on the product form view, and that url was saved in JS
- From there, navigate to another record through the form view, like a
m2o relation or a stat button, or by whatever other mean, but don't
hard reload the page (F5)
- For the example, let's say you landed on a blog post record
- Click on "Go to website" on that blog post form view
-> You land on the product page you were initially, not on the requested
blog post page.
Courtesy of @rdeodoo
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#103010
X-original-commit: 7cd55e8a1d9516a6f457320064160328a49210f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fixing some demo data from US having an Italian VAT.
Also, a partner's name and VAT has been changed not to be too similar
to one of our actual clients. Now the Engie Italia's VAT is used.
closesodoo/odoo#102989
X-original-commit: d169552778dff396ef28bd7b76500db8dca32879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Before this commit, when clicking on category in category bar,
the search bar was (re-)focused.
It was flickering, especially when device prompt a soft keyboard,
such as on mobile.
This commit fixes the issue by not (re-)focusing the search bar
when clicking on a category from the category bar.
Task-3013819
closesodoo/odoo#102987
X-original-commit: 61790c029b3b78c2a099ec72b0d688c28d803374
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when clicking on a mail failure in
the messaging menu in mobile, it crashed.
`NotificationGroupView` is already destroyed, so it crashed
due to attempting to access a field (`messaging`)
Task-3013202
closesodoo/odoo#102986
X-original-commit: 73b94715f0d0086d361937491c27c611a03a9f67
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Followup of #102259
Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable.
I converted all the new rules to work opposite as before, same for the JS logic which added the class based on mobile device detection (size + touch support).
closesodoo/odoo#102977
Forward-port-of: odoo/odoo#102823
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
When the payment views were updated with commit odoo/odoo@f7b8f075, a
hook was improperly renamed to `code`, which doesn't help to figure out
its purpose. This commit renames it to `provider_credentials` which
better fits its role.
While doing so, the view files are also renamed and/or split by model to
increase their readability.
closesodoo/odoo#102976
X-original-commit: 49d126d4fce18761d0261adac00e115b840b9b47
Related: odoo/enterprise#32662
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since o_form_view class was not placed on the right element, as the
form is displayed in a dialog, some styles were not applied in x2Many
dialogs using a form view. Now, the selector matches all cases and
dialogs will be stylized as expected, since the class is placed on the
dialog container instead of the first div.
Now, we are consistent both for dialogs and standard form views.
Tests have been adapted to work as expected.
closesodoo/odoo#102953
X-original-commit: af67305b43d51e1669df19d376d9bda7418ba863
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
Prior to this commit, the border of any badge was set to "1px
$o-brand-primary" in order to achieve the default badge design that
comes with transparent background.
Unfortunately this rule was affecting colored badges too, leaving no
choice rather then either remove the border (causing misalignment with
siblings default badges) or hide/re-color/keep the undesired decoration
, but with mixed results.
These commit will review the behavior applying an outline (that doesn't
affect badge's placement) to "default badges" only.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Prior to this commit, there was no common custom file to easily handle
select2 color values (e.g., dark mode).
This commit fixes this issue by redefining the values in webclient.scss.
task-2710677
Part-of: odoo/odoo#102868
Commit preparatory to the introduction of dark-mode.
note: Tooltip variables should be reworked in order to correctly handle
different scenarios. For simplicity this commit will just match popover
colors.
task-2710677
Part-of: odoo/odoo#102868
This commit adapts the module in order to correctly handle color-scheme
variations.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Move the file in a more convenient place to be shared and customized to
match different color schemes.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
The '$o-theme-text-colors' provides a list of fine-tuned text-color that
differ from the bg ones since used for text.
This commit adds `$o-brand-odoo` in the list.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Since the view's backgound-color has been historically white, white
borders have been used to adjust layout discrepancies between
components.
This commit introduces 'border-transparent' to handle the scenario
regardless by the view background color.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Since the view's background-color has been historically white, the
`bg-white` class has been used to make match several UI components.
Despite working for the default color-scheme, this approach leads to
inconsistencies when the default view's background-color changes, eg.
dark-mode.
This commit introduce 'bg-view' to set any element to match the view's
background-color, whatever it is.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Add 'black' and 'white' color in the list of backend's $theme-colors to
preserve during website's customization.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Partially remove visual discrepancies between odoo and Bootstrap fields,
allowing to use BS variables to control fields' design across versions
and color-schemes.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Items with tax "GST Only - Import" does not
appear on tax report
Add "BOX 11" tag to "GST Only" tax.
opw-2919731
closesodoo/odoo#102784
X-original-commit: 0cec2ec8b090cde5fc1c3fe46c1fb093217368d4
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Analytic distributions that contain mandatory plans should be blocked from posting.
However, automatic flows (for example subscription invoices) should not be blocked.
For this reason, the context is used to determine whether the distribution should be validated.
closesodoo/odoo#102720
X-original-commit: 7b11af76598c0782ac2097d3cbeb718962be2537
Signed-off-by: William André (wan) <wan@odoo.com>
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit, the user was not notified when he
closed the tab or the browser while modifying a record.
Now, the user will be asked to confirm the close if there
is at least one invalid field.
task id: 2994132
closesodoo/odoo#102990
X-original-commit: 3fcc36786453f3006974f5fd0fa395ad5d07d9a2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This fixes a bug that occurred when using BACKSPACE to remove the last
character of a text node, if said character was preceded by a space and
said text node was succeeded by a <br>. The space was removed along with
the character. This was simply due to a missing state restoration rule
to handle this specific case.
task-2990229
closesodoo/odoo#102974
X-original-commit: 5e90529388095321da8b504ebf543c4c3054845e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Adapts the layouts of the immediate production and the production's
backorder to match the new grid css for groups.
Part of task-2985735
closesodoo/odoo#102958
X-original-commit: 5b999ee40e02647c0d2edfbce7081f6f8cf05857
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When an electronic payment is done in the POS, the payment lines
contains the status of the electronic payment and the corresponding
button to perform actions.
We are now correctly display those informations.
closesodoo/odoo#102957
X-original-commit: 7e237dd6282ecd9ebe95690e445466acbab26ca5
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, in a grouped list view with at least one
group_operator and optional fields, the aggregated values in the header
are shifted one column to the right.
Why is this?
Adding the +1 to the colspan in the group header for optional fields
is always added on the left side (group name).
Solution:
The +1 should be added on the left side (group name) if there is
no aggregated value otherwise on the right side (pager).
Before:
TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP
0 1 2 3 4 5 6 7 8 9 10 11 12 13
[ TH 6 ][TH][TH][TH][TH][TH][ TH 3 ]
[ group name ][ aggregate cells ][ pager]
After
TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP
0 1 2 3 4 5 6 7 8 9 10 11 12 13
[ TH 5 ][TH][TH][TH][TH][TH][ TH 4 ]
[ group name ][ aggregate cells ][ pager ]
closesodoo/odoo#102754
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
GitHub has changed the way it forms absolute URLs
closesodoo/odoo#102523
X-original-commit: 181a1a10451f20c7c0b44aba44addc7a9127c219
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Remove the field `crm_statusbar` as it dosen't have a specific
behaviour, and we can use the classic `statusbar` field instead.
closesodoo/odoo#102992
X-original-commit: 386fa0a5e448f149e75da68a02ad94dd88cc4d08
Related: odoo/enterprise#32669
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, some functions overrode the save function of the
form controller. The issue is that this function is only called when the
button save is clicked, and not when we save differently (for example,
when clicking on the breadcrumb).
To avoid this mistake the save function on the form controller was
renamed to: `saveButtonClicked`, and the code that overrode the function
now override the save function of the Record, that it's called at each
time a save is perform.
X-original-commit: b6e3d833e6131562084eb13b2955c22f50ad1e79
Part-of: odoo/odoo#102992
Chong Wang (cwg)