When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the user needs to be able to correct the payments by cancelling them. It was not possible.
closesodoo/odoo#45082
X-original-commit: 9aec95dccef48a9ec89691f5721619ffc0e4da56
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
VAT, NIF in Spanish, is translated NIT in Spanish from Bolivia
Clean and translate the files with the correct translation.
opw-2197155
closesodoo/odoo#45533
X-original-commit: 641c14f08435b1df1d89184cc00855416bf40bc5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Not setting a value for paperformat_id on 'Company Document Layout'
will also make paperformat_id False on the company but it is required
in the settings.
Without this commit, you can get in the weird situation of being able
to set a value on the document layout but having an error in the
general settings as a required field is missing.
Apply the same logic as in the other views
closesodoo/odoo#45527
X-original-commit: e518063e48936a3f8f9f921950cdae209e67ab47
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Create an immediate transfer for a receipt, add a move, set a quantity
done and due to rev[0], an initial demand is set, then
_autoconfirm_picking is called and action_confirm of picking calls
_action_assign if the location source bypasses the reservation. Set
again an inferior qty_done, the initial demand is also updated due to
rev[0] and somehow the system tries to write on a now unlinked move
line.
fixes
- never reserve an immediate transfer
- never update the initial demand if the move is reserved to fix the
existing databases.
- adapt _compute_state so that immediate transfer moves considered
reserved so that they're always "ready"
- adapt the test that was working on an immediate transfer picking and
setting the initial demand while it's not possible through the
interface, the user can only set the done quantity.
[0] 8303b1aclosesodoo/odoo#45317
X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- In debug mode, create a SO
- Confirm the SO
- Click on "Create invoice"
- In the wizard, click on the debug logo
- Set a User default value V for Downpayment amount
- Close the wizard
- Re-click on "Create invoice"
Bug:
The default value V was not suggested.
Fine tuning of c258b8a0427bd5aface891ed1f4420174f4afde4
opw:2184367
closesodoo/odoo#45512
X-original-commit: f95550d59ddeb8a77cb7b72592cc4aafb210aa25
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
=======
PURPOSE
=======
Avoid communication being lost on transfers due to the fact that nobody is following.
=============
SPECIFICATION
=============
When setting a delivery address, add the contact in question as a follower of the transfer.
When a user validates a transfer, he should be automatically added as a follower of this transfer.
===========
LINKS
===========
task 2172675
pr #44350closesodoo/odoo#45498
X-original-commit: d6a981039005080e4803cb9c75287dfa4ada712b
Related: odoo/enterprise#8483
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When creating a payment, we are expecting only one destination account.
However, when grouping payment by customer, it can happen that there are
more than one receivable or payable accounts, which can create
reconciliation issues afterward.
opw-2188632
opw-2166551
closesodoo/odoo#45396
X-original-commit: 779699297b9767438797ae3678eb9da1db0ce609
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
When requesting multiple tracked content at the same time with the same
visitor concurrent updates happen.
The best way I got to consistently reproduce the issue is to open 2
tracked pages with chrome command line:
google-chrome http://pcodoo:8069/contactushttp://pcodoo:8069/
The first tracked page will update the visitor and lock it.
When the second will try to create a track which has a FK referencing
the visitor PSQL will try to SELECT FOR KEY SHARE the visitor but it is
locked => Concurrent Update Error. Using FOR NO KEY UPDATE instead of
FOR UPDATE performs a weaker lock that will not block
SELECT FOR KEY SHARE. By doing that we garantee that we will not
Update/Delete the PK while we lock the record.
closesodoo/odoo#45491
Fixes: https://github.com/odoo/odoo/pull/38372
X-original-commit: 33d0f0bc6b4c84de61ad876311690f26476c32f9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Open any product kanban view with missing images
A 404 status code is returned for missing images, while they are
replaced by a placeholder.
This can cause issues when configuring a specific 404 page in a reverse
proxy: the proxy will serve the custom page instead of the placeholder.
opw-2192663
opw-2192340
closesodoo/odoo#45157
X-original-commit: 2719c8a0e40f318787b4d7a46626de46a8fd33f0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Missing context key in case of reverse of a vendor bill
it was then adding the anglo-saxon move lines.
opw-2172562
closesodoo/odoo#45432
X-original-commit: 48809f0c1b848142441063371d762a435836b6ec
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Do not use an inactive mail server to send the requests.
opw-2197011
closesodoo/odoo#45375
X-original-commit: ecc4759c03534ccb37ebf9eea202abdf387adca9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
Having a char field referring to an Integer could lead
to unwanted behavior if not managed correctly.
closesodoo/odoo#45393
X-original-commit: d73a86fd682495c034dfde678442f37689ecb759
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, There was no Instrustion to Setup this feature like other Integrations.
Now we display message when we enable this feature for the First time from settings.
closesodoo/odoo#44439
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The icon of the json popover become a warning icon
when there is a issue. Also, create a
field show_json_popover in mrp_production
to avoid using d-none to put in invisible the popover.
task-2178494
closesodoo/odoo#45420
X-original-commit: 270e8d34b2adec07e8ae3b8952514184d2a00b59
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In this commit, added a restriction on "json_popover" field so,
Alert should disappear when picking is done or cancelled state on
list, kanban and form views.
task-2178494
X-original-commit: 12ada1bfa3e85c636f5ea85af675dedad3e7e0e4
The recently added group "Show Full Accounting Features - Readonly" was
shown in the selection of groups of accounting, but the "Show Full
Accounting Feature" wasn't. It was inconsistent and allowed to see the
features too easily (not debug mode needed)
closesodoo/odoo#45419
X-original-commit: ed3adb320c6680bb213965c84b6b7fd5654c8121
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We don't want a next activity for an invoice to be created for OdooBot
if he is the Salesperson. We also don't want a traceback if the
salesperson and the next activity user are not set.
closesodoo/odoo#45417
X-original-commit: 8bf1b72e2b2bdf026b8eff28a554301a598012be
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This information is necessary for tours going from the backend to
the frontend (or the other way around) to run properly:
Some tour steps may be flagged with 'community' or 'enterprise',
meaning they must only be executed in the corresponding edition.
The TourManager filters the steps according to the edition. When
a tour is executed (either in test mode, automatically, or in an
onboarding situation, manually), the index of the current step is
stored in the local storage. So, the list of filtered steps must
be the same in the backend and in the frontend, which couldn't be
guaranteed as the frontend didn't have the information (thus always
considered being in community).
Part of task 2180175
closesodoo/odoo#45398
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When you read a record with the document viewer on the right side
that you don't have write access to this record
and the message_main_attachment_id was not yet set on the record
the document viewer try to set a value for message_main_attachment_id
that raise an access error
Set the value is not important but the popup
Access error can be really annoying
closesodoo/odoo#45378
X-original-commit: 74c36e6bc59af241ea162f042015f637880f1911
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
2 lasts steps are:
- Click on go to checkout
- Ensure checkout total is correct
But the last condition was already true before landing to the checkout, thus
the last step would succeed while the page is transitionning to the checkout.
The following would happen every time:
- Click on go to checkout
- Last step succeed directly after the previous step click on Go to checkout
Then, the following would happen rarely:
- The tour is considered successful
- The checkout page is loaded
- Some GET requests are performed
- The tour is killed (cookies & local storage)
- Some other GET requests are crashing, such as:
`Error loading file http://127.0.0.1:8069/web/webclient/locale/en_US`
The fix simply wait for the checkout page to be loaded as it was supposed to at
first, before checking the last step.
Forward-port of https://github.com/odoo/enterprise/pull/8322
X-original-commit: https://github.com/odoo/enterprise/commit/67686b697c866a5e5ad141a85b3589f1f1598d73
(coupon was moved from enterprise to community in Odoo saas-12.3)
Closes#45097closesodoo/odoo#45395
X-original-commit: 6768d87969f30e40b2e13a32c15330832afb780e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Issue
- Remove ~/.odoorc
- Launch a server
- Try to dump the db in db manager
Ok
- Restart the server
- Retry
pg_dump not found
Cause
When the .odoorc file is not there,
the pg_path option is not present so
the normalize method set it to None
When the server is restarted, it re-checks
the options (which are strings) and in the
normalize method we check "if not pg_path"
but 'None' is truthy so it thinks this is
a real path.
Solution
Check if not pg_path or if pg_path string
is None
OPW-2189789
closesodoo/odoo#45369
X-original-commit: f080964694c01a79c52e05c0ceb42c18d4c77df5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since wizards shall not be unlinked by anyone, but as we want to get rid
of this specific one immediately to get rid of eventual credentials,
do it with elevated privileges.
Before this commit, the behavior was an authorization error when trying
to applying the payment method, in a fresh invoicing configuration.
closesodoo/odoo#45363
X-original-commit: c8ee9c73d4ac9989d05843a32abc535b20d761b4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
We cannot assume reading the value of a monetary field has the
decimals specified by the currency in decimal_places.
Right after creating a record with a monetary field it may have a
different amount of decimals.
To reproduce this:
>>> tx = env['payment.transaction'].create({
'amount': 10.87,
'acquirer_id': env['payment.acquirer'].search([], limit=1).id,
'currency_id': env.ref('base.USD').id,
'reference': 'test'
})
>>> tx.id
130
>>> tx.amount
10.870000000000001
<Restart odoo>
>>> env['payment.transaction'].browse(130).amount
10.87
Authorize requires us to send a correctly rounded amount. The
following response is returned when sending 10.870000000000001:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': '',
'accountType': '',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '5',
'errorText': 'A valid amount is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': '',
'transId': '0'}}
To work around the issue always round when we read amount.
Lower level solutions were considered in #45248 but for now we'll
stick with this higher level and lower risk patch.
opw-2188889
closesodoo/odoo#45362
X-original-commit: 7485927f0eb152086efcaaf4a30260e503267c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Stock introduces the option 'product' for the field `type` of the
`product.template` model.
If there exists records for this model with the aforementioned option
selected when the stock module is uninstalled, the records will remain
in the database for an indefinite amount of time, all while pointing to
an option that does no longer exist (except if the record was created by
the stock module itself), making the registry inconsistent and
eventually leading to a crash.
This is a known limitation of the ORM regarding Selection fields and
more specifically the `selection_add` mechanism, no "generic" solution
has been chosen thus far because it is not always clear which approach
should be taken:
1) Delete the record?
2) Set the option to a fallback, base option?
3) Something else handled by the module itself?
...
In this case the second approach has been chosen and whenever the module
stock is uninstalled, all remaining product.template records of `type`
'product' will be reset to the default option defined by the field,
which as of this commit is 'consu'.
See opw#2193814
closesodoo/odoo#45341
X-original-commit: a84b2829c5fac9e2b0d8cb49a4e7aa73f7e0e2b2
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
We recently transitioned to async option methods, this allows us to have
better control on the order of execution in the edition workflow, and
among other things, keep the editor's UI in sync with the current state
of the DOM.
However, some snippet options (such as the number of columns option)
need to remove or clone portions of the DOM, and as such, trigger the
onClone or onRemove methods of the snippets contained in that portion if
applicable. Because these methods are defined on other options, we first
need to make sure all the snippetEditors for this portion are created,
which is asynchronous.
This commit adds support for an onSuccess callback to the
'clone_snippet' and 'remove_snippet' event handlers, such that options
can choose to be notified when the work has been done, allowing them to
wait for it before proceeding.
This commit also adapts the layout_column snippet option to make use of
that new feature, and remove code that was used as a workaround before,
ie: precomputing the expected number of columns after the clone/remove,
and using that number to adjust the width of the columns and update the
UI. We can now just wait for the clone/remove, and use the real number
of columns currently in the DOM.
closesodoo/odoo#45343
X-original-commit: c159d58ce9cfca4a44f159b18eb10d1138977e23
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- install accounting
- go to the accounting main view and hover some of the graphs
Previous behavior:
rounding was inconsistent and would lead to weird js floats
like 65.00000000000001
Current behavior:
floats are rounded to 2 digits after
opw-2172686
closesodoo/odoo#45336
X-original-commit: c00f4962eb790787fffef99595ac14dbef026055
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since 94a3919, the report_location_barcode.scss asset is never loaded.
The report_stock_rule has the same template id than the report_location_barcode
one. This later is so always overridden.
This commit delete the barcode location css as it was not really usefull
closesodoo/odoo#45340
X-original-commit: 9b610d066d25007561ac469f7caf5919c0aa4092
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The many2one_reference is not a field that makes sense with the
form builder.
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
closesodoo/odoo#45339
X-original-commit: 3e61ca5008e19c36aacedf57836dbd4369607e45
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The original existing fields could be altered once retrieved from the
database. Now we make a copy once we use them to prevent any alteration.
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
X-original-commit: 2951c288ff839ccdf1740cac84dece96823eed8f
UniqueId was not set correctly on multipleInputs
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
X-original-commit: 387b8d698ffd599693fe9feaa9be87e19e3549ab
When some existing taxes are defined with amount_type = "code",
the module uninstallation will leave the current data inconsistent.
Add an uninstall hook archiving the given taxes, logging the problematic records ids.
Fixes#45240closesodoo/odoo#45338
X-original-commit: 16e000b5dcc93a3c90a7d1b6d9d9a6097d5a9849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`action_explode` unlinks the kit move and create the stock moves for the components.
As the `create_multi` is not used, it results in lots of delays. Use the `create_multi`.
closesodoo/odoo#45326
X-original-commit: 4818ee61b4f23ab7b388acd2bdd452c27e25fc0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` is called when confirming the moves of a picking. It
calls unlink() when the move contains a kit. As this method is not
multi, when confirming 50 kit moves, unlink is called 50 times resulting in
a lot of cache invalidation, prefetching and so on.
We make `action_explode` multi in order to call one time `unlink` per
kit levels.
X-original-commit: 096c682e748f7e581e48f0070ec8a3284d8a2fe7
The purpose is to force developers to explicitly manage the removal of
field via migration scripts.
closesodoo/odoo#45269
Related: odoo/upgrade#777
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Simplify the DOM
- Add option to move rows in timeline snippet
- Add data-name to timeline snippet
Part of https://github.com/odoo/odoo/pull/44980
task-2182907
PURPOSE
This refactoring commit removes the crm.partner.binding mixin. Indeed it
defines a mixin for unnecessary fields, generally either redefined in
inheriting models, either not used at all. It also holds an utility method
we moved directly on crm.lead model.
SPECIFICATIONS
Code move
* move _find_matching_partner to crm.lead model;
* move action field into inheriting models, except crm.lead.convert2ticket
that does not use it;
* move partner_id to inheriting models;
* remove crm.partner.binding model and inheritance;
Improve behavior
* correctly store lead and partner many2one fields on all inheriting
models. It allows to support a default_lead_id instead of always
relying on active_model / active_id, making the wizards more generic;
* update default_get accordingly in various inheriting models in order to
correctly compute lead / partner values;
LINKS
Part of Task ID 2056759 (remove crm.partner.binding mixin)
Part of Task ID 2088565 (crm onchange -> compute)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Upgrade PR odoo/upgrade#750
Related: odoo/enterprise#8307
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Hiding fields when they are void is not really helpful.
Spotted when working on task ID 2056759 (remove crm.partner.binding mixin)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
Purpose of this commit is to clean mail and SMS composer calls in website_crm
and website_crm_sms by separating composer preparation (context, values) from
customer preparation (check valid data exists, creating partner).
Indeed most of message composer code is based on records having a partner_id
correctly set, unless some templates are used that dynamically creates the
partner. SMS composer is more tolerant and check for phone / mobile numbers to
use.
By the way we make the action name translatable, because why not.
LINKS
Spotted when working on task ID 2056759 (remove crm.partner.binding mixin)
Community PR odoo/odoo#44970
Enterprise PR odoo/enterprise#8307
oco-odoo