Since #26134 the po files are compared with pot content when loading a
translation. If a term is found multiple times in a po file, the terms
that does not exists in the pot files are ignored. If the pot files does
not exists, the unicity constraint leads to an error.
Closes#31583closesodoo/odoo#31823
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
We don't want to notify inactive followers,
especially in the case of oddobot that was considered
as a inactive partner in _notify_compute_recipients.
The computed recipient data for odoobot are
(pid:2 active:False pshare:True notif:None)
It was considered as a partner and notified by email.
This fix simply removes inactive partner from partner to notify.
closesodoo/odoo#31734
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Before this commit the flow of using wishlist with dynamic attributes was not
tested, and it also wasn't tested when combinations were not possible.
Those cases are now tested too.
closes#29859
PR: #31752
task-1920065
Signed-off-by: Sébastien Theys <seb-odoo@users.noreply.github.com>
In the portal, when the client signature is asked (for a SO for example).
Before this commit, the client could send the form without really signing
the document.
Now, a warning is shown if the form is not signed.
opw-1943702
closesodoo/odoo#31768
Signed-off-by: Sébastien Theys <seb-odoo@users.noreply.github.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Suppose that a payment transaction cannot be reconciled for any reason.
Then _cron_post_process_after_done will try to process it every 10 minutes until
the end of time.
Moreover, if the user takes some manual action before
_cron_post_process_after_done,
even if in principle it would have been able to go through,
then it is likely to fail, e.g. on invoice_open.
Meaning that a transaction that could have been processed will become
an undead transaction.
To avoid that situation we set an arbitrary retry_limit_date set to 2 days,
which seems a reasonnable compromise.
It gives some time for the transaction to go through, but not exaggeratedly so.
opw 1945953
closesodoo/odoo#31791
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This makes the assets to be recomputed everytime somebody with a different
language load the page.
closesodoo/odoo#31782
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When there is an optional product for which the quantity is set to 0 because
there is no stock available, the cart update would raise because it tried to
read the order line even though it was deleted above.
Now we apply the logic only if the order_line actually exists.
Part of task 1950712
closesodoo/odoo#31779
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Sequentially previewing and paying two sale orders was causing a
redirection issue. Instead of being redirect to the SO preview
(/my/orders/<:order_id>), the user was redirected to /payment/process.
The issue was due to processed transactions not being removed from the
session.
opw-1948288
Closes#31741
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When journals of type bank are created, default accounts are also
created, and an account code is automatically generated. However, the
number of possible automatic account codes is very limited, because only
100 different codes may be generated, and the error message "Cannot
generate an unused account code" is shown.
To solve the above, the number of possible account codes is raised up to
10,000 different possibilities.
closesodoo/odoo#31681
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When register a payment, and choosing a payment acquired.
Before this commit, the payment post process had to wait until a cron
run (every 10 minutes).
Now, The post process is executed instantly after the payment, if the
payment is not yet done, the post process will be executed in the next
cron run.
Co-authored-by: Toufik Benjaa <tbe@odoo.com>
opw-1928834
closesodoo/odoo#31732
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
vals may be an empty dict
This may happen a write is done on a computed field, the call to _write will
be empty (still needed to update write_uid/date).
Before this commit, all fields were read in the read call.
This was unecessary and may produce acess-rights errors or other side effect
(e.g. in odoo/enterprise#3778 the technical field ticket_count was read, even
if not present in the view or the write call)
Only compute old_values on the fields that are modified
Fixesodoo/enterprise#3778
opw-1949911
closesodoo/odoo#31737
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If the content is too long, it overflows badly.
Since the height is fixed, the flex doesn't work well.
opw 1924145
closesodoo/odoo#31717
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In case company is not set on the model related to the template,
we should not try to retrieve it when creating the associated partner.
Fine-tuning of a46138cb01
opw-1947334
closesodoo/odoo#31607
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Install Invoicing (account) and uninstall it. It results to a an error
because some views required by `payment.acquirer` are deleted before
the acquirers.
The problem is due to the way copied views are deleted, since 1388b7f
they are removed before the module uninstallation. The related commit
faced a similar problem where copied views were deleted too late
during a module uninstallation.
The two problems are revealing that the copied views have to be removed
as part of the module uninstallation, more precisely after all records
refering to them has been deleted but before the schemas has been
cleaned.
opw-1943286
closesodoo/odoo#31443
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit:
The `if` condition doing a `View._views_get` was supposed to be a sort of
'hack' for when the error occured in a child view (as the template raised would
be the parent, not the broken child).
But since we refactored that part to use etree, it was actually going into that
condition for every error even if the error was in the called template.
Proof is, we only set `editable` in that if condition, meaning going in the
else would actually prevent to show reset template.
Indeed the following code would always be true:
et = etree.fromstring(view.with_context(inherit_branding=False).read_combined(['arch'])['arch'])
node = et.find(exception.path.replace('/templates/t/', './'))
as read_combined returns all the view hierarchy DOM
Note: We could not fix this by checking exception.path against `arch` as we
could have false positive (eg the child view replace the <p> element by another
<p> element which is broken, then the path would be found in the parent view
even if the error was in the child view).
closesodoo/odoo#31515
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In saas-11.3 "Is a Landed Cost" (landed_cost_ok) was moved from the
product accounting tab, to the inventory tab.
The inventory tab is only shown for product not of type service, but the
field should be shown when product is of type service, consu or product.
With this changeset, "Is a Landed Cost" is displayed in the top and
"Split Method" is hidden: to specify the split method, this needs to be
done from products in Inventory > Configuration > Landed Cost Types, or
by the list view of cost lines when creating a landed cost.
opw-1949329
closes#31714
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The filter parent_res_name was already in the original search view so
the duplicated one was not needed and caused to have two times the
filter in the search view with possible different behavior.
opw-1949559
closes#31707
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Commit 6af6da5c5 introduced a duplicated term to the file .pot, which
causes the following error when trying to re-load translations:
```
ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same
command have duplicate constrained values.
```
This commit removes on eof the duplicates, leaving only the valid one.
```
```
closesodoo/odoo#31683
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Inline (base64) embedded images are not supported by most mail
clients (gmail on top of them), this fix save those images as
attachments and replace the src tag with the url of the
generated image so the image correctly renders.
opw-1929940
closesodoo/odoo#31532
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Have an account move which lines have all the same partner
Have a bank statement, without a partner
Enter the reconciliation widget for the bank statement
All the lines appear
Select one of the lines of the account move for the partner
Before this commit, all other lines disappeared from the proposition
including the ones for the partner selected
This cas because when having set a partner on the widget,
only receivables and payables accounts were searched for
After this commit, all account move lines for the partner are searched for
OPW 1942936
closesodoo/odoo#31488
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Go to Menu / Accounting / Vendors / Bills
Search a partner with too many opened invoices
- E.g. 713 opened invoices (709 local currency, 4 foreign currency)
Choose all them
Press Open Action -> Register Payment
Wait to open the view.
Before this patch line_profile result
Total time: 1141 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2922 1,139,417,018.0 389944.2 99.9 amount_total = sum([MAP_INVOICE_TYPE_PAYMENT_SIGN[i.type] * i.residual_signed for i in payment_invoices])
After this patch line_profile result
Total time: 12 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2862 11,733,108.0 4099.6 98.1 invoice_datas = invoices.read_group([('id', 'in', invoices.ids)], ['currency_id', 'type', 'residual_signed'], ['currency_id', 'type'], lazy=False)
It means 95x faster
closesodoo/odoo#31313
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Part 1: Backend
Changing an option's variant now change the product name and the image
Part 2: Front end
The behavior is the same as in the backend.
For that part though, there is a huge design problem:
the modal dialog has the class .oe_website_sale, so the widget website_sale
reacts to events triggered in the modal.
It is understandable given the history of the module, but a proper refactoring
that will implement inheriting of business behaviors through OdooClass extension/overrides
is necessary in master
OPW 1938217
closesodoo/odoo#31201
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The holiday_type can be 'employee', 'company', 'department' or 'category'.
However in the onchange of holiday_type, for some reason nothing was done
in the case of the 'company' value.
As a result, the default 'employee' would set the employee_id,
but then changing the type to company would not remove the employee_id.
It follows that the lucky employee would get two allocations instead of one.
opw 1938498
closesodoo/odoo#31656
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, there was a possible race condition in the
`tour_shop_dynamic_variants` tour. Indeed, the `click add to cart` would be
triggered before the `click on the second variant` RPCs are done.
Trigger on `.oe_price .oe_currency_value:contains("0.00")` was supposed to
check that condition but it was not strong enough.
Then, clicking on add to cart would not call `create_product_variant` as it
would still have the first variant id in the hidden input instead of "0".
closesodoo/odoo#31670
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Searching on website is enough. Plus, it will avoid bugs if admin
change sale team of the order or the sale team type.
closesodoo/odoo#31669
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when doing `<t t-raw="0"/>` to print the t-called
content, it was printing "[]" if the content was left empty.
closesodoo/odoo#31668
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
State from the template was 'CA' for California - not recognized on import
Changed it to 'California' to match with the db data
opw 1943904
closesodoo/odoo#31556
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Commit 5a81d8883 fixed the COW view deletion on module update but introduced an
error when installing a theme.
Indeed, when installing a theme, the first step is to remove the currently
installed theme from the website (by unlinking its ir.ui.view).
Commit 5a81d8883 introduced the fact that deleting an ir.ui.view during a
module uninstall also search and delete the COW views, calling
`_get_specific_views` (that expects a singleton).
When installing a theme, it calls `_theme_cleanup` which search COW views and
unlink them. If not cow view, unlink is called with an empty record set raising
the singleton error.
closesodoo/odoo#31662
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Commit d139e92c62 set the force_send to True
unless there is an explicit mail_notify_force_send set to False in the context.
The _get_eval_context puts mail_notify_force_send to False in the context,
but it might be lost before reaching that method call.
Launch a cron that starts a transaction, see if it goes through,
and rollback if it didn't,
then the mails send inbetween will be sent every time the cron restarts.
E.g. _cron_post_process_after_done.
opw 1921112
opw 1945953
closesodoo/odoo#31605
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
uom_po_id is the 'Purchase Unit of Measure' and is required so should be used
here.
This way, the onchange matches the behaviour of purchase module or the reset of
the purchase_requisition code
closesodoo/odoo#29717
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The widget has been moved in rev. odoo/odoo@15f3bbe but was not very generic.
In particular, there was a traceback when clicking on the button if the field
had no value (the button was displayed for readonly fields in create mode).
The button is now only appended in readonly mode (a `button` inside an `input`
or a `textarea` is not very DOM friendly) if the field has a value.
Task 1941996
closesodoo/odoo#31635
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The style of a link (color) of a many2one is only applied over the
first line (probably for eg. the partner on an invoice that has the
partner name and on following lines the address).
In some instance this make some sense, but on other (the name of a
product is too long from where it is) it makes no sense and seems buggy.
With this change, we have the link style over the whole link which seems
good enough.
opw-1947113
closes#31568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a view was removed during a module update (eg: the
record was deleted from the file), its COW views would not be deleted.
This could lead to unwanted behaviors including tracebacks(1).
This commit is somehow related/an extension of b5fe23055d that handle COW view
write during module update and 2e32cc5aa3 that remove COW views during module
uninstall.
task-1931683
Note: Some existing tests had to be run post install
(1) A view doing a t-call is COW'd, then that view and its t-called view are
removed. If the cow view is not removed, the t-call will crash (see tests
in this commit for detailed case).
closesodoo/odoo#31295
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Do not apply the duplicated route to the products/categories/warehouses
the original one was applied to.
Fixes#31610closesodoo/odoo#31619
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit has been backported in 11.0 [1] and then reverted [2],
because it introduced a regression in web_studio, discovered at opw-1947380
As no forward-port has been done between the backport and the revert,
the forward-port of the revert also contains the patch itself, resulting
in a noop.
Actually revert 06d73eab62 in branch `12.0`.
[1] d855e3911f
[2] 1748b46718closesodoo/odoo#31637
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when printing an invoice, the taxes were grouped
by their tax group (NOT by their parent tax)
Summing the base of each tax in the process.
This was largely insufficient, as tax groups can have taxes
with different rates or computation method within them
The summing of the base of each tax for reach tax group was in this case plain wrong
This commit aims at grouping by
group > computation method > amount
Which makes more sense
OPW 1947202
OPW 1945353
closesodoo/odoo#31617
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
goran.kliska