Before that, when using a small screen (with width <= 768 px) and
showing the accounting dashboard of a company without any chart of
accounts installed, the icon and message prompting to install a chart of
accounts was displayed in the lower left corner, instead of being
horizontally centered.
closesodoo/odoo#36974
X-original-commit: 4999f47d7e283c6a5799e68f2b0e1351638e17a3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.
closesodoo/odoo#36973
X-original-commit: 3ab4589ff444da9889ac922ac9d7ba6c8e8638bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following 40487aca5c there was an issue
where a delivery could be splitted because of mrp specific code.
This test checks that when creating a sale order including a level 3
bom (MTO) the delivery is one, containing the correct products
closesodoo/odoo#36961
X-original-commit: c07ecea7923c1609c4461fadbc61040e9fd3d86a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the pivot view, there is the following unsigned measure fields:
"account_tax" and "account_untaxed".
It can cause mistakes since for example the sum of a invoice an its
full credit note should be zero, but here it will be double the amount.
So here we complete 97aec9f8 for two fields that were still available.
opw-2071027
closes#36940closesodoo/odoo#36971
X-original-commit: 2dc8e2feec9e5b604e0c0acae52562822a113342
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The progress bar was pretty broken before this commit.
> It was not possible to input the value as text
> Moving the progress bar to modify value and saving crashed
> modifying the max value crashed
> The whole feature was ill-defined
With this commit, we fix the crashed. It is now possible to write the field
behind the progress bar by moving it in RO mode
or by typing the input in RW mode
*if it is the value we want to write on*
It it is the max value that the field targets, we can do it in RO and RW mode,
only with the input as text
Note that this works *only if* the editable option on the widget is set to true
OPW 2061846
closesodoo/odoo#36928closesodoo/odoo#36970
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In case you have a button of type action, the controller is doing an rpc
on the model using the right method, but in this rpc, the context is not
passed.
This creates a translation problem (nothing is translated) since the
language is not defined in the context.
Task Id 2062419
Closes#36189closesodoo/odoo#36969
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There is no need to redefine `_get_stripe_api_url` by adding `https`
since all existing calls to the method programmatically add it already.
Therefore, we use the same approach: we add `https://`, then join the
URL.
opw-2031745
closesodoo/odoo#36957
X-original-commit: 0412786486462423c91afc1c5a4dcb25886827e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Log an error only if a transaction exists.
opw-2071862
closesodoo/odoo#36946
X-original-commit: 903bd53d5f11dc9a9cfea246e6c5c0a088ad02ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Change the date format of your current lang
- Reconcile a statement
Bug:
The maturity date displayed in the widget didn't use the format of your
current lang.
opw:2068241
closesodoo/odoo#36944
X-original-commit: d2ad3d6542bfe1c900720148f22abe4b507e2a41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit: it gives error when we redirect to payumoney site
after this commit: payment testing in payumoney is working as expected
closesodoo/odoo#36937
X-original-commit: 97c0ece7857ca56b1fd20d3772262def5aeebdc4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reverts d91b1e5bd5
But still handles the use case (cancelling transfer payment)
Make a payment, confirm it
The payment's move has a name, i.e. constructed from its sequence
Cancel it
the payment has no move anymore
Re-confirm the payment
Before this commit, the new move had a new name from a new sequence number
This is problematic to ensure accounting consistency
Besides, it was not the way it works for invoices' moves
After this commit, the former name of the move is taken
to build the new move of the re-confirmed payment
OPW 2046412
OPW 2070167
closesodoo/odoo#36868closesodoo/odoo#36922
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When processing a payment in Ecommerce, if the payment
acquirer communication is defined on 'Based on Document Reference'
and if the sale order sequence is having a suffix, we have
an internal error due to a bad implemented regexp.
opw-2067596
closes#36867closesodoo/odoo#36892
X-original-commit: b08a0025e7900554791a4e42bddcbeb09739a8a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
In case no email address was specified on the delivery address stripe
redirect flow will fail, so we define a fallback on the billing partner
email.
closesodoo/odoo#36833closesodoo/odoo#36862
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* website
Following the new editor merge at https://github.com/odoo/odoo/pull/29775
(which was finally partially reverted for 13.0), the crop dialog was not
working anymore on sub-sequent crop. This was due to 2 things:
1) Re-cropping an image that was just cropped now
The original source of the recently cropped image is saved as temporary
jQuery data on the image element. Unfortunately, for some strange
reason, that image is cloned before any edition and thus lose that data.
This commit fixes the problem by cloning the data too... supposing the
orignal clone is there for a reason.
2) Re-cropping an image that was saved before
This did not work anymore simply because... the cropped images were not
saved in database anymore but saved as base64 data in the view... For
some reason, the cropped images to save were searched in the original
DOM instead of the edited DOM...
Also fixing the random use of a mutex.
Discovered while working on task-2059480
closesodoo/odoo#36878
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With the PSD2 directive coming into effect on September 14th,
was had no choice but to switch our Stripe integration to use
newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for
'redirection' flow to the Stripe Checkout API and from the
Charge API to the newer SetupIntent & PaymentIntent APIs
for s2s flows.
This new modules introduce these changes in a non-intrusive way,
this means that installing this module is *not* required for
all customers (e.g. instances only accepting payment to and
from countries that are not part of the EU), that installing it
will support SCA flows and that uninstallation leaves you with
a working instance as well.
Task 2039100
closesodoo/odoo#36869
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With the PSD2 directive coming into effect on September 14th,
was had no choice but to switch our Stripe integration to use
newer APIs that support Strong Customer Authentication (SCA for short).
This meant switching from the old stripe.js implementation for
'redirection' flow to the Stripe Checkout API and from the
Charge API to the newer SetupIntent API for s2s flows.
This new modules introduce these changes in a non-intrusive way,
this means that installing this module is *not* required for
all customers (e.g. instances only accepting payment to and
from countries that are not part of the EU), that installing it
will support SCA flows and that uninstallation leaves you with
a working instance as well. Essentially a backport of 9f5f2fc
in a seperate module.
Task 2039100
- allow acquirers to arbitrarily include info about the tx in the
processing page
- pending is now a valid state that could require customer action in the
payment processing page - don't blindly redirect to the return url of
another tx if a pending transaction is there
This latest change might mean that customers with many tx attempts might
have a sub-par experience as they may need to click manually on the
redirect url of a successful tx while before they were redirected
immediately.
Be in multi-company, with shared products, let P be a product in company C.
Suppose there are stock moves or pickings in company C'.
Suppose a non-admin writes on P: it triggers an access error.
Stock moves are not shared across companies in all cases.
So fields that depend on product_id might trigger a recompute on stock.moves
that are in another company, and thus trigger a spurious ACL error while
simply writing product attributes.
Note that _cal_move_weight depends on product_qty, however it is not sufficient
to only put that field in compute_sudo; the product_qty has already been marked
as todo, and so it is recomputed in the initial environment.
opw 2066691
forward port of 7d4d8fa18aecb3b78c8d359434a165c1de71a9b4
closesodoo/odoo#36838
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Activate mrp bom cost.
- Create a BoM for a product
- The Compute "Price from BoM" button appear on the product template
below the Cost field.
- Click the button.
Before this commit:
Probably because dynamic variant creation is activated and there is
no variants, the ensure_one fails with 0 records actually passed to
the function.
Additionally, if all the BoM are for variants and there is no BoM for
the template, then there is a division by 0 exception.
After this commit:
A test is performed to avoid calling the function with 0 records.
A test is performed to avoid a division by 0 exception.
closesodoo/odoo#36761
Opw: 2064884
X-original-commit: 42264002070c8acbb781bd111d8a0c31e2ad9716
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Prior to this commit, we would try to decode the logo of a company
without any verification on its presence. If the logo was not set, we'd
try to decode nothing which caused a crash.
This commit ensure that we asert that the field is set before trying to
encode it for a JSON payload.
closesodoo/odoo#36784
X-original-commit: f40f763831bace8c499072ea81ef9bbd5fc910e4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Animations (now public widgets) are now disabled by default in edit
mode. It is opt-in. That one should have been enabled and was left
disabled by mistake.
task-2070930
closesodoo/odoo#36807
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit 5f12e244f6, the write of implied groups is done directly in SQL,
bypassing the ORM writes, and thus bypassing the python constraints checks.
In particular such a constraint was added in f206714af0.
We add back an explicit check of this constraint;
however we rewrite it in SQL to be fast.
closesodoo/odoo#35411closesodoo/odoo#36769
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
For contract of type 'Company' which have no image set, we should display a
specific default 'company' placeholder image instead of default placeholder.
This allows to easily identify which records are companies.
This was already the case up to commit 6153d65664
OPW-2067475
closesodoo/odoo#36783
X-original-commit: 42c08846296d86fb3196f430eec45dd39cf1a8f5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, when printing the Price List report of a Product
Variant, the price is printed directly from the float result of the
calculation of the price, even if this price is rounded, the
representation of the float can have, sometimes, float precision errors
(a lot of 0 after the decimal point, and a 1 or 2 at the end).
Now, the function returns a string formatted to the correct number of
fractional digits.
opw-2069305
closesodoo/odoo#36705closesodoo/odoo#36770
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate variants
- On a product variant without BOM, go to Action > Compute Price from
BOM
A zero-division is raised because of `... / bom.product_qty`.
opw-2067520
closesodoo/odoo#36733closesodoo/odoo#36736closesodoo/odoo#36749
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Forward-port of #36688 (original: #36284)
Before this commit, search view was barely usable with Japanese IME.
For instance, when pressing ENTER while in composition mode and
IME prompts some suggestions, it made a search with the updated input
content. The expected behaviour should have been to update the input
content, without making the search yet.
This commit fixes the issue by turning off some actions of the
search view when typing during composition mode.
opw-2061590
closesodoo/odoo#36728
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Have a model with a parent field
Set his parents like
Parent 0
|
-- Parent 1
|
-- Parent 2
Now, put the Parent 1 as inactive
Open a view with a search panel, which will fetch the parent field as categories
Before this commit, it crashed, because the inner record memory
did not contain a reference to the parent of Parent 2
After this commit, it doesn't crash, and the search panel
just doesn't display parents categories that are archived, nor any children of those
OPW 2070266
closesodoo/odoo#36699
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
-Choose the document template 'external_layout_boxed' or
'external_layout_standard' for client in Spanish.
-Print an invoice.
Before this commit:
the page numbering in the footer is not displayed properly.
After this commit:
the page numbering in the footer is displayed properly
closesodoo/odoo#36741
Opw: 2066838
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When .with_context() is called with a dictionary as 1st positional
argument, it will replace context (and not modify the referenced keys)
It may create bugs when losing the content of the context (e.g. remove
partner's language)
This is a partial merge of #36164 without the inventory part as
discussed.
closesodoo/odoo#36729
X-forward: 4717ccfa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When adding an analytic tag on a sale order line, if there is
a default analytic tag defined matching the criteria, the tag
on the SO line is overwritten in the invoice while it should be
kept.
opw-2068196
closesodoo/odoo#36685closesodoo/odoo#36727
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
-Go to Settings > General Settings and choose the external_layout_background
template.
-Set a client's language to French.
-Go to Invoicing.
-Select any invoice for this client, and click Print > Invoices
Before this commit:
At the bottom of the page you would see "XY" for the page number.
After this commit:
You now see "Page X sur Y".
closesodoo/odoo#36643
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Install l10n_de
- Go in General settings
- Set external_layout_din5008 as Document Template
- Let's consider the customer C with an address and a VAT number
- Create a SO with C
- Print the SO
Bug:
The VAT number of C was not correctly displayed.
opw:2069128
closesodoo/odoo#36673
X-original-commit: b50f51207aa2b4c2d264fc47797a6c123a8ea15e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, in a session with too many open orders the buttons
in the upper right corner, next to the 'delete order button', i.e., the
print button, the connection status, the print button and the close
button, will be pushed out of view. This makes it impossible to check
out, to print, etc., without closing orders.
Now, a scrollbar appears when to many open order and allows to see the
buttons in the right upper corner.
opw-2064409
closesodoo/odoo#36724
X-original-commit: ace930f74c46feafa0759c975e619e7fd1a30780
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
For a couple of clients, the installation of a chart of accounts crashes
because a transfer account is not found. This account should have been created
automatically, but hasn't, or has been deleted.
After this commit:
If no transfer account is found, no account is linked to the "Transfer account"
field of the company, but the installation doesn't crash.
closesodoo/odoo#36693
Opw: 2066557
X-original-commit: d93e5c12bab233d727a6cfb519e77f5fabb73912
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Simple typo; instead of a logger message, an exception is output in the logs.
closesodoo/odoo#36686
X-original-commit: 83030b6ae20bc9d32b2c7a83ea5a1dca33e5f9cf
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Steps to reproduce the bug:
- Let's consider the storable product P and the vendor V
- Set V as a supplier of P
- Archive V
- Go to product P and click on button "Replenish"
Bug:
A RFQ was created with the vendor V
Now when archiving a vendor V, all the product.supplierinfo records linked to V
will be archived.
opw:2066616
closesodoo/odoo#36672
X-original-commit: 5040c17e873b8476c754f1f3e1686c2a02b36e48
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If you:
- have a multilang COA
- create an account.account manually
- add a XML ID with structure {company_id}_{anything} manually
- reload COA translations (install COA language, install COA, set
installed COA since c346e7af3)
=> there is an error since the code try to copy translations of
account.account.template associated to custom XML ID.
fix: ignore this torcivous use case
fixes#36310
opw-2063207
closes#36544closesodoo/odoo#36659
X-original-commit: 0fc0b7484c48fbdcf549e199b5c8cabff3ab726c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The name and address printed on any PDF report (e.g. SO or RFQ) is very
likely to be split on 2 lines once it is long enough. For example,
'My Company (Chicago)' will be displayed on 2 lines.
This is due to 0c6e0d660e and 064eb0a4f4.
opw-2061553
closesodoo/odoo#36498
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since https://github.com/odoo/odoo/commit/01d0523fd76e6d616f36c872f9bff9ca9cd9cbb9, the
_get_alias_values methods is called during the write on the mail.alias.
In this method, the r.sub seems wrong & useless since the alias_name is also checked when
writing on the mail.alias (alias_name is a related="alias_id.alias_name") with a different
behavior that the r.sub.
closesodoo/odoo#36668
--task: 2069650
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the barcode Qweb Field had a
option called "type", which meant what is the mapping between
numbers and barcode, that mapping is called a symbology
https://www.barcoding.com/resources/barcoding-basics/barcode-symbologies/
This option "type" collided with what the qweb engine does
at
```
qweb > _compile_directive_field
that calls
ir_qweb > _get_field
```
It resulted in a crash where type = "barcode" was not a valid symbology
to pass to the barcode lib
It is safe to say that this barcode widget was never user, otherwise it would have crashed
This commit changes that non-functioning API, and the barcode renders well
OPW 2066870
forward-port of #36499 (330d862513dba5bbc4716fe9c8694fd0db696934)
closesodoo/odoo#36499closesodoo/odoo#36658
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Some model can have really complex _order, which can induce unnecessary slow
queries; here as we don't need the right business order we force ordering by
'id' instead
OPW-2007478
closesodoo/odoo#36660
X-original-commit: a1fe8976156a7b6e14aa2d68650176a0e64ba73f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- fixed account types for few accounts
- set reconcile field for few accounts
- added new 'Achats des prestations de service'(code: 61263) account
- reflected accounts in chart template configuration
was task: 1913323
diff taken from PR #30772
X-original-commit: b04477dfa69517a93c3f2209ee98749e30741541
