This fixes the following bug:
Creating an Invoice, clicking on Validate (with no invoice line), and then trying to add a product.
Before this fix, this would throw an error message.
Now it works.
The sequence had a static default value, but when there is an handle, it's important that new items are added at the top or the bottom of the list.
This is a rare case where the defaul_get from the server will be ignored by the view for a certain field.
This will work:
- both in editable mode (inline) and in dialog mode,
- both for X2Many and standalone list.
The scenario is:
- create a new parent model, which has a one2many
- add at least 2 one2many lines which have:
- a handle field
- a many2one, which is not required, and we will leave it empty
- reorder the lines with the handle
This will call a resequence, which calls a name_get.
With the bug that would throw an error at the RPC, but this commit fixes it.
The $as_all variable was mentioned in the doc but it is non-existing in the Python code.
This commit makes clear it is only available on JS QWeb.
Also rename OpenERP to Odoo.
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.
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
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
Christophe Simonis