In the planner the url are generated by prepare_backend_url that takes
an action's xml id as argument. The id passed should have the format
'module_name_where_the_action_is.action_name'. In this case the id passed
was product.product_template_action_product but the action is defined in
stock thus the prepare_backend_url was not able to find the associate action
and return a wrong(default) url.
This commit change the action id passed with the correct module.
closesodoo/odoo#18812
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the field intrastat_country_id was not propagated when refunding an invoice
After this commit, the refund invoice takes the same values for that field
as the invoice it is refunding
OPW 2028333
closesodoo/odoo#35309
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
https://docs.python.org/3/library/stdtypes.html#truth
By default, an object is considered true unless
its class defines either a __bool__() method that returns False
or a __len__() method that returns zero
Since etree elements are iterator, they define a len function.
However it turns out that customerProfileId has always no children.
So bool(find(x)) is always False; the intended meaning was find(x) is None.
opw 1999427
closesodoo/odoo#34922
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
closesodoo/odoo#35246
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `customize_template_get()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
Test writen in 12.0 with #35154closesodoo/odoo#35155
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Create an invoice I
- Set the invoice date in the past and add payment terms
- Validate I
- Create refund from I
Bug:
The invoice date is set as today but the due date was set in the past.
opw:2033438
closesodoo/odoo#34748
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
During checkout, the user can create a new billing (only for public user as it
will create a 'normal' `res.partner`), a new shipping, edit its billing (that
will edit himself) or edit its shipping address.
All those cases will go through the exact same methods, public user and logged
in user included.
This previously led to multiple issues and multiple fixes to correctly set
`company_id` and `website_id` on the address (res.partner).
See 44372471ef that fixed the `website_id` part.
See 3a0f05f33 that fixed the multi-company behavior, but needed 2ba71140 to not
modify the company of an already created partner, but was still incomplete as
after that fix a logged in user would still have the admin (sudo) company
instead of the website one as supposed.
This commit will fix that bug and add some tests for all mentionned issues.
Fixes#28853
Backport from odoo/odoo#34596closesodoo/odoo#34689
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a pl promo code is applied, the code is shown in the promo code input.
Before this commit, if the user clicked on "Apply" (so with the same code) it
would remove the pl as it would go in the `if` condition that is supposed to
handle empty code modo to reset pl.
Coming from #34633closesodoo/odoo#34734
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, values were rounded to the unit, which was part of the former specs
of the Intrastat report
After this commit, we make the intrastat 2019 comply with the new spec, which is to round
value, price and weight to two decimals
See the spec here: https://www.nbb.be/doc/dq/f_pdf_ex/nieuwsbriefintrastat_n28_2018_fr.pdf
OPW 2031682
closesodoo/odoo#34700
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when a transaction has as status 'authorized', the
transactions' confirm page gives an error : 'Oops! There was a problem
with your payment.'
Now, the page gives the same message as when the transaction has the
status 'done' : 'Your payment was successful! It may take some time to
be validated on our end.'
opw-1984325
closesodoo/odoo#34652
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Fix/improve commit d870749d79
that was removing line feed (\n).
In this one, we also remove carriage return (\r)
to address all cases.
closesodoo/odoo#34536
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Detected with OPW 1920765
Reproduce : set multi-companies, install accounting. The due amount for all companies is the sum of the due amount for every single company
Cause : the context for company_id is not set in account.move.line:_query_get
Solution : set it in res.partner:_credit_debit_get in case _query_get is used elsewhere
closesodoo/odoo#30463closesodoo/odoo#34486
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Let contacts be shared in a multi-company setting.
Make a filter on 'Total receivable', e.g. greater than 0.
All contacts that correspond to this clause are show,
even if their Total receivable is nonzero in another company.
It follows that a partner can be shown by the filter with a value 0.
The inconsistency was created by 017184331b, which adapted the compute method
to the multi-company setting, as before the two were summing all companies.
opw 2028660
It's currently possible for binary downloads to be missing an
extension entirely. Generate an extension from the mimetype and use
that. Also ensure the existing extension (if any) matches the
mimetype.
Warning: this may require adding new mimetype/extensions pairs to the
local mimetype database similar to
f413d155df.
Also fix missing or incorrect filenames on records without a filename
field: in some Odoo versions the client would send a filename of
"null", resulting in a download of e.g. "null.pdf" instead of the
attachment or inferred name.
Task 2025716
closesodoo/odoo#34299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Make a SO with a product that have a carriage return in its
description
- Export FEC report
The CSV contains new lines and is not correctly formatted.
opw-2026861
closesodoo/odoo#34385
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 included taxes: 21 % and 6 %
- Create a product A with 21 % as default tax
- Create a fiscal position to map the tax 21 % to tax 6 %
- Allow the fiscal position in the POS
- Add product in a POS order
- Apply the fiscal position
The subtotal is not recomputed correctly. On the other hand, if the
fiscal is first set then the product added, there is no problem.
This is because the `fix_tax_included_price` is only called by
`add_product` and not when changing the fiscal position.
opw-2020755
closesodoo/odoo#34260
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33945
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
Stock.locations should be in no-update:
Limit the impact of recompute fields during the upgrade of stock module. (especially method _compute_product_availability)
Limit the impact on migration
Method _compute_product_availability is triggered during an upgrade of module and during migrations.
This may take a lot of time of big databases
closesodoo/odoo#34074
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.
The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.
opw-2006647
closesodoo/odoo#34076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a web editor, add some text, select the text, add a link and
immediately discard the link modal. Traceback.
The traceback is a execute `setEnd` on `Range`, that error is thrown
because editable DIV doesn't save old range
Odoo wrap code does some text node split in order to attach the link
just on the selected text. If it correctly re-set the underlying
structure, it does not update the $(editable) structure used to restore
ranges.
After this commit, editable div will use newly created range for the element
for ex:
-> content: test
-> selected content "test"
when click on link dialog:
ec: test , eo: 4, sc: test, so: 0
selected content -> start 0, end 4 -> "test" like this
after clicking on discard:
ec: null text element, eo: 4, sc: null text element, so: 0
selected content -> ec and sc both are null, so it will throw an error
while setting cursor position
after applying fix when click on discard:
ec: test, eo: 4, sc: test, so: 0
selected content -> start 0, end 4 -> "test"
task - 1955863
closesodoo/odoo#33792
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
There was no way to inherit properly action_move_create method.
opw:1974069
closesodoo/odoo#33488
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field had no triggers on the compute method.
As the field is not stored, it works fine in most cases where the value is
computed in a different transaction that the modification but when it is the
case (e.g. OCA/connector-prestashop#101), the values were incorrect
Add the correct triggers to recompute the value when needed
closesodoo/odoo#30024
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Backport of 610b813c87.
In this way the description of the delivery method can be used on a SO
line. If the description wasn't set, the name of the delivery method
will be used.
opw 2000169
closesodoo/odoo#33551
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When transaction is approved, if for any reason the `customerProfileId`
is missing from the response, the transaction is aborted.
It should succeed even if we cannot create a customer profile.
opw-1998505
closesodoo/odoo#33501
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit will correctly check for a custom payment.transaction create method
on 'self' instead of the acquirer's provider before calling it.
closesodoo/odoo#33033
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When multiple emails (`mail.mail`) are linked
to the same message (`mail.message`),
all the message notifications were being marked as sent
as soon as one of the mail was sent, and not all of them.
This is indeed possible to have multiple emails linked to a single
message, for instance when there are employees and customers in
the followers of a thread, and some must therefore have
the buttons meant for the employees ("Assign me") and some not.
In other words, it was possible notifications were marked
as sent while their associated email was not sent yet.
This revision also comes as an addition to
5d6656d739
as it was possible to receive a bounce coming from
the previous mail sent which wrote on the same notifications `email_status`
than the current message being sent before we could acquire the lock on
them (see commit message of the above mentioned revision),
as it was writing the `email_status` on more notifications that it
should have, including notifications of the previous email.
e.g
- Mail 1
- Message 1
- Recipient A, B, C
- Mail 2
- Message 1
- Recipient D, E
Let's say recipient A bounces
If the email notifying the bounce arrives during the processing of the "Mail 1",
it will be blocked until we release the lock on the `mail.notification` `email_status`
we acquire thanks to having written `exception` on `email_status` before sending the email.
But, as soon as it is unblocked (after the `cr.commit()`),
it will immediately re-attempt the delivery of the bounce email,
therefore writting "bounced" in `email_status` of recipient A,
while the transaction of the second email already began.
When the second email sending will try to write the `email_status`
of recipient A as well
(as it used to write the `email_status` on all the message notifications,
not just the one related to the current email),
it raised a concurrent update.
Therefore:
1. Interrupting the loop, as psycopg2 exceptions are raised and not passed,
2. Replay the sending of the second email a second time.
opw-1984293
closesodoo/odoo#33431
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Rounding each element of the sum decrease the
precision and prevent to reconcile large recordset.
closesodoo/odoo#33100
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
With some escpos printers the cash drawer did still not open after
previous fixes. One of the problemetic printers is the Epson TM-m30.
This fix will check the status of the drawer and try to open it up to 5
times. The fix is successfully tested with the TM-m30.
closesodoo/odoo#33328
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When website_customer is not installed, some endpoints are not handled
by the router, causing the following tests to fail:
- test_10_crawl_public
- test_20_crawl_demo
- test_30_crawl_admin
Those tests were failing due to /customers responding with 404.
Indeed, the route /customers is defined in website_customer, but had
some usage within website_crm_partner_assign, causing tests to fail when
the former module is not installed.
The new behavior can be explained as follows:
- module website_crm_partner_assign on its own will lose the hyperlink.
- module website_customer will now inherit the view definition in order
to wrap the targeted HTML text elements with an anchor tag.
Closes#33344
Signed-off-by: Christophe Simonis <chs@odoo.com>
before fix negative values will be added after -0.00 resulting in a
value like for instance -0.008543 while is should be -8543.00.
Also when removing the value there will be a traceback for '-' not being
a number.
added extra checks for negative values on input.
resolves https://github.com/odoo/odoo/issues/29910
resolves https://github.com/odoo/odoo/issues/29909closesodoo/odoo#30035
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase to reproduce:
- Archive a stockable product with quantity on hand
- Start an inventory with all products.
-> Archived product is displayed
It happens because the search is an SQL request that is build
and it thus does not benefits from the automatic search on active
objects.
This commit add an active search on quant for inventory lines.
closesodoo/odoo#33077
backport odoo/odoo#27384 from 11.0
closesodoo/odoo#33098
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO
- Add a product service that will generate a task to the confirmation.
Its UOM must be Hour(s)
- Confirm the so an go into the task
- Add a timesheet line with "00h20min" and save it
Quantity saved into the delivery qty of the SO is 0.34 instead of 0.33.
The default rounding method is `UP`, so we use `HALF-UP` instead.
opw-1975014
closesodoo/odoo#33276
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Putting *args and **kwargs confuses the function `odoo.api.split_context`.
This causes that a call to `search` via XMLRPC gets the wrong argument: takes
the first argument of ``args`` as the context.
Example which ignores the `count=True`::
```
api.call_kw(self.env['product.product'], 'search', (
[], False, False, None, True, {'lang': 'en_US'}
), {})
```
would ignore the `count=True` and use the wrong argument for context.
Issue introduced in commit 15ea753a.
Since:
`def search(self, model=None, *args, **kwargs)`
is equivalent to:
`def search(self, args, offset=0, limit=None, order=None, count=False):`
because the call to the super will anyway call the parent method, we can
change the method arguments.
note: this is only for [10.0,saas-14] where 15ea753a is.
closes#33147
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
Prefetching it triggers its translation, which quickly becomes most of
the overhead of /jobs despite the field not being displayed on that
page: an empty /jobs takes ~150ms, a /jobs with 99 jobs takes ~2000ms,
>70% of which are spent in html_translate and ultimately
translate.py:process (14600 calls, 60% of runtime, 40% own).
Removing prefetching lowers the runtime to ~700ms.
closesodoo/odoo#32985
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make a PO then an invoice with a product that will create an asset
cancel the invoice
Open the Assets Analysis report
Before this commit, the asset lines corresponding to the invoice
are shown
After this commit, they are not shown (only non archived assets are by default)
OPW 1974344
closesodoo/odoo#32955
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
amoyaux