This commit dynamically translate some content in the spreadsheet.
Static translated terms are extracted from the spreadsheet data.
One might think we could translate the spreadsheet upfront, server side,
by translating the data before sending it to the client but it could lead to
unexpected behaviors though:
Let's say a chart has a translated title, if you copy-paste it from one sheet
to another, you still want the title to be translated/translatable.
In other words: manipulating things in the spreadsheet should be done on
the raw, untranslated, data.
X-original-commit: 53dc147504bfc3ddabef61a2bae8610f526bf6ac
Part-of: odoo/odoo#101120
This commit extract translatable content from spreadsheet data.
- chart titles and description
- pivot and list names
- argument of _t() functions
- labels of links
X-original-commit: d210a55f48b316fdf38fcbe5ae5a70cf0e2c3814
Part-of: odoo/odoo#101120
This commit make it possible for design theme tours to define
preconditions based on the CSS variables in order to make sure that
the tour is run within a website that has the specific theme applied.
See https://github.com/odoo/design-themes/pull/590.
task-2687506
closesodoo/odoo#101119
X-original-commit: b29e17765f4e912b2dd472493b5be500b3a32c87
Related: odoo/design-themes#594
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit makes failing custom `run()` functions logged as a failed
tour step.
task-2687506
X-original-commit: bcd679f1d204a8c3f858aa03a992686545829e4b
Part-of: odoo/odoo#101119
Move the analytic items menu under the management section of
the Accounting menu.
closesodoo/odoo#101109
X-original-commit: 79e3f311ed9129fadc484446efd320fa58c7b5bd
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Current behavior:
When the default intermediary account is the same as the default
receivable account define on customers, and you make a payment with
2 differents payment methods the invoice is not marked as paid.
Steps to reproduce:
- Set the Default Intermediary Account to be the same as the default
receivable account on customers. (You can get the default account
by creating a new customer and go in the accounting section and
look for "Account receivable")
- Start a PoS session, select a customer
- Add some product to the order and click on payment
- Click on invoice
- Pay with 2 differents payment methods (cash and bank)
- Validate the order
- The invoice is not marked as paid (Amount due > 0)
opw-2972726
closesodoo/odoo#101106
X-original-commit: 439f7ee0ceae01eaba6a5a352e45531d5e9c9167
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
The web tooling to lint/prettify the js codebase was only enabled
for master branches, because we want minimal diffs in stable.
However, v16 just got freezed, and we can afford to lint for a
while, at least until it is released. This commit enables the
script for v16, in addition to master.
closesodoo/odoo#101110
X-original-commit: 47ffd1b9efa933fa37c1b629afeeb4e3df123249
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the no content helper was displayed just
below the control panel in empty list views, whereas it must be
displayed approximately in the middle of the screen.
The `position: relative` has been introduced recently, and doesn't
seem useful, so we simply remove it.
closesodoo/odoo#101108
X-original-commit: ee18aa1f6b85eb420e198775592a9e0772cc8475
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: adyen, authorize, demo, razorpay, stripe.
The param `create_refund_transaction` from `_send_refund_request` became
useless following this commit:
https://github.com/odoo/odoo/commit/e4c63126b45854b10f08ab14dee5eb1d4ed98bb0
It was only used for Authorize.net, which now works without calling this
param.
task-2869910
closesodoo/odoo#101105
X-original-commit: 6855d65df7a83037ee5e2202966fa4e67dae7d5a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit prevents the "|" between the additional title and the
website or company name from being turned into a translatable `span`.
closesodoo/odoo#101102
X-original-commit: 81c7c4cdf973b36e8ed787f8247da3a4bbf93117
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the popover was incorrectly
positionned because of the style of the legacy widget.
The legacy widget added some rules to add margin and an arrow
that the new component does not need.
closesodoo/odoo#101097
X-original-commit: bd4862774264c5169aa2dcf4cd80908c2f4c71bb
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a Kanban view, the group representing
a new column did not contain a domain. Its domain should have combined
the view domain and the groupBy domain ([groupByField.name, "=", id]).
How to reproduce:
- Go to a grouped kanban view with a progress bar
- Create a new column
- Create a record in this new column
- Click on the progress bar to filter the records on a state
Before this commit:
All records corresponding to the selected state are displayed in the
column. (even the records that are not part of the column)
After this commit:
Only the new record is displayed in the column.
closesodoo/odoo#101096
X-original-commit: 1022262c6fcd51c8d4fc8024217542bb1f536d2c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
The template user groups are applied to new users, but this is not the
case for existing users.
To harmonize the flow, the added groups to the default user template are
synchronized with the existing users.
closesodoo/odoo#101086
X-original-commit: aefb05eb497a8a16a9359432f41024c09552ed70
Related: odoo/enterprise#31759
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If called in cascade, this could lead to a situation in which a same
thread is trying to create recursively several registries when loading
the sames modules, which obviously cannot work in any way.
Use button_install instead, that will simply update the module state
while waiting to be installed in a proper way, instead of forcing
a registry creation that will mess the whole process.
X-original-commit: 6b52844a8dc78788cbd948c7e2f90156ee8b89d7
Part-of: odoo/odoo#101086
Before this commit, when website was not installed, the frontend used
the default bootstrap font. That font was not receiving the unicode
support Odoo provide in the backend or the frontend when website is
installed. This is probably visible on some portal pages in hebrew or
something like that, so this could back-ported in stable if found
necessary (in that case, the fix to the `o-add-unicode-support-font` in
this PR should be back-ported too).
task-2993054
closesodoo/odoo#101068
X-original-commit: f7cfcae0f0169774e0b66b8b8083005a7cd34eaa
Related: odoo/design-themes#593
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To allow increasing page loading performance, websites can now choose to
use system fonts instead of using a google font. It is also the default
in the default theme of Odoo from now on. The option will automatically
be available for all themes whatever way they defined their available
fonts but will only be used as default if explicitly asked by the theme
(as done in the default theme).
task-2993054
X-original-commit: c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
Part-of: odoo/odoo#101068
Before this commit, if a theme wanted to define a main font for their
theme and let the "headings", "navbar" and "buttons" ones use the same
they had to add this in their map:
```
'font': XXX,
'headings-font': null,
'navbar-font': null,
'button-font': null,
```
Indeed, without setting the "null" values, those font would use YYY
which is the first font defined in the theme config, which might be
different from XXX. And if forcing XXX 4 times, like most themes do at
the moment, if the user wanted to change them all, he had to change the
4 ones instead of the main one.
Now, only the 'font' value use the first font defined in the theme
config if not explicitly set. So forcing the null values is not
necessary, it will be the default behavior.
The advantage is thus also functional, as most theme forced all their 4
fonts so changing the main one did not change the others.
task-2993054
X-original-commit: c6b56955f62c6b837b477223daac2d87ab984efb
Part-of: odoo/odoo#101068
Before this commit, if a theme defined in its website values "palette"
"null" as value for the "headings-font" variable, it was properly making
the headings font use the default "body" font as expected but the editor
panel showed an empty value instead of displaying the "body" font value.
Now, that panel UI problem is fixed for the headings, navbar and buttons
fonts. Note that all our current themes force the font for each of those
component so the bug was never visible anyway. That's why it is merged
here in 16.0 and not before but it could be backported if necessary
(although it is only an UI bug which is not really confusing).
Before this commit, for a theme which says "use XXX as main font" and
"let headings follow the main font", the UI displayed:
Main font: XXX
Headings font: /
After this commit, it displays:
Main font: XXX
Headings: XXX
task-2993054
X-original-commit: b07a408f2f80638a2abdda8304e31d3dac9968b3
Part-of: odoo/odoo#101068
Before this commit, the function (which allows adding unicode support
to a font definition) relied on the fact "serif" or "sans-serif" was
defined last in the given font. If that was not the case, you had to
give the position in the given font stack where you want to include
unicode support).
Now, if no position is explicitly given, the function does not suppose
"serif" or "sans-serif" is defined last. It only supposes it is defined
somewhere in the stack, and put unicode support just before.
task-2993054
X-original-commit: 1f34ef2b64aad34ab533e77b1f31e434a5a17af1
Part-of: odoo/odoo#101068
Some views still use them.
closesodoo/odoo#101081
X-original-commit: adb5508afd2749dbbfeb85803d707df43358b011
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before, the user had to manually unplug and replug the IoT Box to reboot it.
Also, it was required to connect to the IoT box to restart Odoo service.
This improvement adds the 'Restart Odoo' and 'Reboot IoT box' buttons on the box's form view to IoT app.
They allow the user to reboot the IoT box and restart Odoo service on it remotely from the IoT app in Odoo.
task-2476576
closesodoo/odoo#101045
X-original-commit: 662b41293315ae934502c683939d9820e4ca451a
Related: odoo/enterprise#31747
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently cannot see assigned user working on picking/batch in kanban view.
Added user_id in picking kanban view, and related user_id
from batch
TaskId: 2871679
ENT PR: odoo/enterprise#28886closesodoo/odoo#101026
X-original-commit: 943e5b9761b43257ec968c12f15723c618c3b5ad
Related: odoo/enterprise#31740
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Copying an odoo chart gave a traceback since the method `copyInSheetId` wasn't implemented in Odoo Charts.
Odoo task 2987656
closesodoo/odoo#100748
X-original-commit: c26b8ee12857253c90b62b14c0a86c60457af4c2
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Minne Adrien (adrm) <adrm@odoo.com>
Given the group only contains EU27 members and the UK was specifically removed in 52cdfd22d7 it seems clear this group represents the European Union speifically rather than any other interpretation of "Europe".
Rename the group to match.
closesodoo/odoo#101051
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When the kanban is grouped on a readonly fields,
it shouldn't be possible to drag and drop a record from
one column to another.
It was the case when the field was part of the view architecture,
but not when the fields wasn't part of the architecture,
despite we have the information as we have the field description
through the search view / the control panel.
This is a bug which has been introduced during the OWL conversion.
For instance, in 15.0, when grouping CRM leads by sanitized phone,
it wasn't possible to drag and drop records from one column
to another.
In master this is possible.
Besides, in the legacy code, the readonly information
is read from both the field in the architecture and the general
field descriptions:
- https://github.com/odoo/odoo/blob/67191359f2e71be85e6e72d64720bb2748008b3f/addons/web/static/src/legacy/js/views/kanban/kanban_renderer.js#L506-L515
In addition, compared to before,
this revision allows a new possibility compared to before:
Make draggable when grouped by a field which is by default
readonly in the model,
but which is set as `readonly="0"` in the view.
This is to be uniform with what is done in the list and form views.
closesodoo/odoo#101041
X-original-commit: 2a0f8d9ddba754cfc297b2a0de6e2c56990b1e61
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: crm,link_tracker,project,sale,utm
Before this commit, in some form and kanban views, there were
missing whitespaces, typically between icons and texts. This was
due to the transition to owl views, because we simply ignored
`&nbsp;` in archs. This commit also fixes a layout issue in
a project view, where the icon and the field should be displayed
in the same line.
closesodoo/odoo#101040
X-original-commit: f5813e348b6052436a4fabaa5837ecc37b15430e
Related: odoo/enterprise#31746
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Improve both tree and form views for the account.analytic.distribution.model
closesodoo/odoo#101001
X-original-commit: bb2820ad585ceed0f0562de3cd5f9ef8f1fac7d1
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Before this commit
In a nondeterministic sequence, the editor was not totally loaded
whenever the test `mass_mailing_editor_tour` dropped a snippet
in the page.
Now, by waiting for the attribute `data-editor-message` to be set,
we ensure that the state of the editor is ready for dropping a snippet
in the page.
closesodoo/odoo#100752
X-original-commit: a333c8ff6b48c7f614ee0a45321fdf176e9dc33b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
The test was running by luck because the event and all talk pages
contains the needed elements. The favorite was checked randomly on
other pages because those steps are way faster than loading the page.
This test will fail in rare case if the page loads faster and the step
checking if the "favorite is on" occurs when the talk page is finaly
loaded.
This commit adds some step to try to ensure the page are loaded before
doing anything else.
Also enable ticks on freezetime so that we have an idea of the steps
durations in logs for easier investigation.
X-original-commit: 8405104b14624f27df4d95e21738b253d048063f
Part-of: odoo/odoo#101050
Remove sorting rules arrays from the functions that wrap them as they
are unnecessary noise.
closesodoo/odoo#101039
X-original-commit: b37baf8996d65d639f0178651a7be0206d0679d0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes some wrong usage of the bootstrap class `col` & `row`:
- POS: Missing the child `col` on `row` parent;
- Survey: Using the class `col` to center the node on the parent div;
closesodoo/odoo#101046
X-original-commit: acacf52d40a41b53aa78967748602cb3b1e62261
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the inputs (radio, check and select types) on
`focus` state wasn't visible due to the override rules in Bootstrap:
```scss
/* Example of rule for checkbox */
.form-check-input:focus {
border-color: $form-check-input-focus-border;
}
/* Default config of Bootstrap 5 */
$component-active-bg: $primary !default;
$input-focus-border-color: tint-color($component-active-bg, 50%) !default;
$form-check-input-focus-border: $input-focus-border-color !default;
/* Our override in Odoo */
$component-active-bg: $gray-200 !default;
```
This commit, sets the `$o-brand-primary` color (`#71639e` in community,
`#017e84` in enterprise) on the border in focused state.
Note:
before Bootstrap 5, this bug was not present as custom-checkbox was a
custom pseudo-element (`::before`), and so it was not possible to be on
a `focus` state on this pseudo-element.
closesodoo/odoo#101044
X-original-commit: fba258e738d6b629bb79fb5d7d9c9585733d72b1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit properly removes the Many2ManyTagsField and
Many2ManyTagsAvatarField's placeholder when at least one tag has been
selected.
Steps to reproduce:
- In Contacts, open a partner's form view
- Edit and set at least one "tag"
- The placeholder is present next to the selected tags
Note: the placeholder was already present in previous versions.
Reported by FP.
closesodoo/odoo#101042
X-original-commit: 5976e19a31b9b0edaefc1079541514810d12b240
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when exiting a record in any way, the validity of
each of the fields was checked, even if not dirty. This means that the
user would be locked on a required field if that field got an invalid
value from the server, even with no given input.
In this commit, switching the mode on a record ("readonly" | "edit")
will not go through validation if the record was not dirty.
closesodoo/odoo#101000
X-original-commit: 8a8241503e41486e79ca19f9ca16f413cfabb08b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When generating an invoice for a SO with 2 SOL that have a timesheet service
(1 SOL is timesheeted in August, the other is timesheeted in September) and
we request the invoice for the period of August only, the SOL for September
is incorrectly set to state "Nothing to Invoice", instead of staying in
state "To Invoice".
This is due to the fact that when we inspect the SOL to invoice, those that
are not in the domain (here the SOL in September is not in the time domain
of August), we set it's qty_to_invoice to 0, so it doesn't get invoiced, but
this is a computed field, which sets the line invoice_state to "Nothing to
invoice".
The proposed fix is to reset the invoice_state of the lines that are not validated by the domain to the state before setting the field qty_to_invoice to 0.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2969641
closesodoo/odoo#100978
X-original-commit: 50b81adb3ea13db33bf1375b7038b6cc3546ec86
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Lucas Lefèvre