PURPOSE:
Default analytic account should be used wherever possible. This wasn't
the case because the module didn't implement a default_get and only
filled the fields on product_id change, which isn't set by the OCR
task-2067097
opw-2068110
closesodoo/odoo#37389
X-original-commit: 2c450015154f8ba2384fb1f0ad1d4075785009c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Pre-filter lines based on known products.
Closes#36854
opw-2074824
closesodoo/odoo#37383
X-commit: bd3997b79a075a24afce749474fc32b43ac8c03f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, 'Go to website' in website module dashboard might not
redirect to the correct website.
It would just redirect to `/` (href) without forcing the website selected in
the dashboard.
task-2063252
Closes#36390closesodoo/odoo#37359
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, if one would introduce a scheme or a port in his website
domain, it would make the website selector to crash JS side.
Indeed, it would replace the current url hostname by the website domain.
If the website domain was introduced with `http://` it would lead to
`http://http://mysite.com`.
If port was introduced, `http://mysite:8069:8069`.
Also, by fixing those 2, it also make `localhost` and `127.0.0.1` to work.
(which would not work without `http://`.
Related to #36390
Test import of a file with xml ids.
At the first dry run, the xml id X is associated with id R for each such record.
If some records refer to X via a relational field, then in SQL it reduces
to a query using R as id; but R does not exist since it was a dry run.
As a result, subsequent runs fail.
The cache should be cleared after a dry run, since the xml ids are not reliable.
opw 2068446
closesodoo/odoo#37396
X-original-commit: 1b35294d7b8d07f373eca24977e2952b9cfb2c7d
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
l10n_ch_currency_name is a related field to currency
Without this patch, when creating an invoice, the inverse of the
related field was computed, trying to write the name on the currency
(with the same value).
If a user did not have the required access rights (e.g. a user in the
group Billing can create an invoice but not write on res.currency by
default), he was unable to create the invoice.
Fixesodoo/odoo#31487Closesodoo/odoo#31489closesodoo/odoo#37381
X-original-commit: 5e49fa8002d7581bfad6dacee0f0b75de59817ec
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Go to Inventory > Reporting > Inventory Valuation
- Run the report
- In the search view, filter on 'Location' or 'Warehouse'
The filter doesn't work.
Actually, the filter can't work. This is a hack introduced in order to
add context keys.
Originally, the function `search` was added to avoid the error log
'Non-stored field %s cannot be searched.'. This happens because the web
client adds the field in the domain on top of adding the context key. By
using `filter_domain`, no domain is added and no error is logged.
opw-2075456
closesodoo/odoo#37347
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, editing a record e.g. in a form
view and toggling the home menu would cause the discard
warning to be displayed twice when going to the home
menu (in enterprise) and then once again when going to
an other app. This is now fixed.
Task ID: 2043027
closesodoo/odoo#37301
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Since 2302386d3ea47f3160ca5857425c99e0d4bbf62a the VAT or Codice Fiscale
fields could be empty for non Italians buyers. In that cases the
generated XML must be sent a dummy Codice Fiscale (99999999999), to pass
the extra checks, see
https://www.fatturapa.gov.it/export/fatturazione/sdi/Elenco_Controlli_V1.1_EN.pdf.
opw-2045244
closesodoo/odoo#37346
X-original-commit: 98ea0872efbdb60b9dd04b31dc711b937c2195ec
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create a lot of event (i.e. 300 via recursive events) with attedees. Sync.
Cancel all the events. Sync again. This and all subsequent
synchronization will take a lot of time to complete. The first time is
normal because odoo will cross-check every deleted event for the "syncing" user
with google to ensure that there is match between OE and GC.
This matching will sistematically fail because the json module cannot
serialize a datetime object, so it will be retriggered again and again
stalling the synchronization for minutes. Formatting the datetime before calling the
dump fixes. Moreover the api usage was wrong as 'originalStartTime' is
not a date but a complex object holding the date.
Note: this could have been avoided via logging but error detection was
suppressed.
opw-2052450
closesodoo/odoo#37335
X-original-commit: 951808b2434717d38ab9d562404eb74d8bd40634
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
So the logs contain some indication as to what was exceeding the limits.
closesodoo/odoo#37303
X-original-commit: 0a266f444a0abda026d09ad88024dca1c50c92b9
Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>
The field second_amount_type was not taken into account when doing automatic reconciliation and 100% of the remaining amount was always used
closesodoo/odoo#37282
X-original-commit: 8c2ed8849bdf5f6b84f63a01c1b27b83d31e3a8d
Signed-off-by: wan <william-andre@users.noreply.github.com>
Having this field required in the view forbade the 'send for digitalization' button of account_invoice_extract to work, as it could be empty there (as the invoice was created via .create({})). The constraint defined in the view was checked before executing the code related to the button and caused everything to fail before running anything.
closesodoo/odoo#37279
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
-TVA à l'encaissement (vente) 10,0% for sale
-TVA à l'encaissement (vente) 10,0% TTC for sale
-TVA à l'encaissement (achat) 20,0% for purchase
-TVA à l'encaissement (achat) 20,0% TTC for purchase
-TVA à l'encaissement (achat) 10,0% for purchase.
-TVA à l'encaissement (achat) 10,0% TTC for purchase
-TVA à l'encaissement (achat) 5,5% for purchase
-TVA à l'encaissement (achat) 5,5% TTC for purchase
-TVA à l'encaissement (achat) 2,1% for purchase
-TVA à l'encaissement (achat) 2,1% TTC for purchase
also add accordingly fiscal positions
task - 42558
closesodoo/odoo#37266
Signed-off-by: Josse Colpaert <jco@openerp.com>
Since 11.0 88b75f150 the wishlist can't contain duplicates: thus if we
remove an element from wishlist (by adding it to cart or removing) there
is an error next times it is added (since the product is already in
wishlist but archived until next garbage collection).
opw-2074843
closes#37255closesodoo/odoo#37287
X-original-commit: 0b085ce0800f410d5f88615fd18bd633c0d48fb5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If groups are deleted (or does not exists yet in case of upgrade), it
wasn't possible to update the `account` module.
closesodoo/odoo#37286
X-original-commit: 5c5823f254ab79b5ea4e88aee5b6d088508db9a0
Signed-off-by: Christophe Simonis <chs@odoo.com>
Go to Configuration > General Settings.
Before this commit:
if a setting is None, a stack trace appears.
After this commit:
a warning message is logged in this case, but there is no crash.
closesodoo/odoo#37271
Opw: 2075047
X-original-commit: ed64477d0a9fc58a577d9174a347268186eff70f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Avoid to crash when trying to render an employee's org chart
when in a different company than yours.
- Retrieve the context from the current environment instead of
the `_check_employee` function parameters.
closesodoo/odoo#37251
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Before this commit, when the domain alias was set (e.g. my_domain.com),
the reply-to and the reply-path were filled with default values using
this domain (e.g. reply-to : catchall@my_domain.com and reply-path:
Return-Path: bounce+number@my_domain.com). As we have a second SMTP
server, the certified email
(https://en.wikipedia.org/wiki/Certified_email), with a different domain
than the domain alias filled in the settings, the SMTP servers will
arise an error : "SMTPRecipientsRefused: Sender address rejected: not
owned by user", this error arise because the domain of the certified
email is different from the one setted in the settings, is also
different from the domains of the reply-to and the return-path.
Now, when we know that we are going to use the certified email SMTP
server, for example to send invoices to the Italian government, the
email will be sent without a reply-to or without a reply-path. This
behaviour is exactly the same as the behaviour will have if we didn't
set a domain alias.
opw-2045244
X-original-commit: 66c5053
When having a long systray (icons from different apps, mode debug,
multi-company...) the resize of the window can trigger a crash for apps
that have not too much top-level menus (e.g. Contacts).
This also happens when loading those apps.
Steps to reproduce (on an iPad, portrait):
* use a Runbot with all modules installed (12.0+)
* activate "debug mode"
* ensure that the menu/systray bar is quite full
* open the "Contacts" app
=> traceback with a "cannot call getBoundingClientRect of undefined"
error
The reason is that the resize's callback iterate over the systray/menu
items to find which one should be folded behind a "more" ("+") menu
item.
Sadly in some cases (combination of screen width, systray size, app's
number of menus) it can lead to a traceback.
This commit ensures that when looping for menu items, we don't try to
reach an non-existing item.
closesodoo/odoo#37245
X-original-commit: d7bae0329990171710acf2d9c0d4d9579cba2c0e
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Before this commit, when printing an invoice that has at least
one tax which is part of a tax group and some repartition lines
On the invoice pdf the group of tax contained twice the base amount for that
tax
After this commit, the tax group contains the base only once
OPW 2073989
closesodoo/odoo#37226
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
omission in d26e253edd
kill -3 (SIGQUIT) is not processed like the other signals so it doesn't
go through this bit of code, but leaving the AttributeError lurking
there is not a good idea.
closesodoo/odoo#37221
X-original-commit: ac65ef0208a5ec814d263aeb44a98b47a5ee3947
Signed-off-by: Denis Vermylen <Icallhimtest@users.noreply.github.com>
If SQL, if you do
```display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL```
and `display_type` is `NULL` then you can only have `'t'` because
`SELECT NULL OR 'f';` yields `NULL`
`SELECT NULL OR 't';` yields `'t'`
The check of NULL is not blocking, hence the constraint doesn't work.
closesodoo/odoo#37075
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a survey with one page per section.
- Go to the second section and select an answer.
- Go back to the first section using the breadcrums.
Before this commit:
if you go back again to the second section, you will see that your answer
wasn't saved.
After this commit:
answers are saved even when navigating with breadcrums.
closesodoo/odoo#37157
Opw: 2072948
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Prior to this commit, the documentation page for the installation of Odoo had lots of inconsistencies, errouneous information and a bad structure.
This commit restructures the page to split the Source Install chapter into three sections for Windows, Linux and Mac OS.
Each section is entirely rewritten to be accurate, logical, clean, easy to understand and focused on its purpose (removed tutorials of non-Odoo softwares).
task-2072822
closesodoo/odoo#37001
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
on a picking, move_ids_without_package is a subset of move_lines.
The inverse function on move_ids_without_package only work well when we
add a move.
This commit improves the inverse function to take deletion into account
closesodoo/odoo#36558
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Payment tokens created before the installation of this module and that
used the Charge API did not need to keep the card reference on Odoo's
side - since we were allowed by the API to simply specify a customer
reference when creating a charge and it would take the default one for
that customer. Odoo creates one customer per payment token (even if it's
the same partner), so there was no uncertainty there.
Now, with the PaymentIntent API, the payment method reference is
mandatory. We have a field to keep it in db, but this info needs to be
retrieved for tokens created before the module's installation. This fix
introduces that remote call.
closesodoo/odoo#37206
X-original-commit: 1b760a988fdf7bbc08b92e0705929d5620356a2f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The computation of kit quantities was not efficient. A loop on each product
of the recordset to consider performed. Each time a product was seen as 'not a kit',
a new computation on the complete recordset was done. This leads to a N^2 complexity
This commit only compute stock quantities for non kit product in one batch
opw-2070768
closesodoo/odoo#37205
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
From Accounting app under the kanban card "Bank" click on
"Reconcilile items". Select a line to reconcile with a selected partner
or counterpart (or input one) and then filter the underlying lines using
for example the name of the record
No filtering will occur, this is due to commit 900d89c997.
The domain used by the filtering function is matching all lines
from the current partner instead of restricting the search to
the filtered elements.
Reverting that commit and providing a fix for the original issue:
removing a check on the partner id make a logical separation between the
domain involving the partner_id and the one related to the search string,
so that they do not interfere with each other (at most they will overlap).
Preserving tests from the reverted commit and adding some more as well
opw-2070458
closesodoo/odoo#37179
X-original-commit: d434251f3350e033843d941b48cf84f7de28d20f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Customer invoices and supplier refunds lines involved with taxes will be credit lines, hence their balance must be inversed when shown in the tax audit field.
The method is_inbound() encloses exactly those documents, whereas is_outbound() stands for customer refunds and supplier bills.
closesodoo/odoo#37092
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
From the settings activate:
- Multiple Sales Prices per Product
-- Prices computed from formulas
- Discounts
Create a pricelist with discount policy "Show public price & discount to
the customer", set the price calculation formula:
- Rounding: 10
- Price discount: 10%
Modify the sale order xml list view adding 'digits="[3, 2]"' to the
discount shown in the sale order line.
Create a sale order with such pricelist and on the so line put a
product with quantity 1 and sale price 4190 (VAT 19% included in the price).
The discount will not display the requested number of decimal digits (2)
in list view, but it will when editing the field.
The cell formatting is done calling the appropriate function (formatFloat),
which search the digits option from the 'options' parameter or from the field
definition. The latter stores the default digits coming from
the DecimalAccuracy settings, which, as side effect, alter the behavior
of the discount calculation.
https://www.odoo.com/web#view_type=form&model=project.task&id=2069939&active_id=2069939
When passing into edit mode the field is created as widget, parsing its options
which have 'digits', instead when coming back in list mode it is "just a
float field" rendered directly from the list_renderer which no options,
so the formatFloat will look at the field definition
https://github.com/odoo/odoo/blob/12.0/addons/web/static/src/js/fields/field_utils.js#L172
Adding the correct parameter to the dictionary passed to formatFloat
during the list rendering is a possible solution, because it is the
"closest" point in which parsing the parameter is possible without
touching higher level code or forcing the creation of a widget (adding
widget='float' as xml parameter).
closesodoo/odoo#37167
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Initial bug report, full of red herrings:
receive two support requests by email while on Odoo.sh, the first creates a
ticket, while the second replies to the server with the error:
550 Requested action not taken: mailbox unavailable
When a request is done, the service check function tries each request multiple
times when getting Operational errors.
When two email are received within a 'short' amount of time (e.g .1 second)
the two requests are initiated with a new cursor.
When both mails generate the creation of a new record of the same model,
the second cursor is going to fail because of an:
ERROR: could not serialize access due to concurrent update
However, the record we used in the computations needed in the creation of the
second record have been added to the environment.
When that second creation is retried, it will operate on the same records,
and find them in the todo, with the environment that was obtained for the first
trial. Since the cursor is closed, this crashes.
To explain the bug report, Odoo.sh transfers the mail through an xmlrpc
to process the mail.
Because of this crash, the server interprets the lack of well-formed response
by a generic 'mailbox unavailable'.
opw 2060476
closesodoo/odoo#37165
X-original-commit: 845eecdfa7b27d84862e94f4b63d40a851e0c410
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Christophe Simonis