On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
Commit a3c9c286cc made stripe.js more generic. By doing so it also fixed the
`provider_form.innerHTML = data` that was not doing anything since
provider_form was not a dom element.
For orders on /my/orders/XX, the `return_url` was /my/orders/XX before going
through stripe.js.
stripe.js would then call `/pay/sale/XX/form_tx/` that would return new
acquirer form values that should replace the old ones, including a new
`return_url`.
But since `provider_form.innerHTML` was undefined, the old data would remains.
With commit a3c9c286cc the data is now correctly replacing the old ones.
The `return_url` is now /my.
So when an user pays a SO, he is redirected to the portal root page instead of
the SO he just paid with a confirmation message (like it was the case before
the stripe.js improvement).
This fix ensure that the user is still redirect to his SO, by redirecting to
/my/orders/xxx and not /my.
res.currency's `_convert` expects a record not an id.
On res.currency:
_convert() calls
_get_conversion_rate() which calls
_get_rates()
_get_rates does company.id.
Both features already existed but it was not possible to enable both.
This makes that possible. When both are enabled the quotation first has to be
signed, then it can be paid.
Purpose
=======
No way to combine digital signature and online payments to confirm orders.
A customer signature matters for big deals, in order to keep an official print
of customer agreement.
Specs
=====
- when the customer signs online, a new pdf is generated with the customer
signature on it and posted as a note in the chatter, replacing the current
signature jpg.
- show the signature in the portal view, with both sale_management and
website_quote module
- change in settings: Digital Signature and Electronic Payment are now 2
checkboxes instead of a radio button
- these settings must be company-specific (add company icon if multi-companies,
like other company-specific settings)
- when both modes are activated, it first request the signature, then the
payment
- the order is confirmed after payment
opw-1818837
Closes#24174
The funny self.$('#o_portal_sign_accept') line was some leftover
debugging code. It doesn't actually match anything, because that
element is not in self.$el.
Before this change nothing happened when you clicked the button and an
error occured.
Now the `data.error` message (e.g. 'Invalid Order') is shown near the
bottom of the dialog.
When updating the reservation of an partially available or available
move line, use the current record of the loop and not the whole
recordset.
Closes#25445
The CSS of reconciliation highly uses `overflow: hidden` to hide
elements, but this cut the bottom part of the "Select a Batch Deposit"
list of deposits.
There is no possible overflow in this situation anyway, since in the
given circumstances the `max-height` is set to none.
opw-1859408
closes#25524
In some undertermined circumstances, a `KeyError` might appear in:
https://github.com/odoo/odoo/blob/f9737d79e77e9abf634c8eaa4b6ea331e2aa814d/odoo/models.py#L4898-L4904
Despite the lack of reproducible use case, it seems that this was
introduced from 59b010ac36. In the meantime, other
optimizations were introduced in the prefetching of related fields, and
it seems that the fix is not necessary anymore.
Running the same script than described in
https://github.com/odoo/odoo/issues/19536#issuecomment-333118947 , we
observe the following performances:
Before the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.306
On change with 20 lines (10 new, 10 existing) took 0.221
On change with 30 lines (10 new, 20 existing) took 0.208
On change with 40 lines (10 new, 30 existing) took 0.271
On change with 50 lines (10 new, 40 existing) took 0.306
On change with 60 lines (10 new, 50 existing) took 0.319
On change with 70 lines (10 new, 60 existing) took 0.354
On change with 80 lines (10 new, 70 existing) took 0.382
On change with 90 lines (10 new, 80 existing) took 0.506
On change with 100 lines (10 new, 90 existing) took 0.503
```
After the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.238
On change with 20 lines (10 new, 10 existing) took 0.259
On change with 30 lines (10 new, 20 existing) took 0.250
On change with 40 lines (10 new, 30 existing) took 0.233
On change with 50 lines (10 new, 40 existing) took 0.287
On change with 60 lines (10 new, 50 existing) took 0.325
On change with 70 lines (10 new, 60 existing) took 0.345
On change with 80 lines (10 new, 70 existing) took 0.451
On change with 90 lines (10 new, 80 existing) took 0.496
On change with 100 lines (10 new, 90 existing) took 0.423
```
The fix doesn't seem to be necessary anymore, so we go back to the
previous implementation of the computed field.
Closes#25448Fixes#19536
opw-1861468
The method 'action_done' on inventory adjustment became private and the
action launched from the view is now 'action_validate', so we adapt
those tests to use the new function.
TASK-30921
When you have some product tracked in an inventory adjustment, the
lot/serial number is not required, so when you confirm an inventory
adjustment with product tracked for which you didn't provide serial/lot
number you get a warning to inform you.
TASK-30921
The constraint avoifding ot have two inventory lines with the same
properties was only triggered in the create, we make it work also in the
write.
TASK-30921
When you create a inventory adjustement line, you can create new products,
but you don't really want to create products in the inventory adjustment.
TASK-30921
When the update quantity on hand is clicked on a product tracked by lot
or serial number or if the database is in multi location, the button
update quantity on hand will open an inventory adjustment to allow you
to add multiple lot/serial number and/or choose the lopcation in which
you are updateing quantities
TASK-30921
Before this commit, something strange could happen after reloading a
settings form view: all 'sections' were displayed. The issue was caused
by the fact that the state of the view was read from the arch of the
form view at render time. Also, as a form of optimization (I suppose), the
settings did not call the initModules method twice, when it rerenders.
This is unfortunate, because the very same method is actually
responsible for removing unused sections.
This fix is the safe fix, but definitely not the perfect fix (this would
involve a larger change, something like reading the state from the arch once in
the view (factory), then only rendering what is necessary).
In the discuss composer on google chrome, when when the smileys have
more width than available, they stayed on one line and would increase
page size (adding an horizontal scrollbar).
This happened really easily in saas-11.3 because we have more smileys,
but still happened in 11.0 depending on the screen size.
opw-1861191
closes#25507
Co-authored-by: qsm-odoo <qsm@odoo.com>
When computing a salary sheet, a maximum recursion error could happen if there
is a cycle in the rules or in the categories.
Add constrains for salary rules and categories.
Closes#25405
- Store a token inside sessions to allow implicit session deactivation when needed.
backport of @da1f153d61d747d9357694382fe04f96c0ca886a @c8243e71c6da37547a19f61c58f25d5d03e13d38
- Activate the Sale option 'Tax-Included Prices'
- Create and print an invoice
=> the total is displayed on each line
- Activate the Sale option 'Sections on Sales Orders'
- Create and print an invoice
=> the total is NOT displayed on each line
The option 'Tax Display' only applies to SO, not to invoices. Moreover,
we make consistent the wording.
opw-1856623
In this commit, our hero backport c444b5a293 to 9.0
[FIX] google_account: fix google request exception management
Error thrown by google request is an urllib2.HTTPError that can be read
and loaded in JSON. However in some cases the result of the read may
be void or not JSON-ready. This was causing a crash in the error
management and hid the actual issue.
This commit tries to read and JSON-load the error but fall back on
simply displaying the raw error in case of issue when handling it.
opw-1851612
Application of a fix more specific to the problem of the contact widget
which can not serialize the dictionary because it contains the values of
the context of which browse record. (because contact try to
json.dumps options for multi-edition feature in web_editor)
opw-1859848
https://github.com/odoo/odoo/commit/ab85e9594651fd33ffd2747f4d3c5b360e7c7922
Steps to reproduce the bug:
- Create a product P with routes MTO and BUY
- Set a vendor V on this product
- Create a BOM B with P
- Create a MO M with B
- A RFQ is created with M as origin
- Create a purchase requisition PR with vendor V
- Set PR as purchase agreement on the RFQ
Bug:
- The field origin with M was erased by the name of PR
- The field partner_ref was erased by the name of PR
The fix is inspired by: c914df5a36
opw:1860430
In b446930dc there has been a number of changes in report to improve
performances.
In one of these change, printing several documents with result such as:
```
<div class="article"><h1><span data-oe-model="mymodel" data-oe-id="1" data-oe-field="myfield" /></h1></div>
<div class="article"><h1><span data-oe-model="mymodel" data-oe-id="3" data-oe-field="myfield" /></h1></div>
```
The system will know it is rendering 2 mymodel records (with IDs: 1, 3)
and will try from the document to determines what part (called
"outlines") of the PDF corresponds to these IDs.
This is done by splitting the document over semantical delimitations
such as h1, h2, *.
If all is fine: each part of the PDF will be saved for each record, so
if we print records 1 and 3 they will be saved separately and will be
possibly used as is the next time they are to be printed.
But in the instance of printing a report which has:
- field that are displayed,
- several records printed at the same time,
- save and getting document back from attachment enabled,
- no h1 or other semantic delimitation
The matching of part of PDF and outlines can't be done since there is no
outlines, this was not expected by the code and caused an error.
With this change, if there is no outline each part of the PDF will not
be saved as attachment.
opw-1856469
closes#25496
Carlos Dauden