When creating a job position from the frontend, and we:
- are on the same language that the default website language,
- have the permission to write on ir.ui.view,
we have all conditions to adding branding used to edit a page.
But when creating a position by the frontend, we create a job that will
render this template:
website_hr_recruitment.default_website_description
When we are in the above said condition, we will create a job position
that erroneously has the branding that should only be displayed on
website and removed when saving an edition.
This caused a lot of problem with the editor that would most often not
be able to edit the content.
In this commit, we use the "rendering_bundle" context key to prevent
branding.
opw-1868879
closes#25963
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
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
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
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
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
The resequence mechanism works if the sequence is sorted by its handle field.
Therefore sorting on another field should lock the handle, while sorting on the
handle field should unlock the handle.
opw 1867049
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
- Set a product with real-time valuation
- Create a SO, select the Drop Ship route
- Validate the SO, the PO, and receive the picking
=> an accounting entry is created
- Return the picking
The reversed accounting entry is not created.
This is because the return of a drop ship picking is not recognized as
some kind of dropshipping.
opw-1879117
On a website page, click on promote and add the keyword "DS1517"
before this commit, the javascript froze
after this commit, it doesn't freeze
OPW 1880341
closes#26771
- When checking if a recipient has already received a mass mailing, the
record model for the recipient was not checked.
Which leads to false positives.
Christophe Simonis