- Create a user B with 'Barcode' and 'Security PIN' set.
- Log in the POS with user A
- Scan the barcode
The PIN is not asked and the user is switched.
Closes#20760
opw-781360
Before this commit, when reconciling with a tax included line,
the journal entries were wrong as the amount taken into account was the one that was **already** computed with tax
e.g:
TAX: 20%
amount of the line (tax included): 1
tax amount: 0.17
base amount: 0.83
what was sent to the server was the basea amount, and since python re-computes the taxes
it reapplied tax included 20% on 0.83 instead of 1
After this commit, we send the right amount to the server,
at the small price of semantics change in the meaning of "amount"
OPW 783933
closes#21189
This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
This commit implements the same fix already made in commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df, but this time applied to the tree view of the sale order lines, instead of the form view.
Without this fix, if you add new lines in the sale order by using the tree view (instead of the form) you can get the following error:
```
Odoo Server Error - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: product_id - product.id]
```
The error is because the "product_id" value is not sent to the server. The "product_id" value is mandatory for sale order lines.
To reproduce the issue, you need to reproduce the following scenario:
- create a new sale order and save it
- edit the sale order; you should be able to edit inline the sale order lines (by the tree view)
- create a new product, being sure that the field 'product_id' is readonly (field 'product_updatable' is False).
- try save the sale order
See detailed explanation of the issue in description of commit https://github.com/odoo/odoo/commit/a5ca63c83beafd9a060ac58d3b4c6a9a987b28df.
PR #21211
It seems that Authorize.net returns an 'Error' status when transactions
fail (note that it can also return an Ok status for different types of
failures).
This is incoherent with the way the authorize requests are processed,
since an Error resultCode will raise a ValidationError, rollbacking the
complete cursor transaction. This makes little sense, since there should
be a trace of the payment.transaction in the backend (preferably with an
explanation for the failure).
This fix adds an error processing step to the response handling of
authorize.net - while before, it was assumed that an 'error' result
meant an issue in communication/setup, now it is treated as an error
in payment and the payment.transaction status is set accordingly.
I've added a test for this and it was green (pinky promise), but this
particular test suite is deactivated (or perhaps only on nightly, I need
to check the nightly process with @nim-odoo).
When the result packaged is changed on a move line, we should not change
the reservation of quants, because result_package is not related to
reservation, only package_id is used during the reservation.
We also changed the copy of move_line when we split a move line to put a
part of it in a package. By copying the move line and set the
product_uom_id in the default values of copy function, we mess the
reservation, because there is no quant reservation made for the move
line even if the move_line has a product_uom_qty. So we set the
product_uom_qty to 0 when copying the line, and then write the
product_uom_qty which will call the quant reservation
Fixes#20784
Remove the condition checking that the postal account field of bank accounts only accepts mod10r-verified references, as not all banks use such references (example: UBS).
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
When using this module, the default behavior is to generate timesheet.
This timsheet is linked to a project and a task and there is a
constrain that verify that the task and project are set on model.
If another module (like l10n_fr_hr_payroll for example) tries to
create holidays.status without a project and task, it causes a
traceback.
This commit adds default values for these fields in order fullfill
the constrains.
Notice that the order of the imports in the __init__ is important
because the columns have to be created on the res.company before the
status is initialized.
Example of failing request:
```
rpc.query({
model: 'link.tracker.click',
method: 'read_group',
args: [[links_domain, ['create_date', '>', interval]], ['country_id']],
kwargs: {groupby:'country_id'},
});
```
The RPC request built contains the following:
```
args: [[["link_id", "=", 1]], ["create_date"]]
kwargs: {groupby: "create_date:day", domain: [], fields: []}
```
This will be interpreted server side as:
```
model.read_group([['link_id', '=', 1]], ['create_date'], groupby=['create_date:day'], domain=[], fields=[])
```
2 arguments match `domain` and `fields`, which causes a crash.
opw-781300
- Open an event registration page
- Fill form for 2 persons => redirection to /shop/checkout
- Click Review Order => open /shop/cart
- Change quantity from 2 to 1
- Finish checkout process
- Login to backend, confirm SO
Two tickets are confirmed instead of one.
opw-783945
Usacase to reproduce:
- Plan MO with 2 unit to produce.
- Produce 1 unit
- Update the quantity to 1
-> Traceback
active_move_lot_ids should have been changed to
active_move_line_ids during the forward port to 11.0
from this commit d62b307597
Use case to reproduce:
- Create a BOM with a component product tracked by SN
- Create a MO for this product and reserve it.
- Plan WO and process it.
- Register the same lot than the reserved one.
-> Error message: you can't use twice the same serial number
It happens because WO use temporary move line that should not
be considered as a real object. However it exists is a constraint
that trigger if two move lines share the same SN for the same product.
It's a wanted behavior that a real move line share the same SN that
temporary move lines.
This commit prevent real and false move lines comparaison.
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.
Otherwise, when rendering the 'Product' template it crashes when calling
the 'get_price' method.
Indeed, we need to add products as a Product model instead of as a plain
JS object.
Use case(stock_picking.py):
- Sell a product which has tracking enabled
- Reserve the stock on the delivery order and assign to all stock.move.line a lot/serial, but leave the qty_done zero
- You will get an error message which is not correct
(stock_quant.py)
Give more information about the source of failure
opw:783828
Since odoo/odoo@da136d8 the modifiers in the widget attrs are parsed.
`stringify` thus needs be to used when displaying them in the debug tooltip (to
avoid to display [Object object]).
Before this fix:
A readonly monetary field was not updating
its currency symbol when selecting another currency.
Scenario:
1. Activate multi-currency with $ (default) and €
2. In hr_expense, go to My Expenses to Submit
3. Create a new expense
4. Select 'EUR' as currency
=> Unit Price is correctly updated with €, but not Total.
With this fix:
Total displays the correct currency in edit mode.
Explanation:
Monetary fields in readonly are relying on _formatValue() to
display their value.
_formatValue() uses this.formatOptions.currency, which stores
the currency at loading of the field. We must update its value
whenever there is a change of currency.
opw-783378
Steps to reproduce the bug:
Setup Authorize.net test account, then go to My Account from portal
and select "Manage your Payment Methods" and add a new card.
Bug:
It raised "Please fill all the inputs required."
opw:782716
Suppose some taxes with the same sequence:
The tax are not computed in the same order in POS and SO/INV.
This is wrong in case of multiple taxes affecting the base.
-opw: 779498
The rev. odoo/odoo@93bf26a modifies the way kanban record defines their size.
Kanban dashboards used to define a fixed size and reset it when grouping.
This fixed size should in fact only be set for ungrouped kanban as the column
size is fixed.
With this commit, we add a few extra logs to help debugging issues with
phantomjs.
I suspect that the recent problems with phantomjs are due to the
localstorage not being cleared properly, but the logs are not sufficient
to determine the exact cause.
Some reports displays the wrong partner.vat.
On the invoice report, when the shipping address is different than the
invoicing address, we also also display the shipping address in addition
to the invoicing address. But we displayed the VAT of the invoicing
address instead of the one from the shipping address.
Same issue on the MRP repair report and the sale report.
- Create an expense paid by employee
- Create an expense paid by company
- Select the two expenses and submit a report
You are authorized to create this report but you cannot validate it and
you cannot refuse it because of the mix of an expense paid by employee
and paid by company. You're blocked.
We should block the creation of an expense report mixing expenses paid
by company and paid by employee
opw-783395
Commit f45edfbe6d fixed a bug on image fields
but was a partial fix.
The problem is that while adding field dependencies to fieldsInfo,
it did not add them in the fields of the view, making the view crash.
After this commit, views and subviews contain fieldDependency as both info and actual fields of the view
OPW 780021, 781620, 779649
[FIX] web: tests on many2many subviews
closes#20891
Before this revision, unlinking a module which has been uninstalled at
least once would raise an Exception because base_module_uninstall
contains a field model_id which is required. The unlink method of
ir_module_module would try to set this field to NULL which is of course
a constraint violation.
This is fixed by manually unlinking the respective base_module_uninstall
records before the unlinking of the ir_module_module record itself
Fixes#20720
DO NOT FORWARD-PORT
Nicolas Martinelli