A user without stock acces rights was not able to read the fields
added by the stock module
The statbuttons display the number of items available which are
computed fields An accountant (no inventory or sale access rights),
opening the product view will trigger the recompute which will fail
(no access on stock.warehouse.orderpoint)
closesodoo/odoo#32499
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the product has a lot of variants which are displayed as checkboxes
or as colors, the jQuery selector was matching as many items, and the
event was triggered for each of them.
The result was the change event of website_sale being triggered many
times, where only one call would be enough.
The change replicates what was made on v12.0 on the same line by commit
f8dad1bb4b.
opw 2036356
closesodoo/odoo#35322
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the calendar view
In the partner filter in the calendar side bar
type something, and backspace rapidly to remove everything
Before this commit, there was a error because the framework tried to write something
in the corresponding field
This was because the o2m field was not initialized
with the correct values
After this commit, there is no error
OPW 2043975
closesodoo/odoo#35330
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.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>
- Admin (U1) user, Demo (U2) with Sales Manager rights
- Create parent company A and child company AA, U2 has access to A (U1 to both)
- Create 2 taxes, T1 for A, T2 for AA
- For product P, add tax T1 in company A, and T2 in company AA
- U2 creates a new SO in company A with no lines, export Order Lines/Product
- U2 edits the file to add product P
- U2 imports the file
Before this commit, the sale order's line had the taxes for bot company
After this commit, it only has the taxes for the company of the sale order
OPW 2036453
closesodoo/odoo#35294
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>
Since 5c9cea4ee7, it was not possible to remove an applied promo code
pricelist by adding an empty promo code on checkout (eg removing the one shown
in the promo code input).
Indeed, when sending an empty promo code, the `search()` done in the controller
would not find any pricelist as promo would be en empty string. For the rest,
check code on mentionned commit.
See `sale_get_order()` method docstring about `code` param: "If empty, it's a
special case to reset the pricelist with the first available else the default.".
Fixes#34633
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>
Forward port of a8dfc7fb73
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
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>
The patch fa492d87f4 has been backported
from Odoo 12.0, that runs on Python 3.
The string '\n\n({} {}, {} {})' to be formatted is a byte-string in
Python 2, while the return value of _() is always a unicode-string.
As format() is (too?) nice, it attempts to convert the unicode-strings
into ascii in order to inject them in the format pattern.
With some languages that are written in ascii, this works -- by chance.
When you use non-ascii languages like Japanese, it fails.
We then fix that issue by using unicode-strings in the formatting
pattern.
#OneCharacterPatch B-)
opw-2032016
-----------------------------
For full technical understanding:
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format('test')
'test'
>>> '{}'.format(u'test')
'test'
>>> '{}'.format(u'エ')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u30a8' in position 0: ordinal not in range(128)
>>> u'{}'.format(u'エ')
u'\u30a8'
closesodoo/odoo#34698
Signed-off-by: Richard Mathot (rim) <rim@openerp.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>
Before this commit, on a device with a "pen" (e.g. Surface Pro, ...),
it was not possible to sign a document on some browsers recently
updated (e.g. Chrome, Firefox, ...) only Internet Explorer was working.
Instead of drawing continuous lines only few dots appeared.
For Chrome and Firefox we have to catch events with "addEventListener".
For Edge we add touch-action property to convert touch events into click.
Steps to reproduce:
1) Go to sales app
2) Then go to quotations (menu Sales)
3) Create a new quotation
4) Click on preview
5) Click on the "Accept" button at the end of the preview
6) Use the "pen" to draw the signature (BUG)
We use a custom version of the jSignature lib (c.f. odoo/odoo@eddcb46),
so we have to patch the file in the Odoo repo with a mix of some
pull request found in the official repo and forks.
Link:
https://github.com/brinley/jSignature/pull/109https://github.com/brinley/jSignature/pull/159https://github.com/willowsystems/jSignature/pull/96
opw-2029684
Backport somewhat improved version of this fix (we don't need to check
for the existing extension since we're not doing anything if there is
an extension at all) merged into later branches, to avoid forward-port
conflicts.
closesodoo/odoo#34509
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before that, groups of taxes defined in l10n_es only defined tags on child taxes. This is wrong: base tags of a group of taxes should always be set on the group itself; children should only contain tax tags (at least, if their type_tax_use is 'none'). Indeed, the tax_ids field of aml generated for these taxes will point to the group, while tax_line_id points to its children.
closesodoo/odoo#34557
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
concat_xml was apparently missed during the Python 3 text model fixes,
resuling in a function which usually returns ``(bytes, str)`` but in
the case of an empty or missing ``file_list`` would return ``(str,
str))` instead, leading to type errors in Python 3.
Fix the particular case so it properly returns bytes as the
"concatenation result" even when it did nothing. Fix the docstring so
it properly reflects expectations as well.
closesodoo/odoo#34751
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Usecase to reproduce
- Create company A and company B with one warehouse each
- Warehouse from A resupply warehouse in company B
- Create a product and check the route MTO and resupply from warehouse A
- Connect as Demo User that only have access to company B
- Do a delivery order in company B for this product -> it creates a
receipt from warehouse A
- Deliver in warehouse A to company transit
- Try to reserve the receipt in company B
-> It does nothing.
It happens because the receipt move is in company A and the delivery
order is in company B. The move is tagged as make_to_order so the
reservation is based on move_orig_ids. However the move_orig_ids is
empty due to record rule that hide since it's in the other company.
In order to fix it, allow to see move from other companies that goes
to transit location.
opw-2033066
closesodoo/odoo#35223
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Add the missing drop_view_if_exists that allows the recreation of the template
when updating the module
closesodoo/odoo#32380
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Do not use model._description as this is a static string that is untransalted
Retrieve the value on the ir.model record which has a translated field
Fixesodoo/odoo#28481closesodoo/odoo#33957
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Odoo Translation Bot