On existing databases, the SQL not null constrain is not removed, making
the creation of new assets impossible. This is because a computed field
is not inserted at creation, but written afterwards.
This reverts commit 0c76bd3c63.
opw-1840661
Have a One2Many
The views of that o2m define two inline views: the list and the form
in the list view, put a field that isn't in the form and used in a domain
Try to add an item to the list
The form pops up
Fill in the data and save & close
Before this commit:
It crashed when evaluating the domain on a field using the field that is not in the form
After this commit:
Subviews share their fields in a special object on the parent record
In our case, the form view checks in that shared resource if the fields it is supposed to initialize
are there.
Hence, this flow doesn't crash anymore
OPW 1837511
closes#24350
The way the calendar view selected its form view was broken for two
reasons:
- any value given in the form_view_id attribute was kept as string,
which means that the string value would be sent to the server, and
this is not good.
- if no value was set, the calendar view then simply did a do_action
with the form view id set to false, which means that the default form
view is used. This is mostly ok, except when we are in the context of
an action with a form view which is not the default one. In that
case, we clearly prefer the form view from the action.
For example, before this commit, the form view in the timesheet
application (community) is not the same as the default form view on
account.analytic.line.
Note that this commit also adds a small tweak to the mock server to
better simulate errors like the web client does (in session.js).
Having boolean checkbox in an editable list
Before this commit, the checkbox was disabled, thus not clickable
The user, who probably expects to click on it to tick/untick
was thus misled, and needed to click *outside* the checkbox in order to activate the row
and only then tick the checkbox
After this commit, the behavior is as expected from the editable list point of view
clicking anywhere in the row (inlcuding on the checkbox itself) activates it into editable mode
OPW 1836067
closes#24292
Have a partner with company_id = False
Your user is currently in company A
Before this commit, only FPs with no company id could be set on the partner
After this commit, FP without company or belonging to company A are available
The drawback is that since this computation takes place in an onchange, when you first arrive on the partner
no filter is applied and you can choose whatever FP that appear
This might cause access errors when it is misued
related to #24256closes#24507
Before this commit, it wasn't possible to use a barcode scanner
with the Odoo mobile app.
However it works fine for mobile Chrome browsers.
We now know that 'keypress' event doesn't work as expected in
Chrome for mobile. See @3a74afd21
It's why 'keydown' detection has been implemented.
We also want to use this detection in our Android app.
Unfortunately, 'window.chrome' doesn't seem to exist anymore
in the Android webview.
In this commit, we change the way Chrome is detected.
Before this commit, you were automatically redirected to the top of
the page when you scanned a product.
It was, therefore, difficult to find the product that had just been
scanned and to check its quantity.
Because of @3a74afd21 we need to put the focus in an invisible input
at the top of the page.
This input is now always vertically centered in the middle of the page.
The error before this pr could be reproduce with the steps,
- Create two warehouse WA and WB
- Create Route to get: Purchase in WA and transfer to WB
- Create product with Route created before
- Create orderpoint to WB
- Run scheduler
If there is no purchase created the `_run_buy` method tries to create a
PO, but if there is no `group_id`, a traceback occurs.
Closes#24353
opw-1838384
- Set a specific expense account on an expense product
- Send an email to the expense alias
The specific expense account is not used; a default account is used
instead.
opw-1838174
Do not try to keep the reservation when creating a backorder for two
reasons:
1) it doesn't make sense since the backordered move will only be
confirmed while it got some reserved move lines
2) with badly configured uom's rounding, it is possible that the
initial demand of the backorder is inferior to the now reserved
quantity
We also fix another "cannot unreserve more than available" cause that
could happen in the second case ; let's imagine in the second case that
the backordered quantity is 0.999, `_update_reserved_qty` will reserve
0.999 on the quants but do not create a move line as range (0, 0.999)
will not return anything.
We remove `test_split_1` as it tested a behavior we removed and add a
new test showing a new flow with what we fixed.
Please note that setting the rounding of unit to 1.0 would have
prevented all the issues here.
Followup of rev 383947646f
Let's say you have 6 units and you try to reserve a dozen while the
rounding of the dozen is 1.0. The previous commit correctly only allows
to reserve 12 units, and handle correctly forced quantities in other
compatible UOM, all that with extra moves/backoders.
But we missed an important issue: if now you have 12 units, you will
reserve them. If these 12 units are split across quants, i.e. some are
in another sublocations or are assigned a special lot_id, then we'll
again have rounding issue because the reservation was always expressed
in the move's uom while sometimes it is not possible to go back and
forth between the move uom and and the product's uom. In other word,
we'll reserve 12 times 0 dozen and get stuck at the next step.
This patch now only reserve a quantity if the quantity is expressible in
the rounding's UOM. If this quantity is split across multiple move
lines, we'll make the move line reserved in the UOM of the quants if
necessary. We also do not apply the rounding down -> halfup dance if
`_update_reserved_quantity` is called with the force argument set as
True (meaning, in an mto scenario). The change in
`_prepare_move_line_vals` will make the move lines in the uom of the
qants and everything should be good. With the last change, we need to
adapt the test added by the previous patch, else we won't be able to
make a chain of 2 move moving producst tracked by serial number if the
rounding of the dozen is set at 1.0.
opw-1835186
opw-1835946
When computing the amount of the anglo saxon entry, if it's a vendor
bill only consider IN move, if it's a credit note only consider out move
(the returns).
opw-1819353
- Set up Paypal as described in
https://www.odoo.com/documentation/user/11.0/ecommerce/shopper_experience/paypal.html
- Buy a product on the eCommerce.
The vendor might receive an email mentioning that Instant Payment
Notifications (IPN) are failing.
When completing the paypent process with Paypal, 2 confirmations of the
transaction will occur. The first one is through the route
`/payment/paypal/dpn` (Payment Data Transfer (PDT)), which takes place
right after the payment validation. The second confirmation comes
through the route `/payment/paypal/ipn` (Instant Payment Notification
(IPN)), which might arise with some delay (and potentially being run
several times).
Both confirmations will trigger the method `_generate_and_pay_invoice`,
which can raise an error if no invoiceable line is found ('There is no
invoiceable line.' in `sale` module). In this case, we should log the
error and move forward instead of crashing and stopping the workflow.
More information on PDT and IPN at
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNPDTAnAlternativetoIPN/
opw-1837196
In case of changing the quantity on hand of two variants of the same product,
the two message created will have the same name (the name of the
product.template).
Show the name of variant instead.
- When a quotation if viewed by a customer, a note is posted in the quotation's chatter saying "Quotation viewed by customer".
This is causes issues if the quotation is accessed without the access token and by a partner that do not have the rights to write on the model "sale.order".
To address this issue we provide to the "_message_post_helper" function the sale order's access token to bypass the accesses checks.
OPW-1839183
When validating a delivery order with automated inventory,
some accounting moves are created.
Since an inventory user might not have accounting rights,
the validation of delivery orders might fail.
We simply had a sudo when in the internal method creating the move.
Moreover if the inventory valuation is set in FIFO,
the product price might be updated.
It might fail for lack of additional rights.
We add a sudo for this price update.
opw 1836761
When validating a delivery order, some stock moves might be merged by an
internal function, which thus might delete some stock moves.
Since an inventory user has no right to unlink stock moves,
the validation might fail.
We simply had a sudo when doing the unlink, since this is an external method.
opw 1836761
Commit 542201eed3 added the possibility to configure a set of countries for a
given payment acquirer.
Commit 194d52e8fd refactored the payment form, but forgot to take the country
into acount.
opw 1837819
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
Remove behaviour introduced by [1], if there's a price difference the
price difference account will be used. This code block did not take into
account the fact that out move have a negative price unit, resulting in
inverted debit/credit. Furthermore, there's no special case for return
of standard and fifo.
[1] 1df16a189e
opw-1828196
- Set a default value for the field 'Activity Type'
- Schedule an activity
The default value doesn't appear.
The default value is taken into account, but the onchange override the
value.
opw-1838066
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
Steps to reproduce the bug:
- Create a stockable product P
- Create PO and confirm it
- Cancel the PO
- Reset the PO to Draft and reconfirm it
- Validate shipment order
Bug:
- The "Receive product" button is still displayed but every shipment orders of the
PO have been treated.
NB: The field is_shipped is only used to display the button "Received product".
opw:1838539
It was possible to change manually the company of an asset, although its category would be belonging to another company and thus its depreciation lines and journal items also.
To tackle this problem, we set the company_id field of an asset as related to its category
Was PR #23498. Courtesy of Miquel Raïch
When in Python 3, then function `open` defaults to open the file in text mode
with and the encoding (if not passed) is taken from
`locale.getpreferredencoding`.
Using `getpreferredencoding` is not necessarily a good practice. Because
files might no be encoded that way.
When testing Odoo not in runbot (which has LANG set to C.UTF-8) you may get:
Traceback (most recent call last):
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 24, in test_check_suite
self._check_only_call('web.qunit_suite')
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 37, in _check_only_call
if RE_ONLY.search(fp.read()):
File "/home/gitlab-runner/virtualenvs/odoo11-MlnlRiTaP2/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4757: ordinal not in range(128)
The proposed solution is to read the file in binary mode, and decode to
unicode/str ourselves using utf-8. We don't use the encoding argument of
`open`, so that the code works in both Python 3 and Python 2.
PR #24434
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
Usecase to reproduce:
- Create a product A with a qty on hand 5.5
- Create a delivery order with an initial demand of 5.5
- Validate it with a qty equals to 5.95
The initial demand is updated to 5.951 then reduced to 5.95
and a backorder is created with an initial demand of 0.001.
That should not happen since I process extra quantities.
It python 5.95 - 5.5 = 0.4500000000000002 and the float_compare
use a round UP method thus it returns 0.451 and the following
flow is based on a wrong value.
In this case a float compare is used before the float round, so an
HALF-UP rounding should be okay since a very small quantity diff should
be filter by the compare.
Fixes#24401
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
When a scrapped move is part of an open picking, it was not possible to
unreserve the picking. A scrapped move is done and scrapped ; this
combination should be allowed.
opw-1835186
- Create the following reconciliation model:
Line 1 is 50% of amount, tax is 20%
Line 2 is 50% of amount, tax is 0%
- Use this reconciliation model to reconcile an amount of 1000.
4 lines are created:
- 2 lines for base amount (500)
- 1 line for the 20% tax (100)
- 1 line for the 0% tax (1000)
Obviously, the last line is incorrect, and should be 0.
opw-1837049
The calculation of the delivery cost for a sale order / invoice was not correct when
free over a limit had been satisfied.
Steps to reproduce the bug:
- Set a delivery method DM with a fixed price = 10.0 and free when the amount of the order exceeds 100
- Create a SO for an amount of 150 and set on it DM
- Confirm the SO and deliver it
Bug:
A SO line with DM was created with a fixed price of 10.0 instead of 0.0
opw:1838070
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
If the user has limited_access, download_security field was not read due to the
override of check_field_access_rights and so the field not set.
When you try to access/read it, you got: Selection is not iterable.
Now we check in sudo the download_security.
We also add the **kw that should be present in all routes.
Avoid: "slide_download() got an unexpected keyword argument 'debug'"
We also remove this controller from the sitemap.
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
When a user creates a new column in a kanban view, leave the action and
comes back, the order is not preserved. With this commit, we force a
call to resequence to ensure that the order does not change.
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
Nicolas Martinelli