When creating an activity, the date saved will be the choosen one in the
tought in the client timezone.
But when displaying the counts of activities Late/Today/Future, the date
is tought out as the one in the server timezone.
Thus we would have activity today/future/late not corresponding with the
date in the current timezone.
This is solved in this change and follow what was done in 72254129.
A second change is made so the default "Due date" is today in the
timezone and not today in UTC date.
opw-1837894
closes#24554
- Create a bill for partner A of an amount X
- Create a bill for partner B of an amount Y
- Validate both bills
- Select both and register a payment by check.
Two payments are created with the same amount in words: X + Y.
In this specific case, we recompute the amount in words automatically.
note: this commit reintroduce the fix c52b18e65 which was lost after
changes in 10.0 (line was removed then brought back with 416d07f0b).
opw-805842
closes#24569
In a situation where there's a negative quant next to a positive one,
they should be merged when the scheduler runs or when the user open its
inventory view. However, if in the meantime the user reserves and
unreserves, there may be some issues.
The system will only reserve on positive quant ;
the system will unreserve on the first encountered quant (even negative)
The issue is the second part of the early break condition:
float_is_zero(available_quantity, precision_rounding=rounding):
The issue here is `available_quantity`. In a reservation scenario, it
represents the maximum quantity we can reserve across quant. It is
useful so we do not lose time loopin over quants where nothing will be
available. In an unreserve scenario however, it represented the same
thing, which is wrong. In the case you reserved all the quantities,
`available_quantity` will be 0 we'll loop only on the first quant where
we won't do anything.
As the code doesn't check the success or failure of the unreserve, move
lines were unlinked while the reserved quantity on the quants were not
updated, resulting in the desynchronization of the move lines/ reserved
quantities.
This continues the work done at [1] to track down the "cannot unreserve
more than" errors.
[1] cce6030c0d
Assume a one2many field inside a form, displaying field A in its
list view, and a field B in its (dialog) form view. Moreover, there
is an action button in the dialog, which updates the value of B.
Before this rev., B wasn't correctly reloaded when the button was
clicked, because the BasicModel reloaded the fields on the list
view (i.e. field A), whereas it should reload the fields in both
views.
This fix is twofold. First, we force the viewType to 'form' when
the record is reloaded, instead of the default ('list'), so that
fields in the form view are correctly reloaded. Second, when we
open the form view in the dialog, we add the fields of the list
view to the dict of fields of the form view, so that the form
is aware of those fields and can ask the model to reload them
(still without displaying them).
Fixes#24189
When the virtual machine used to build MS Win package takes too much
time (to build or to test the build), a warning is logged and the VM is killed.
Before this commit, the PID of the process was passed as an argument to
the warning method, causing a traceback.
Instead of searching for ids in the whole cache, search for the ones we will potentially prefetch.
Example: imagine you have 1K records in cache, and only 3 records in your prefetch set. Instead of retrieving the 1K records that have a value in cache, retrieve which of the 3 records that have no value in cache.
The precision digit on the produce lines is not set to the product unit
of measure one. That can lead to a lost of precision when a small values
are set in the manufacturing order and not in the produce wizard.
OPW-1838077
When moves of a MO are generated, they are rounded up to the decimal
precision of the rounding, what is not done in the wizard.
So to keep it consistent, we also round up the quantity to consume in
the wizard.
If document viewer is opened from chat window and when document viewer is opened then focus
remains on it's modal, pressing escape should set focus back to chat window's input element,
if file selecor dialog is opened and if user press ESCAPE on file selector dialog to cancel file selector
dialog then it should not close chat window instead it should set focus on chat window input and on
second ESCAPE key chat window should be closed
also increase z-index of document viewer dialog so image remain on top of cht window
OPW: 1777937
When an internal locations has its `scrapped` field set to True,
reserving will increment the quant's `reserved_quantity` while
unreserving will bypass the reservation mechanism (as in a supplier
location). This leads to a desynchronisation between the
partially_available/available move lines and the quant's
`reserved_quantity`, leading later on to "cannot unreserve more than
available" errors.
To prevent this kind of issues, there's a `should_bypass_reservation`
method set on the location that we *should* use everywhere, it was
implemented by [0]. Sadly, this line was not adapted since its
implementaton in [1].
Co-authored by len-odoo <len@odoo.com>
opw 1837900
[0] e1cea2640f
[1] 0469d2e712
This constraint was added during the Great Accounting Reform of v9, in
an attempt to help users avoid reconciliation mistakes.
It turns out that such mistakes are difficult to make in normal
situations, since the system only offers matching entries to reconcile,
so the constraint is largely redundant.
On the other hand, it does block legit cases of reconciliation,
such as those where a large number of lines with different partners are
reconciled together. This often happens when reversing a Journal Entry
that encompasses multiple customers, such as a POS closing entry, or a
manual entry.
To make the system more flexible, let's consider that when a manual
reconciliation breaks the "single partner" rule explicitly, it's for a
good reason, so we should allow it.
OPW: 1840437
When creating a transfer from:
Dashboard > Planned Transfer
The scheduled date is not configurable as explained in commit:a57a290bd89bee0c50c9c1b03e7185c0497e89ed
opw:1838620
update_goals is called through the 'Run Goal Challenge Checker'
cron, potentially on a large amount of goals.
With self containing ~400k records a worker has been observed to use
~3.4 GiB. With sensible memory limits this will probably cause the
worker to be killed.
To avoid this turn of prefetching in this initial loop. Performance
shouldn't be affected too much because in the following loop
prefetching for goals will still take place per definition.
opw-1840666
These translations were for the first company only ('1_' part)
The process_translation part in l10n_multilang is enough to propagate the
translations of the templates to the accounts
- Set the system parameter "stock.propagate_uom" to 1.
- Create a Sale Order with a product (1 Dozen).
- Confirm the Sale Order
- Validate the stock picking with 1 Dozen of quantity done.
- See the stock move form.
The value of the stock move is the price unit and not the correct value
because the amount is computed by the quantity_done (1) and not
12 Units.
Closes#24352
opw-1838335
- 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
- Create a product with 2 variants (e.g. black and white)
- Create an invoice with one of the variant
The description doesn't contain the attribute name, as it would be in a
SO.
This is because the invoice uses `partner_ref`, which doesn't include
the attribute name.
opw-1839598
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).
Have a nginx set up with HTTPS (and the web.base.url too, obviously)
HAve a multilang website
Call a slide with the https domain with the non-default lang in the path of the resource
[https://domain/fr_FR/slide....]
Before this commit, when the iframe src is requested for by the browser
the python will transform the url of the iframe by injecting /fr_FR/
When the request for the *content* of the iframe is actually fetched by the browser, there is a mixed content
(though in the SAAS case and through cloudFlare for some reason)
After this commit, since we explicitly form the iframe src with lang, there is no error of mixed content
OPW 1839308
closes#24445
Since these server actions are triggering python code, their 'state' field must explicitely be set to 'code'.
Currently it is taking default value for 'state' field which is, since saas-15, 'object_write' and thus not working as intended.
Was PR #22706
Was task: 1813998
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.
Nicolas Lempereur