When you import a variant or when you archive variants to only leave
one tied to the template, the image of the variant can't be changed.
If the variant has a picture and you archive all the other variants,
when you change the image on the variant, it's the template
image which is modified.
opw 1974727
- Create 5 vendor bills with a long reference (> 1000 characters), for
the same partner.
- Select the bills and register a payment
An error arise: 'psycopg2.OperationalError: index row size 3256 exceeds
maximum 2712 for index "account_move_line_partner_id_ref_idx"'.
As mentioned, the index row size limit is 2712 bytes, which is exceeded
in that use case. Indeed, the reference of the payment is computed based
on the vendor reference of all bills.
We limit the number of characters to 2000. This seems reasonable knowing
that UTF-8 characters use sequences of 1 to 4 bytes [1]. Characters with
a code less than 128 require 1 byte only, and it is expected that most
vendor references will only use these characters. It is indeed unlikely
that special characters (such as Chinese characters, taking up to 4
bytes) are used for such references.
[1] https://tools.ietf.org/html/rfc3629
opw-1998823
closesodoo/odoo#33457
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Traceback generated when trying to pass a datetime object into a function tag
in xml.
<function name="action_name" model="model_name" eval="datetime.date.today"/>
Used to fail.
With this commit now one can pass time, datetime, timedelta, relativedelta,
version, ref, pytz in function tag in xml
Task-id: 1772614
Closesodoo/odoo#29212
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Dhaval Limbuwala <dli@odoo.com>
If destroy is called before start, there will be a crash before this commit.
At the time of this commit, this can be reproduced in master by dropping the
image gallery snippet, clicking on add images (double click, which opens the
media dialog twice for some reason), selecting 2 images to add on the
media dialog, and clicking on add. The error will be in the JS console.
closesodoo/odoo#33440
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Open a mail.compose.message wizard.
Select a template that generates an attachment.
Reselect it. A second attachment has been generated.
Can be repeated ad infinitum.
At template onchange, the template is rendered to overwrite the composers values
This includes the attachments.
Let L1 be the list of attachments generated by the template.
When _convert_to_write(values) is called with {'attachment_ids': L1},
it gets self.attachments_ids = L2, and generates a [(6, 0, L1 + L2)] command.
As a result attachments are only added,
the previous ones need to be removed manually.
Since c6d718f, the semantics of _convert_to_write changed.
Before, it always returned an empty list for new records (without an id).
In other words, wa always had L2 == [].
As a result we need to adapt the wizard to keep its old behaviour.
To solve it we bypass the _convert_to_write for 'attachment_ids' and directly
generate the 6 command with the list of ids L1 generated by the template.
We only do this for templates that add attachments to keep the templates
composable (a template only overwrites the values it defines).
Unfortunately, we don't have any way to know which attachments have been added
manually, so we can't preserve these (which was the old behaviour anyway).
opw 1997430
opw 1987169
opw 1998115
opw 1998782
closesodoo/odoo#33387
Signed-off-by: Nans Lefebvre (len) <len@odoo.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>
Since cdca5d4751, the field company_id
on account.payment is not stored anymore, so, it doesn't make sense to be able to group on it
OPW 1998427
closesodoo/odoo#33428
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
If the smtp session was dead, it would lead the whole mail batch to fail.
opw 1949270
closesodoo/odoo#32424
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
closesodoo/odoo#33350
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When an exception is raised during the course of a normal SMTP session,
smtplib's `sendmail()` method will close the channel automatically,
so any further attempt at sending SMTP commands will fail with an
SMTPServerDisconnected error, even just calling `smtp.quit()`.
This will shadow the original error, and make debugging harder.
Fixes#1493
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>
- Activate cash basis
- Set a tax
Tax Due: Based on Payment
Include in Analytic Cost: true
- Create an invoice, add the tax and an analytic account on the invoice
line
- Validate and pay
The analytic account is correctly set on the tax line, but it is not set
on any of the cash basis entries.
Partial backport of 079a13a349.
opw-1971751
closesodoo/odoo#33236
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a product barcode to a 8 letters value, e.g. 'AAAAAAAA'
- Print 'Product Barcode (PDF)' (or any other report containing the
barcode)
The barcode doesn't print.
All templates assume that:
- a 13 characters barcode is EAN13
- a 8 characters barcode is EAN8
But this assumption is too restrictive: one could want to generate
barcodes with such length without following the EAN13 or EAN8 structure.
We fall back on Code128 when the barcode generation fails.
Backport of 06cfdbaab8
opw-1981988
closesodoo/odoo#33240
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There was a syntax improvment in the commit merged but it was not
intended to be unfinished.
fixes#33228
opw-1981839
closes#33239
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When paying an eCommerce order with an acquirer which doesn't
redirect (payment_flow: s2s) the "Pay Now" button is correctly
disabled after clicking it. This prevents a user from clicking it
multiple times and being charged multiple times.
When paying with an existing payment token however the button was not
disabled and the user gets no feedback his request is being
processed. Charging an existing payment token takes a while (~5
seconds with Authorize) and so it's possible users will hit the button
multiple times.
This disables the button when reusing an existing payment
token. Additionally it now uses the correct font awesome icon (fa-lock
instead of fa-plus-circle).
opw-1981064
closesodoo/odoo#33196
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Python2 uses byte strings by default and python3 text string, so adapt
the code communicating with blackbox to still only use bytestring.
Also raspbian image has been updated in posbox 17 to Raspbian 9
(stretch) so ifconfig command returns has different format output (
`ether {MAC address}` instead of `HWAddr {MAC address}`) so the way we
get the MAC address is changed.
opw-1981839
closes#33150
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
ONLINE:
make an order, chose a customer, click on "invoice"
Make the payment, validate
Just **before** the request to download the pdf of the invoice
go OFFLINE
(to achieve this, just put a debugger before the do_action() fires, and kill the server)
Before this commit, the button validate on the payment screen stayed inactive forever
This was because the deferred representing the invoicing flow was still pending
After this commit, we handle the case to invite the waiter to print the invoice
from the backend
OPW 1972301
closesodoo/odoo#33188
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
There was 2 issues regarding delivery price when the delivery was set to fixed
price and free over a certain amount.
1. On /shop/payment step, such deliveries would have the fixed price shown on
the badge, even if the sale order amount exceed the free over threshold.
2. When clicking on a delivery carrier, it is supposed to compute all the SO
costs (delivery, taxes..) and display them.
The delivery price selector would try to get the 'badge.hidden' element
which never exists for fixed prices. Thus, it would not update the delivery
badge price.
Now:
1. If the free over threshold is met, we display 0$ instead of the fixed price
by calling `rate_shipment`.
Note that `rate_shipment` can't fail in case of a fixed rate (see method).
The only failing case is if the customer country does not match the delivery
allowed country, but such a flow is not possible as delivery shown during
cart payment are already filtered by allowed countries.
2. The delivery value returned after clicking on the carrier is correctly
updated on the badge.
Fixes#31502closesodoo/odoo#32938
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
The "from" of an email is expected to follow the regex
"name <address>(, name <address>)*".
We simply split the from on the commas "," and try to interpret each piece as a
(name, address) pair.
If a "from" contains a name that is not quoted, and contains special characters
before the comma, then we would try to encode that name into an email address,
and fail on a UnicodeEncodeError.
E.g. the following "🐧, <a@a.com>" would be parsed as [('', '🐧'),('', 'a@a.com')]
thus Odoo would crash on trying to use 🐧 as email address.
With this commit we would just mess up the name in these situations,
by ignoring failures.
opw 1923429closesodoo/odoo#33145
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Install `l10n_be_hr_payroll_fleet`
- Connect as admin
- Change demo user rights:
- Remove fleet (nothing, not user, not manager)
- Set employee Manager.
- Connect as demo
- On an employee, click the "Contracts" smart button.
- Try to create a contract.
Before this revision, access right issues were raised:
- Just after the create, as default values couldn't be computed,
- After the save as well, because of defaults and computed fields.
The real use case here is for our own sake: Dubai HR Officers
do not have access to Fleet as they do not have company cars,
but they can't create contracts for their own employees
without having access to fleet.
closesodoo/odoo#33120
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Fine-tuning of 463601a384.
It does not make sense to be able to write on mail.activity.type
using the related fields defined on mail.activity.
But this field is not a related one, and it is necessary to be writable to make
the 'recommended next activity' feature work at all.
opw 1974236
closesodoo/odoo#33325
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This commit is a followup to #25854
If a custom relational field is in a view and the field it references is
in another module and this module is uninstalled, the registry will
crash.
This is not because the ORM doesn't properly cascade-delete the field,
it tries to, but since the field is in a not-to-be-deleted view, the
unlinking of the field is interrupted and an error is raised to prevent
the breakage of the view.
However, module install/upgrade/uninstall cannot be stopped by such
errors and once the registry is reloaded, it crashes because it cannot
find the referenced field.
The solution, while not ideal, is to force the deletion of the field if
we're in uninstall mode... This means that the view in question will be
broken until the field is manually removed from the view, but a broken
view can be dealt with more easily than a broken registry.
opw-1974362
closesodoo/odoo#33130
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Nans Lefebvre