Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.
In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.
Step to reproduce:
- Start odoo in dev xml
- Install website app
Related to #27199closesodoo/odoo#27210
- Create a project
- Create some tasks with followers
- Create an outgoing mail server with active = False
- Copy that project
When copied, the project tries to send emails to followers using the
inactive mail server. This leads to a traceback.
The addition of the context key dates back to 2009 with 853789d0aa.
The purpose was to copy all tasks, including the archived ones.
We keep this behavior, but without propagating the `active_test` during
the copy of the tasks.
opw-1887354
closesodoo/odoo#27192
Steps to reproduce the bug:
- Create a picking
- Create a line with product "A"
- Validate Picking
- Duplicate Picking
- Add a new line for product "A"
- Validate Picking
Bug:
A missing error was raised.
PS: The function _action_done on model 'stock.move' calls the function _action_confirm
where some stock.move records could be unlinked by function _merge_moves
But the recordset was not updated afetwards.
opw:1885053
closesodoo/odoo#27209
- Set the Outgoing shipping of your warehouse to pick + pack + ship
- Create a SO with a stockable product and validate it
- Set the qty done to 1 in the ship and validate it
- Cancel the pack
Bug:
It was impossible to cancel the pick.
opw:1887098
closesodoo/odoo#27193
Commit dc1681b1 did change the name of the inventory creation from
direct qty update, but test still tries to compare the product.name
closesodoo/odoo#25948
In 11.0 7e724f96c5 is_product_variant has been introduced back (it was
removed in 10.0 b747b05fa). But related of _inherits are computed on the
related model so is_product_variant would always be false.
Without fix, added test fails with:
AssertionError:
Items in the first set but not the second: True, Items in the second
set but not the first: False, Product variants are variants
fixes#26961
related to opw-1814973
closes#27163
Before this commit, if you create an automated action with trigger 'on_change'
it was not called because the run() function don't have active_id.
Now if we have onchange_self in the context but not active id, we call the
function nevertheless. (withtout active_id in context!)
closesodoo/odoo#27167
- Create a Customer location (CL) and set a Company on it
- Configure Product A in FIFO / Perpetual
- Receive 2 Unit(s) of A in Stock
- Create an Internal Transfer
1 Unit(s) of Product A
Source location: Stock
Destination Location: CL
- Validate
The Inventory Valuation report incorrectly retrieves a quantity of 2 in
stock instead of 1.
The error is first due to a misconfiguration: the CL should not have a
Company set. However, we should not take into account any quantity in a
customer location, even if there is a Company set.
opw-1884675
opw-1884835
closesodoo/odoo#27145
Make sure that the company is not set on the customer and supplier
locations of the demo data. Otherwise, any quant in these locations will
be set a `company_id`, which is incorrect (e.g. valuation report will be
incorrect).
opw-1884835
closesodoo/odoo#27144
In ac1e187ee some unecessary code and RPC were removed by ignoring
attachments in the sidebar when they would never be shown.
But there was an regression since `updateEnv` function would not
longer call redraw (which is also called in _super function).
report: https://github.com/odoo/odoo/commit/ac1e187eea3#r30569171
related to opw-1865736
closes#27146
- Open a partner view, click on Action > Partner Review
- Switch to another partner
- Click again on Action > Partner Review
The Google Doc file of the second partner is the same than the first
partner.
This is due to `_onGoogleDocItemClicked` which is always called with the
same `resID`, i.e. the `resID` used at `start`.
We retrieve the active ID at each click instead.
opw-1882068
closesodoo/odoo#27132
Activate the group in the sale module: Sections on sale orders
Print an invoice
Before this commit, there were twice the same table filled with the invoice lines
After this commit, only one table and the right one is printed
OPW 1885549
closesodoo/odoo#27137
Steps to reproduce the bug:
On a new db, just launch:
./odoo-bin --addons-path=../enterprise,./addons --test-enable -d s11 -i l10n_be,account_accountant,stock,sale_management,purchase
An error occured in test_02_check_mto_chain due to the supplier taxes set on the product.
opw:1878341
closesodoo/odoo#27069
We clarify the `stock.quant.package` view to highlight the difference
between the case where the content is retrieved from the move lines or
the quants.
Otherwise, this is confusing for a user who sees the same record with
the same view, but not the same content.
opw-1883714
closesodoo/odoo#27098
Use case: have a partner in fr_FR while operating with a user in en_US
Create a SO for that partner
add a product which name is translated in french
Before this commit, the description of the sale order line takes the
*untranslated* name of the product
After this commit, it takes the *translated* name of the product
The issue was due to a limitation of sudoing within an onchange for related fields
(typically the case of product.product.name)
In this case, values that are missing in the cache are retrieved from another one
In our case:
First, _onchange_product_id_check_availability triggers the evaluation
of product.name as sudo (later in the stack), without lang in context
Second, the function that actually uses the product.name (product_id_change)
retrieves the value found before from the 'wrong' cache
OPW 1863305, 1884106
closes#27031
- Create a PO with 5 units of A and 10 units of B
- Receive the products
- Return the picking, but return 12 units of A and 10 units of B
The first picking (done state) will contain:
- 7 units of A, 0 qty done => it is an extra move
- 10 units of B, 10 qty done
But another picking (not done) is created, with
- 5 units of A, 12 qty done
The core of the issue is that the `origin_returned_move_id` is not
copied on the extra move. Therefore, it is not merged by `_merge_moves`
since the latter field is in the list of
`_prepare_merge_moves_distinct_fields`.
opw-1882959
- Set the product A in FIFO, real-time valuation
- Receive 5 units @ 2000 each
- Create a landed cost of 1000, apply on the picking
=> the cost of A is 2200
- Sell one unit
- Create another landed cost of 1000, apply on the same picking
The cost of A is 2360, while one expects 2400.
The value of the move after the second landed cost is computed as:
value = previous value + prorata of landed cost 2
= 11000 + (1000 * 4/5)
= 11800
This is not correct. The whole value of the second landed cost should be
taken into account for the `value` field. The prorata is only useful for
the field `remaining_value`.
opw-1878229
When localisation modules such as l10n_no are installed, the test
TestAngloSaxonCommon broke.
We isolate the test more by setting the right accounts on the products to make
the test pass.
This is useful for odoo.sh clients that install localisation modules and see the
tests break.
opw 1881014
When a sale is done on the website, a corresponding sale order is created in the
backend. By default the salesperson and sales team associated to the sale are as
defined on the website.
When we prepare values, we fallback on the partner sales team in a way that is
coherent with the way it falls back on the partner for the salesperson.
opw 1882640
Fix on sale_coupon (enterprise) https://github.com/odoo/enterprise/pull/2224 needs this change to be able to merge
SO lines when a program generates multiple discount lines on different taxes.
Closes#24971
task-1866977
task-1832967
task-1857843
Have the main company (A) with the public user
Have an invoice in company B
Make a brand new browser access the invoice with the token
Before this commit: the token link ended up asking the customer to login,
eventhough it wouldn't if the invoice were in company A
After this commit: the whole payment with access token flow works as expected.
OPW 1879999
closes#26744
When sorting by a many2many fields (e.g. partner_ids) with one of the record
having an empty value on the sorted field, the comparison method used to compare
and empty record (e.g. res.partner()) and a name_get result (e.g. "Agrolait").
This is because the sort_field was initialized with the result of self[field]
but never assigned a new value below.
Fallback on an empty string when no record is found
Fixes#26908
Clicking the config labels don't toggle the checkboxes, instead show
dropbox menus (at the upper left screen) for the hidden field when
the checkbox is inactive. This modification toggles checkboxes correctly.
OPW 1884452
Usecase:
* Activate price control on point of sale.
* In pos session, as administrator, activate pricechange modus.
* switch to normal user.
Before fix normal user can change the price.
After fix the modus will automatically switch to quantity.
Steps to reproduce the bug:
- Create a journal "Temporary" with default account
(don't care about the names) with Fixed asset type and reconcile = True
- Create a vendor bill
- Create a payment from this vendor bill in the temporary journal
- Create a bank statement and with a line where you specify the vendor
- Try to reconcile the temporary account with the bank account
Bug:
Impossible because the temporary account item was not displayed
opw:1884376
- Create a partner in Germany
- Set an invoice address for this partner in Poland
- Create an invoice for the Poland address, but the delivery to Germany
- Validate invoice
The Intrastat reports the transaction in Poland, while it should be
Germany.
opw-1878590
Since https://github.com/odoo/odoo/commit/4330ea02676a4afd88707bb463a007e7de3c8686, action_mark_won was
not api.multi anymore, which made it impossible to mark leads as won in
batch.
The problem is that we do exactly this in the demo data.
As we need to keep the rainbowman in the interface the decision has been
taken to split the method in two parts, one for the interface which
returns the rainbowman (and uses ensure_one) and the second which is a
true api.multi method.
Thanks to @tde-banana-odoo for his advice on the matter
cherry pick of 634de21b76
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
opw-1874349
Hardening of commit:995610c065bf0242cb5023cfad2940234395739e
The JournalDashboardGraph requires nv, which is lazyloaded.
However it requires nvd3.js which is loaded after nv.d3.js.
A function called in destroy is defined by nv.d3.js,
which can make the crashhappen with the right (wrong) timing.
opw 1873749
Romain Derie