As a developer,
when you craft your records set manually,
and wrongly use the API and set something weird in `ids`,
something else than a tuple of integers,
`repr` should help you to understand you did something wrong.
e.g.
before
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner(1,)
```
after
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner'(1,)'
```
We could put an assert in `_browse` to make sure `ids`
is a tuple of integers, but this is considered a non-stable
change, as it will suddenly crashes when you will update
Odoo while it wasn't the case before.
closesodoo/odoo#118119
X-original-commit: f689c4f53fc4663b17c57bd1d704b9ffb9f11f8d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This PR fixes the `15350`runbot issue that was due to the
websocket subscribe not being properly awaited before logging
out.When the log out occurred before the subscribe was received,
the `odoo_ws` variable was `None`.
closesodoo/odoo#118097
X-original-commit: 59af91840c3ed7253c1c3c9dd80a4919ebdee593
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
doAction does not convert the action help html to markup resulting in the display of an html string.
To replicate:
- Journal Items List view or Analytic Items
- Click a link to the bank recon widget
- In bank recon widget, search for something that returns no records
- The no content helper displays html string
After this PR:
By using the doActionButton instead, noConentHelper is marked up and displays correctly.
closesodoo/odoo#118093
X-original-commit: 8cedb020f2bcd2115fdaf0fb44abbeb936ced3c0
Related: odoo/enterprise#39531
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
The co-model field in `IrField` view is accepting Related Model name
even if it is invalid. And replaces the invalid model name with `_unknown`.
This causes KeyError `display_name` when trying to create or read a record.
To fix that we are adding Validations for the Related Model field when it gets
updated from UI side.
sentry-3933471439
closesodoo/odoo#118052
X-original-commit: e4f7798fd5a5cccd5d385f535fbc21264cb6948b
Signed-off-by: Rémy Voet <ryv@odoo.com>
Since Bootstrap 5, bg- classes behave differently. On the website
e-commerce shop the ribbon for the states "Sale, Sold out, Out of stock,
New!" still uses bg- classes therefore having the wrong text color by
default, making it difficult to read.
This commit fixes the default text color by using new bootstrap 5 class
text-bg-* instead of bg-*
task-3096035
closesodoo/odoo#118051
X-original-commit: e6ecb4f72e9610bd5e3f81264c8278fbb7a6d5a3
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
We move the function loadFields from the view service to a newly created
field service. That service can also be used to load model fields for a
given path (loadPath), i.e. load all model fields for the models
traversed by the given path.
We use loadPath in useModelField and DomainSelector.
closesodoo/odoo#117882
Related: odoo/enterprise#39418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We introduce two new methods for Cache:
- a method "clear" that can be used to delete a specific path
- a method "invalidate" that can be used to delete all paths
Part-of: odoo/odoo#117882
Steps to reproduce the bug:
- Go on the blog of the website.
- Edit.
- In the "Customize" section, apply the "List" "Layout" and activate
the "Sidebar".
-> The sidebar appears at the bottom of the page instead of on the
side.
The situation looks like this:
```html
<div class="container">
<div class="row">
<div class="col"></div>
<div class="border-end"></div>
<div class="col-12"></div>
</div>
</div>
```
The bug comes from the fact that the `div` with the `border-end` class
is inside a `row` class. Due to that, a bootstrap 5 css rule applies
and puts the `width` of the `div.border-end` element to `100%`. Because
the element tries to fill the entire width of the `div.row`, it is put
at the bottom of the page as well as its following elements (in this
case, the sidebar). This bug is fixed by removing the `div.border-end`
element.
opw-3217775
closesodoo/odoo#117849
X-original-commit: 9d8b895b934e5b0986c932837fd043cf847a8992
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1. always show the name of the assignee.
2. replace the icon with avatar
3. bold the time info.
task-3142628
closesodoo/odoo#116349
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit adds a menu to see reaction on a message.
It can be accessed from message options or from long press in mobile.
Task-2641441
closesodoo/odoo#116022
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Incorporate Carlos Carral (carralc) as Vauxoo's contributor.
closesodoo/odoo#118040
X-original-commit: 0472569febd557a9956b196e840dd996309c9f9c
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the Invoicing dashboard, the upper-left most scorecard displays the total
invoiced amount.
The baseline "X unpaid" is wrong. It was displaying the difference between
the key value (total invoiced amount) and the unpaid amount.
That means if not a single invoice was paid (everything unpaid), it would
display "0 unpaid". That obviously not correct.
opw-3248761
closesodoo/odoo#118030
X-original-commit: 2b795ee59ef063b5b7298382008ebd61c51de36e
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
1:/
- Select the company A
- Create a purchase order:
- product: “P1”
- vendor: “V1”
- confirm the PO
The vendor “V1” is added to the supplier list of “P1”
2:/
- Select the company B
- Create a purchase order:
- product: “P1”
- vendor: “V2”
- confirm the PO
Problem:
The vendor “V2” is added to the list but “V1” is deleted from the list
in company A
The “seller_ids” field is in the “product.template” model, we try to
modify it in the “_add_supplier_to_product” function from the
“product_id”(product.product) field which inherits from the
“product.Template” model:
https://github.com/odoo/odoo/blob/3b88ed5ea458a37ee4d440f83bab45bd0fb13845/addons/purchase/models/purchase.py#L531-L532
So the function “inverse_related” will be called, in which the function
“__set__” will be triggered: In the values, the command for the create
will be added but the command for the set will be added as well while
it shouldn't. So in the `write_real` function a search will be done to
get all `product.supplierinfo` with the same product_tmpl_id:
https://github.com/odoo/odoo/blob/36544651f2049bcf18777091dbf02c9631b33243/odoo/fields.py#L4415-L4417
but as we are in sudo, those of company “A” will also be recovered, so
they will be unlinked since they are not in the command.set
opw-3251941
closesodoo/odoo#117985
X-original-commit: 78f803f3c1963711e2a5541f913f030da4f06fb7
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This will improve the testing of the onboarding tour
- earlier when we change the class and don't update the class in the tour it goes unnoticed
- to prevent failure of the tour we called onboarding tour from python to test the flow
- Because it helps users to understand the flow so we can let the tour fail
task-3235684
closesodoo/odoo#115672
Related: odoo/enterprise#38333
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit:
- The burndown chart displayed the stage in order of the data fetching which wasn't logical especial for a chart that supposed to represent the evolution of the tasks in the project
- When sorting all/my tasks by stage, It was possible to select any project in any quickcreate of the stages which didn't make much sense
After this commit:
The burndown chart legend is now ordered according to the stage sequence (previously was ordered randomly by comming data)
Modified the burndownChartModel, simply makes a RPC to get the stages and sequences then sort the legend elements (one by stage) with it
Display only the projects which uses the stage in the dropdown menu of the task kanban quickcreate (when grouping by stage)
When sorting by all/my tasks by stage, the quickcreate now only display the projects which contains the stage selected
done by adding a domain in the quickcreate form
(shoutout to LTU and AUON who actually found the fix)
Task-3067445
closesodoo/odoo#105694
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This PR fixes the `19916` issue on the `test_mail_channel_public_page_as_guest`
test.
The messaging service subscribes to bus notifications before it is fully
initialized. This test is composed of two tours. In the first one, the guest joins
the channel and receives the "guest has joined the channel" message. Then, the second
tour starts and the local storage is cleared. Since the local storage has been cleared,
the guest receives this message again, potentially before messaging has been initialized
which leads to a `channel_pin` rpc. This RPC fails with `SessionExpired` error and the tour
is stuck and eventually, fails.
closesodoo/odoo#118000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
17c4f47b0a updated table_kind to return
`pg_class.relkind`, however the semantics are *not* the same, and that
was ignored: `relkind = t` is for *toast* tables, not *temporary*
tables. In `pg_class` the temporary-ness is instead signaled by
`relpersistence` (which applies to both tables and sequences), temp
(and unlogged) tables have `relkind = r`. `existing_tables` does that
correctly, possibly unwittingly.
While at it, upgrade `table_kind` to return an `enum` (whose value is
the old discriminant).
closesodoo/odoo#117444
Related: odoo/enterprise#39185
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently, the "receipt_header" and "receipt_footer" text fields of the
'pos.config' model can be used to render html in the receipt using qweb by
putting `<!DOCTYPE QWEB` as the first line of the text. In the previous
versions, it is converted to a markup so it is rendered as html in the
receipt. Rendering it as markup poses security issues therefore we are
removing this feature in this commit.
After this commit, we now only allow regular string to be added in the
receipt and footer headers.
If user wants to introduce custom markup in the headers, they can
properly do so by extending the `OrderReceipt` template from other addons.
closesodoo/odoo#117336
Task-id: 3256208
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit:
- project tasks view: when we group by company, milestone, customer,
worksheet template or any m2o field, the KanbanColumnQuickCreate is
displayed for that field, we can add a new one or apply examples,
but thoses examples are stages.
That doesn't make any sens to add them in a project or milestone context,
then if you add a new column manually or via the apply examples, it will
disappear once refreshing the page.
To summarize, stage is the only valid group by that can have the
KanbanColumnQuickCreate.
- all tasks view: same problem as the previous point + quick creating
is also not valid for group by stage as we are in all tasks context that
are linked to different project and the examples are mainly applied for a specific
project, if you try to add manually or via the examples and refresh they are going
to disappear as they are not linked to any project.
- my tasks view, same problem for previous point + quick creating when grouping
by personal stage is valid but apply examples button is displayed to show stages and if
used, it will not add anything, so it should be hidden.
- Project Kanban examples stages are all created as not folded.
Some users don't know that 'folded in kanban' option is available on the stages,
and that tasks in a folded stage are considered as done.
After this commit:
- project tasks: KanbanColumnQuickCreate and applying examples are only available
when grouping by stage.
- all tasks: KanbanColumnQuickCreate is not available.
- my tasks: KanbanColumnQuickCreate is only available when grouping by personal stages.
applying examples is not available.
- some example stages are folded..
task-3092925
closesodoo/odoo#107633
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
before this commit, in the calendar view, if there is
a field of selection field, instead of showing the
filter value, currently it is shown as undefined.
after this commit, the filter will show the selection
value instead of undefined.
closesodoo/odoo#118007
X-original-commit: edf838d791ee02f41af2bff32dc20b5657ef0d81
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
partial revert of https://github.com/odoo/odoo/pull/117205
Since there was no link between the odoo instance and the new tab,
it was impossible to determine if it was really open and the test
afterward would always trigger
closesodoo/odoo#117973
X-original-commit: 5717eeec9eb8d5cc9cd684e6b147919d808f5db1
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Steps to reproduce:
- In a snippet in grid mode, resize a column.
- Drag and drop this column in a non-grid dropzone.
- Undo.
=> The column is back in the grid but is still a normal column. The same
happens when doing these steps with a normal column to a grid.
This happens because the class changes are not observed in these cases.
When fixing the drag and drop history in [1], only the style changes
were observed because the class changes are automatically recorded. But
it is not the case after a resize.
This commit fixes that by also observing the class changes.
[1]: https://github.com/odoo/odoo/commit/1dfb127f70832aa9e9022ac337af343b7dc17729
task-3151207
closesodoo/odoo#117854
X-original-commit: 48b3683c4753f1e385ea1692db9c1a15d32cae30
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
This commit fixes some mistakes that were found in the code of the grid
layout option. More precisely:
- When a column was dropped near a grid dropzone (so not inside it), and
if its height was bigger than the grid, the `rowCount` attribute of the
row was not updated to the correct number of rows => there was one extra
row.
- When we start dragging a grid item, if we do not go over the starting
grid at all (it happens if the move handle is placed outside of the
row), the `rowCount` of the starting grid was never updated. This is
because the resize is done at the "out" of the dropzone so if there was
no "over", it cannot be done.
=> As a fix, the starting grid is now always resized when we drop the
column.
- When dropping a grid item inside a non-grid dropzone, its `z-index`
CSS property was not removed.
- When a grid item becomes a normal column, when dropping it in a non-
grid dropzone or when toggling the normal mode, the resize classes
(`g-col-lg-*` and `g-height-*`) were not removed from it.
- When a normal column becomes a grid item, the padding and offset
classes were not removed and the `col-` class was not systematically
synchronized with the `g-col-lg-*` class.
=> The two previous points need to be fixed because after doing multiple
drag and drops, the classes could become inconsistent. This happened
especially with columns whose width changes a lot between snippets (like
with Masonry columns, because of the padding).
- When going back to normal mode, the `--grid-item-padding-*` CSS
variables were not removed from the row.
- In commit [1], a comment that should have been modified has been
forgotten.
[1]: https://github.com/odoo/odoo/commit/67d1b078329600efce414974307d74e9fa9ba9fe
task-3151207
X-original-commit: 4afd418e1a1d4231369aab08dfa5c2d10ca9a310
Part-of: odoo/odoo#117854
Steps to reproduce:
- install website_sale;
- with web editor add a language selector to the top bar menu;
- go to the page '/shop/cart';
- click on the cart.
Issue:
A traceback appears.
Cause:
We use the property of a HTML element without checking its presence.
opw-3246545
closesodoo/odoo#117966
X-original-commit: e6829c38ff3fc0139583be94bf6f86c9acaab8fa
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Problem:
Indian edi doesn't take into account the round off.
Cause:
It is looking for rounding lines in `invoice_line_ids`, but since v16,
rounding lines are no more invoice lines.
`invoice_line_ids` is a subset only consisting of move lines
having a `display_type` in `('product', 'line_section', 'line_note')`
and a rounding line is a move line with a `display_type == 'rounding'`.
Fix:
Rounding lines must be searched in `line_ids` and not in
`invoice_line_ids`.
opw-3202845
closesodoo/odoo#117922
X-original-commit: a07d9683eae9c49cb8a36c6b1781c33d48eb03cb
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Arnaud-Sibille <arsi@odoo.com>
This commit introduces an optimization to reduce the number of read
operations performed in kanban views that are grouped by a field with
a group_by_tooltip. Specifically, we now fetch the required values
from group_by_tooltip only when the tooltip is first opened, instead
of performing a read every time the view is loaded.
Part of Task: 3179751
closesodoo/odoo#117758
Related: odoo/enterprise#39349
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- activate Purchase Receipt
- Create a Purchase Receipt
Issue:
- the edit tax total is not displayed as it is in Bill
opw-3253060
closesodoo/odoo#117980
X-original-commit: a7706ae581bcdb02fd72035ac67208cb4197a009
Signed-off-by: William André (wan) <wan@odoo.com>
Since the `account` module contains a CoA and is installed before any
other `l10n_` module, the condition `and not self.env.company.chart_template`
was always preventing the installation of a foreign CoA.
By delaying until the registry is fully loaded, we will take the last
CoA declared in the installation stack.
task-3256385
closesodoo/odoo#117944
Related: odoo/enterprise#39452
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
As the number of `account.move`, `account.move.line`,
`account.bank.statement.line` and `account.journal` is growing, the
accounting dashboard, which is the entry point of the app, gets slower
and slower.
There are multiple issues being addressed in this commit:
* The data for each journal is computed journal by journal. This means
that the number of queries run increases linearly with the number of
journals. While the boilerplate around running multiple queries is
negligible compared to the running time of the queries in this case,
some queries take as much time to run for one journal or for many.
To improve this, all the queries are now batched. This has been done
by refactoring the code; all these functions are now called on as many
records as needed[^1]:
- `_get_journal_bank_account_balance`
- `_get_journal_outstanding_payments_account_balance`
- `_get_last_bank_statement`
- `get_line_graph_datas`
- `get_bar_graph_datas`
- `get_journal_dashboard_datas`
* The gap detection and the entries' count are computed fields
(`has_sequence_holes` and `entries_count` respectively). We don't need
to display/compute these fields for all types of journals, but since
they were mentioned by using a `<field/>` node in the view, they were
computed for all journals displayed. Instead of using the `<field/>`
node, we are now setting the value in the `kanban_dashboard` field.
* Documents in foreign currencies on journals in foreign currencies need
to get the rate in order to be aggregated in the journal's currency.
There are 3 cases:
- Document in journal's currency
- Company's currency is the same as the journal's
- Document, company and journal have 3 different currencies
Before this commit, the second case will still fetch the daily rate
for the document in order to do the conversion, but we actually
already know the conversion; it is stored on the document.
Benchmark
=========
On a `populate` database with:
- 4 `res.company` (with accounting enabled)
- 45 `account.journal`
- 19k `account.move`
- 140k `account.move.line`
- 4k `account.bank.statement.line`
- 4 `account.bank.statement`
| Query count | Query time | Remaining time
--------------------------- | ----------- | ---------- | --------------
Before fix | 279 | 0.333s | 0.375s
After fix (without update) | 40 | 0.120s | 0.170s
After fix (with update[^2]) | 38 | 0.100s | 0.170s
Note that the currency conversion was disabled because the populate
database doesn't represent a realistic dataset regarding this. Disabling
it only improves the numbers before the fix.
Note
====
A lot of the time remaining comes from the aggregation of
draft/unpaid invoices with the correct rate done in python instead of in
SQL. This commit doesn't change the behavior but this could be rethought
from a function point of view.
________________________________________________________________________
[^1]: the old functions have been kept for compatibility, new ones are
suffixed by `_batched` and made private if it wasn't the case.
[^2]: some optimization require the views and indexes to be updated
closesodoo/odoo#117964
X-original-commit: 0a386932d2cbcb44cf36c1830422e52b285ae990
Related: odoo/enterprise#39461
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
`res.currency` already has some utilitises like `round` or
`compare_amounts` but until now we always needed to import
`format_amount` from the tools in order to format.
This commit unifies the API.
X-original-commit: 3517a0fece96dd5d0deb02c9fd973444e748986b
Part-of: odoo/odoo#117964
Recently the tax report was updated with new tax report lines, but translations weren't added.
This commit adds translations in FR, DE.
task-3264626
closesodoo/odoo#117962
X-original-commit: 35e5de512eb126bd9a4c7989c8e34c910abcd50f
Related: odoo/enterprise#39458
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Before this commit, even if customer rating is disabled from setting user can
get subscription of task rating.
This commit ensures that only when the customer rating field is enabled, the user can
get a subscription to task rating.
task-323170
closesodoo/odoo#117577
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
How to reproduce
================
1. Load the accounting & any of the modified l10n modules
2. Take any of the languages supported by the selected l10n module
You'll see that all the terms remain in english
opw-3114100
closesodoo/odoo#113572
X-original-commit: 13b619477977254d5cb070d716e0c07f87cb7407
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Happen since 29d55e44
To reproduce the error:
- Settings > Inventory > Enable "Product Packagings"
- Inventory > Configuration > Products > Product Packagings
- Create a new packaging having a barcode
- Start a Point of Sale session
- The session is not loaded and a traceback is raised
Reason:
we try to apply the find() method on an object instead of an array
After this commit, the session is loaded and the packaging is correctly
displayed
closesodoo/odoo#117947
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
project_profitability + change the name displayed in portal
This commit's purpose is to
- add the computation of the AAL for the project profitabity. If a the
analytic account of a project contains AAL that were manually added (
and thus not linked to any sol/purchase/etc ) those lines are not
computed in the 'other costs/other revenues section.
- to display the title of the ticket/task/project in the name of the page My ticket/My task/My project of the portal
task-2960753
closesodoo/odoo#106438
Related: odoo/enterprise#34344
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
the error will occur because when you first add the menu that's menu can not
store in the database without clicking on the save button and that id is
temporary store in string format now you delete that menu and click on save they
try to browse that menu but it is not available in the database and also it has
a string.
steps to produce this error:
1) go to the website and click on 'menu editor'
2) click on 'Add Menu Item' button
3) Add name and URL and click on the ok button.
4) now delete the newly added menu and save it.
So here we can check the id type.
sentry-3931666290
closesodoo/odoo#117937
X-original-commit: 334e13a21dee6cba44aaa4ee79827278a89ab275
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since 5da90dfc4 a test has been added in which
a global readonly variable from `window`
is reassigned.
Furthermore, it is the global "parent" which is
read-only and should nerver be modified.
closesodoo/odoo#117927
X-original-commit: 169a471c7d48891d3295e2b597300425fb145abc
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Since 8fb53c53c3, Order model is no longer
a backbone model therefore, we can no longer call the "trigger" method
on it. Normally, the old "trigger" call means we want to rerender the
screen and persist the new order information in the local storage.
The order object is already setup to do those mentioned (rerendering
and saving to local storage) when it's mutated. Therefore, we can just
simply remove the "order.trigger" and "this.render" calls as proposed
in this commit.
closesodoo/odoo#117915
X-original-commit: 603d73ad8f181a4e5154153cad2cbb18a493b536
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit removes the onCreate param in Kanban, as it is no
longer useful since [1]. It also removes the beforeLoadProm param
and replaces it by an onWillStart option, which is slightly cleaner
(there was no reason for this to be a model param as it is only
used by the useModel hook).
[1] 067bcac533
Part of task 3179751
closesodoo/odoo#117889
Signed-off-by: Géry Debongnie <ged@odoo.com>
Denis Ledoux