- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Report
- Export as XLS
The header values have too many decimals: 60739.2000000007
The root cause is `convert_to_cache` returns this value:
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
In this case, `currency.round()` keeps the extra digits. Since the field
is not stored, the useless digits are kept.
A simple solution is to use `float_repr` on the non-stored float fields
to make sure that doesn't happen. Another solution could be to not
convert the floats to strings, but that doesn't seem intended.
opw-2378895
closesodoo/odoo#62265
X-original-commit: 2ebcbb16f113dee1416097b7a52f8068a40a34cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The partner is not visible in the form so copying can lead to unwanted
behaviours.
Task 2389917
opw-2388430
closesodoo/odoo#62276
X-original-commit: ef1b3332a523f0afdb954f8eb2abb8f442bdca58
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
The `Adyen Account` menu entry leads to an external page.
This cannot be tested by the click_all test.
closesodoo/odoo#62269
X-original-commit: bcbbe3dd80bfe50bf897ce620da0bd7ddb3c3094
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
PURPOSE
To ease the scheduling process, we introduce a new calendar view on mailings
that allows to easily schedule your communications. In addition, mailings and
sms views are improved to ease global usability especially about scheduling
configuration.
SPECIFICATIONSS
- add a calendar view to allow marketeers to either schedule or overview their
ongoing mailings/sms;
Side note: inspired by what has been done with Social Posts
- improve the scheduling flow by allowing to configure it directly in the form
view using fields rather than action buttons that open an extra window. This
implied removing the schedule wizard as everything is now configured directly
from the mailing form view;
- add a constraint on 'schedule_date' to make sure it's not scheduled in the
past;
- compute a calendar_date to be used by calendar view. It is either sent
date (if sent), next departure of cron (if in queue) or schedule date (if
scheduled).
- update mass_mailing_sms to match scheduling flow of emails and adjust the
'sms_force_send' display to ease understanding ;
LINKS
Task ID-2202759
COM PR odoo/odoo#57000
ENT PR odoo/enterprise#12920
UPG PR odoo/upgrade#1736
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
It was impossible to validate the cash control popup if the value was 0.
Now it's possible to validate any amount, including 0.
closesodoo/odoo#62256
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
During the uninstall step of the registry, we perform a commit right
after the uninstallation of all module data, this commit is performed
right before the creation of a new registry, this means that said commit
will call `flush_env` and thus `recompute` on an environment that is
based on a stale Registry (memory and database are unsynchronized).
This means that during this specific moment, there's a chance that the
recompute function may have to fetch some fields it depends on to
perform its computations if said fields are not in cache, this in turn
means that it will try to prefetch fields that are potentially no longer
in the database, making the registry crash and preventing the uninstall.
This is what happened with multiple if not all `payment_*` modules, the
main module `payment` depends on a `ir.module.module` record, most
notably the `color` field of the `payment.acquirer` model which depends
on the `state` field which in turn depends on the
`ir.module.module.state` field.
This meant that uninstalling a module such as `payment_paypal` triggered
a recompute of `payment.acquirer.color` during uninstall, and to perform
that computation we need several `payment.acquirer` fields to be fetched
from cache or the database. If in cache, the uninstall would go through
without a hitch, if not in cache, we would fetch the required fields
from the database but we'd also attempt to prefetch the fields
introduced by `payment_paypal` that had just been deleted from the
database!
To avoid this, the `_module_uninstall_data` method of `ir.model.data`
will henceforth guarantee that `ir.model.fields` that are to-be-deleted
will have their prefetch set to False, meaning only existing fields will
be fetched from the database during the uninstall of extending modules.
Fixes#60424
opw-2372598
closesodoo/odoo#62247
X-original-commit: 7bffd2df0d5d7eff841cdf7ba7cb6ea84a5c5c49
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
In unit tests, this avoids side effects from one test to another. In
particular, a test modifying the user's company can make other tests
fail because `env.company` defaults to the user's company when nothing
else is available in the context.
The now unique class behaves as the former class `SavepointCase`. It is
now up to the developer to use `setUp` or `setUpClass` for preparing the
tests.
Steps to reproduce the bug:
- Let's consider the current company C in Germany with a VAT number
- Let's consider a partner P in Belgium with a VAT number and fiscal position Geschäftspartner EU (mit USt-ID)
- Let's consider a product PR with weight and a 19% tax
- Make a cutomer invoice CI to P with PR
- The 19% tax will be replaced by Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG)
- Post CI
- Go to the Intrastat report
Bug:
PR didn't appear in the report
As wrtote here: https://github.com/odoo/enterprise/blob/13.0/l10n_de_reports/models/partner_vat_intra.py#L21
The taxes considered in the intrastat report must be with as least one of these tags:
- l10n_de.tag_de_intracom_community_delivery
- l10n_de.tag_de_intracom_community_supplies
- l10n_de.tag_de_intracom_ABC
But Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG) didn't have one of these tags
Same for Steuerfreie Ausfuhr (§4 Nr. 1a UStG)
opw:2379263
closesodoo/odoo#62245
X-original-commit: e72b3fc9b899f93b515c6c4bb8287e21133a5946
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The way QWeb handles text nodes and node tails makes it generate
white spaces copied from the XML indentation even before the first
useful character
Before this commit blank lines appeared at the beginning of generated
documents as well as inside the document content
After this commit no blank lines appear at the beginning of generated
documents and blank lines inside document are removed
task-2366756
https://github.com/odoo/odoo/pull/60850closesodoo/odoo#60850
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit only the first default palette color was configurable
on illustrations
After this commit all 5 default palette colors are configurable on
illustrations
task-2368585
closesodoo/odoo#60503
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Activate multicurrency:
* EUR with rate 1.0
* USD with rate 100.0
Have a company in currency USD
Create an invoice (in USD)
* invoice line of 12.15, no tax
Save, post and register payment
In the payment widget change currency to EUR.
The amount will be automatically converted in 0.12
Register payment
Invoice will be still marked to paid as the amount paid is 12.0.
This occur because the system does not check if the amount to be paid,
expressed in payment currency, is what has been paid.
opw-2376336
closesodoo/odoo#62238
X-original-commit: 967a2ab323e273c853aee0edd5ce404f4d14e6ab
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The replenishment menu is available even for users that are not allowed
to use it. This causes the click_all test to fail with a warning.
closesodoo/odoo#62232
X-original-commit: d22daa8baa78fdcc9202657ab94e849f5690187f
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This commit makes it so a note is logged when an unbuild order is linked
to a manufacturing order is completed.
closesodoo/odoo#62012
Task: 2378831
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
resize_class can be missing from the properties
opw-2379828
closesodoo/odoo#62092
X-original-commit: e07757b1e941c33fd76f79aaafe8398f611721d2
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, `destination_account_id` field was not required on model/view, Creating record without `destination_account_id` is not allowed since it is required on `account.move`.
Now field is required.
closesodoo/odoo#62218
X-original-commit: daac5e3c720b42b062445e72d70a834d591f953f
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Create two companies on a multi-company database without Website installed.
For this use case, install Purchase
2. Configure two distinct logos per company
3. Create a Purchase Order with the second company.
4. Send PO from second company over as email.
5. Check recipient email (or mailhog for Runbot) for the email
6. Find that while the PDF report reflects second company's logo,
the header navigation bar in the client email when clicking "View Request
for Quotation" reflects company_id=1's logo.
What is currently happening ?
The displayed logo is not the correct one.
What are you expecting to happen ?
Display the right logo.
Why is this happening ?
Because when rendering the view. The value of 'res_company' declared in the context has as value the id of the default company of the user
How to fix the bug ?
Specify the current company.
opw-2380274
closesodoo/odoo#62066
X-original-commit: 044bca5e64451d86c6f7c9dbb919c0c319a37bd5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
The German date format is the following: DD.MM.YYYY but when importing
such value, it is wrongly considered as a float value due to the '.'
being confused with the thousands separator in the regexp of method
_remove_currency_symbol.
We should check both date/time and float/monetary formats, so it will
correctly identify the German date format as well as float values.
closesodoo/odoo#62205
X-original-commit: 1bdd0cc247d36c869ffdee7d501cb65d36be47a6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
WHY: this is needed for project_timesheet_forecast_sale, which adds employees
from planning.slot records
---
opw-2378102
closesodoo/odoo#62193
X-original-commit: ed8f7009ee89f162d8c752efa5335b885a27c389
Related: odoo/enterprise#14919
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Changelog:
[FIX] DomLayout: Make sure falsy attribute values are not transformed into null
closesodoo/odoo#61875
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When chatting with visitors, operator may use /lead command to directly create
a lead from discussion. That way commercial discussion can follow visitors
inquiries.
Anonymous (public) users may be part of channels, notably since f5fe11cf1e.
In that case we don't want new leads to be associated with those users. Indeed
* they are not real users, just technical users for website / frontend;
* merge processes may think all leads having public users as customer are
duplicates and should be merged, which means loosing information and
leads;
We therefore set the following heuristics
* if a public user is member of a channel -> consider this is a livechat
with an anonymous and set customer_id to False;
* otherwise try to find a share partner in channel members and link the lead
to that partner;
Task ID-2389564
closesodoo/odoo#62192
X-original-commit: 7fbeda3f7d92fa501c2752c873be2255697f5d97
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
When sending a message by clicking on the "send" button manually, the focus
should stay on the text input (and the mobile keyboard should stay open), so
that it is possible to quickly send another message afterward without having to
re-click manually on the text input
SPECIFICATION
the focus should be set to composer automatically after sending a message
LINKS
closesodoo/odoo#62179
Taskid: 2372546
Pr: https://github.com/odoo/odoo/pull/61226
X-original-commit: 6cc5d4ae9ed2d7dbbad51ae720365730c8a416ac
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- Install eCommerce
- Enable debug mode
- Go to Website > Configuration > Websites
- Configure Website by adding a Selection field in "Product Page Extra Fields" (i.e. Product Type)
- Go to Website and from Shop, open a Product
- In Customize menu, enable "Show Extra Fields" options
A KeyError is raised with "selection" key.
By using "selection" widget, the value is processed by SelectionConverter, which tries
to retrieve the text linked to the value by accessing missing "selection" dict in options.
As the feature was originally designed to support "char" and "binary" types, the selection
of extra fields displayable on eCommerce Product page will be restricted to these 2 types.
opw-2378753
closesodoo/odoo#62151
X-original-commit: 87ea687169c9a0047b41b11ab143544142c82aae
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The rating emails were still sent even if the rating feature was
disabled on the specific project.
This commit ensures the emails are only sent to project with the feature
enabled.
closesodoo/odoo#62181
Taskid: 2390802
X-original-commit: 3fe5416f07e76ccca6c0bb05a6fa12d8e2ca0e6c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Currently, when the user is using the quick create card of the kanban view, the
card will automatically close itself if the user clicks on a tooltip element
from a tour.
This can lead to bad user experience since the tour tip can be visually
*within* the quick create card, and the user will not understand why the card
is closing.
More importantly, the tooltip element "zone" is bigger that what it visually
looks like and you may click on an element (a field, ...) that seems to be
perfectly within the quick create card but is in fact part of the tooltip.
This commit fixes that behavior by preventing the click event propagation in
the tip widget handler.
The fix is made in version 14.0 because this is especially problematic for the
tour of the "CRM" app, that heavily uses the quick create card in combination
with tour tips.
Task 2388450
closesodoo/odoo#62175
X-original-commit: 48d30e1375cc25fd430cdcb53e9b849be295ac26
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Fax field was removed somewhere between Odoo10 and 11. However there is still
some leftover about fax in contact widget. As there is no fax field anymore
and as it is easy to add it through inheritance let us remove it.
Closes#62105closesodoo/odoo#62182
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the website header template uses the user's photo, and if this one does not exist, a 500-error is returned.
To reproduce the error:
(Need website)
1. Go to the website
2. Edit
3. Change the header template
- Select one that uses the user's photo
4. Save
5. Go to Settings > Users & Companies > Users
6. Select your account
7. Edit
8. Remove your photo, Save
9. Go back to the website
=> 500 error
When the user doesn't have any photo, the template uses the placeholder image.
OPW-2378269
closesodoo/odoo#62174
X-original-commit: ae0acf83cee73f6617200387bb923bf875e1830b
Signed-off-by: adwid <adwid@users.noreply.github.com>
The test highlighting the current issue has been posted in PR
https://github.com/odoo/odoo/pull/62076
But it is not included as part of the current PR because it is too slow to
execute, while it is unlikely we will break this fix as it is not influenced by
anything else in the code.
The reason why we need this change is because on some database, including ours,
we have users who have more than 1000 failures still unresolved and they are
all returned at init.
closesodoo/odoo#62173
X-original-commit: 32ed8125aeb356e568d3c49ef7a04c0ff9e36169
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
`MessageSeenIndicator` sub-component should not be rendered if the thread does
not support seen indicators.
The issue is manifesting because the otherwise empty indicator has a margin,
which is adding more space than expected before the following element.
closesodoo/odoo#62172
X-original-commit: 4e0e8a415ae2175cd68e514cff33b2bffeb99db7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When searching for a channel in Discuss, the search results include
all matching channels even those user is already member of
task-2347837
closesodoo/odoo#62161
X-original-commit: 884bebb0f549dc4385cec9542f74e0bba64ccb08
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since odoo/enterprise@93ac6e5116 a the `Add Bank Account` menu is using
an new proxy server. As it's an external service, it's not desirable to
click on this menu during the test.
closesodoo/odoo#62157
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
1. Create a storable product
2. Set the category: Costing
- Method: First In First Out (FIFO)
- Inventory Valuation: Automated
- Price Difference Account: Price different accounts.
3. Create a vendor bill with the product and the quantity set as 0, and set a tax
4. Post the vendor Bill
A ZeroDivision error is raised.
opw-2375464
closesodoo/odoo#62120
X-original-commit: beeb83ca53c52dc189faaff4d76711bbcf24a08c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
XML loading always raises a ParseError, however when an XML loading error is triggered from an HTTP request (e.g. a button) the final ParseError logged & shown to the user would not be properly chained to its ancestor, leading the original cause to be lost and issues being much harder to diagnose.
This cause is lost in _handle_exception where we duplicate the exception in order to chain it correctly, the __cause__ of the source exception was not properly copied over, and would thus break the chain.
The fix also requires explicitly chaining the ParseError to its cause, this should not be necessary but the cause is also lost if this is missing, it is not clear why.
opw-2381776
closesodoo/odoo#62117
X-original-commit: 650476812ee7d57f1d954be5557a3856448ffe5e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Step to reproduce:
- Create a subcontracting BoM by partner A,
for a tracked product B (by serial or lots)
- Create a incoming transfer coming from A and mark as todo.
- Fill the move with move lines with lot + quantity.
- It is impossible to validate the transfer, "You need to supply lot..."
Also at the creation of the picking a warning popover indicate that
the previous operation (the hidden MO) is set after the transfer.
These issues comes from the refactor of mrp for v14 and the part of
subcontracting wasn't complete obviously.
Fixes done:
- Rewrite the code of the `_action_done` for subcontracting. It is for
the case of tracked finished product without any tracked component,
there wasn't any code to manage that. Now manage it by backorder MO
feature. Fix the main bug
- Set finished_date_planned before the transfer to avoid the alert
popover.
- Avoid to write activity in channel about the hidden MO in case of
cancelling.
- Fix `action_record_components` to manage multiple subcontracting
products with tracked component.
- Remove the `priority` field from the wizard MO (in case of tracked
product. Also the wizard is not really a wizard, just a weird hybrid
MO form)
PR: odoo/odoo#61606
task-2357115
closesodoo/odoo#62109
X-original-commit: 1a34e46eaca14aec981dd0f162e8014c7cb0abea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this fix, trying to authenticate via
xml-rpc call from PHP following the documentation at
odoo.com/documentation/14.0/webservices/odoo.html#logging-in
raised an error:
> $uid = $common->authenticate($db, $username, $password, array());
TypeError: 'list' object is not a mapping
Because PHP doesn't have separate array and mapping types, the
XML-RPC encoder disambiguates based on the existence of
key => value pairs, such disambiguation yields an empty xmlrpc
array for an empty PHP array, which is unexpected on the Python
side.
Relax the check on the Python side:
* fixing this on the client side requires adding arbitrary and
meaningless key => value to the empty array to force the
correct disambiguation which is ugly and weird
* the example code has been there for a long time, so there's
probably lots of such PHP code in the wild
opw-2388141
closesodoo/odoo#62101
X-original-commit: 9f97b7435977c81a079004b7c2186ce75526490c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Prior to this fix, replacing a jpeg image with an svg illustration
didn't properly update its mimetype in its dataset. As an effect, the
jpeg image options still appeared, that were irrelevant for an svg.
This was caused by a premature update of the image in Jabberwock's vdom,
before the mimetype was updated, and by the fact that the current image
was not being passed to the constructor of the media dialog, causing it
to create the image from scratch on save instead of replacing the src
attribute of the current image like it did before introducing
Jabberwock.
closesodoo/odoo#62082
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Website event track module is an advanced event module that is required notably
in some sub modules: live, quizzes, exhibitors.
When unchecking Schedule & Tracks in event settings, submodules checkboxes
are hidden. It means that currently you may uncheck module_website_event_track
while still keeping sub modules (_track_live, _track_quiz, _track_exhibitor)
checked. When saving, modules are uninstalled, then installed again if one
of sub module is still checked.
In this commit we add an onchange so that unchecking track also unchecks all
its sub modules to effectively remove them all.
Task ID-2389569
closesodoo/odoo#62027
X-original-commit: 29f12da08dbbe6037e530dcae9cf570b71894136
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Nicolas Martinelli