VAT number should be readonly when parent_id is set
This is already what is done in base.view_partner_form and
base.view_partner_short_form
closesodoo/odoo#28190
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
Spamming the "send" button on the chatter send multiple times the
same message. This PR simply disable the send button to fordib the
spam.
opw-1895511
closes#27233closesodoo/odoo#28078
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
The field residual_company_signed must be positive for out_invoice and in_refund and
negative for in_invoice and out_refund. In this way, the correct writeoff amount
can be computed in function _create_payment_entry.
PS: In function _compute_payment_amount, the field residual_signed and residual_company_signed
are already signed, that's why it was wrong to multiply a second time on it with MAP_INVOICE_TYPE_PAYMENT_SIGN
opw:1893570
closesodoo/odoo#28148
It appears that chrome headless with sandboxing is failing when running
containerized because it tries to use Linux namespaces.
With this commit, the no-sanbox optional arg is used to avoid this
issue.
Closes#26456Closes#28053
Before that, when receiving, then invoicing with price diff, the value in interim account corresponded to the price on the invoice instead of the original valuation one.
Scenario to reproduce the issue:
* create PO with 1 product, FIFO valuation, price=10
* receive PO: the entry in stock interim account has debit=credit=10
* create invoice, with price=15 instead of 10
* the invoice entry should be: payable: C=15 ; price diff: D=5 ; interim account: D=10
==> Instead, we had payable: C=20 ; price diff: D=5 ; interim account: D=15 => this was wrong
Also added a test case for the same scenario, verifying the amounts written in the different accounts (and refactored a bit ValuationReconciliationTestCase for easiness)
Closes#27394
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
opw-1883693
- Create 2 Products A and B, tracked by serial number
- Create a BOM for A:
1 Unit of B
- Create a MO for 2 Units of A
- Validate:
Product with S/N A1 consumes B1
Product with S/N A2 consumes B2
- Unbuild A2
If A1 was created before A2, B1 will used as a component of A2 at
unbuild.
When going through the stock move lines, we don't verify that the lot
produced matches the lot we unbuild.
opw-1889002
closesodoo/odoo#28154
before fix:
in firefox the textarea of note modal has a overflow
textarea can be expanded outside borders modal in all browsers
closes#25199closes#25215
issue 1895298
If the search returns more than one result, the rendering of the message would
crash (SingletonError when accessing check_in field value).
Use the same order and limit as both search before and after
Courtesy of David Tran
Closesodoo/odoo#28055
before this fix it was not possible to connect to the pos/iot-box using
https on the pos. By checking if the pos is http or https this is now
possible after accepting the certificate.
if https scanning for proxy is disabled, the user should always give a
ip in the configuration
Apparently missed in 07ab8b6cd2
In Python 3, there is no Exception.message attribute anymore, this would
lead to cascading exceptions in the stripe_s2s_create handler.
closesodoo/odoo#28141
1. Product A - on stock 5 pcs.
2. SO - 7 pcs. of A
3. Generated picking has reserved 5 pcs.
4. Increase stock to 7 pcs. (Update qty on Hand)
5. Run procurement scheduler
6. Picking still has reserved 5 pcs.
The scheduler should take into account the moves partially available.
Fixes#27874
opw-1895622
closesodoo/odoo#28136
In a multi-currency company, the delivery price of a quotation was
wrongly converted when the currency used by the pricelist was not
the same as the currency used by the company.
This PR correct that behavior by correcly compute the delivery
price according to the pricelist currency.
To reproduce:
1) Install the accounting, sales and delivery modules
2) Set the company as a multi-currency company in the accounting
settings
3) Change the currency rate so the one used by the company is 1
and the other one (the one that will be used on the pricelist)
is anything else than 1
4) Create a pricelist with that other currency
5) Create a quotation using the new pricelist, select a deliver
6) Click "Set Price", the delivery price shown on the form isn't
the same as the price on the quotation.
opw-1894422
Use case to reproduce:
- create a BoM of 50 finished products:
- Add a routing with an operation time of 1h
- Set a 1$/h cost on workcenter
- Set unit price from BoM
It will be 1$ for one product. It should be 0.02$
since it will take 1h for 50 products, so the price
should be 1/50
It happens because the system add the operation time by unit instead
of adding it only once.
related to commit 17b6256955
opw-1890005
Before this commit:
If an user has multiple session on a database (eg: he is connected both on his
smartphone and his laptop on the ecommerce), and there is a cart in these
session, confirming the cart on one of the session will make other sessions
unable to use the checkout anymore.
This is because other sessions will still contains the Sale Order that is now
'sent' and updating the cart will raise an error:
`It is forbidden to modify a sales order which is not in draft status.`
Now:
If the SO to be updated is not in `draft` anymore, we create a new one.
Step to reproduce:
- Login on ecommerce from device A
- Add product in cart, the SO will be added on session
- Login on ecommerce from device B
- Pay the cart (it will retrieve the SO from device A)
- At that point, the cart is paid and the SO is removed from session on
device B but other devices won't be able to use the checkout anymore
as they still have the SO in session which is in `sent` state.
Thus, any action on cart will raise the error
Note:
1. We can't implement that behavior in `sale_get_order()` as it is supposed to
return SO in `sent` state after checkout.
2. We can't implement that behavior in `_cart_update()` as it is inherited in
some module. Thus, implementing that behavior in `cart_update()` would change
`self = order` but inherited methods would still have initial `self`.
3. Implementing the behavior in the controller it is already done (differently)
in `cart_update_json()`.
Fixes#27508, closes#27794
Spamming the save button when creating a new custommer in point-
of-sale create duplicate users. This PR disable the button once
clicked and re-enable it when all the processing is done.
opw-1895302
close#23919
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
Robot Odoo