Purpose
=======
In the case a time off is created:
- In the past
- Using support documents
An invalid user error is raised in the interface, because the webclient
is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])])
which is writing by inverse relationship on the field 'attachment_ids'.
On the other hand, it should be possible for an employee to add attachment
on the time off after it has begun.
closesodoo/odoo#103626
Taskid: 3032232
X-original-commit: c32c22ec267626322aebb7af4ee36b573c71760d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Allows more granularity on the activity reports by adding
a column to the tree view of crm activity reporting. Those
are the tags of the lead of the activity. Remove useless 'api'
import.
Also, make them available in the search bar and default show in
the tree view of activities. Improve the view with an avatar
widget on the author and default hide on the description.
Task-2991375
closesodoo/odoo#101245
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
The price_reduce field is not shown to the users, and was not useful for
business computations because of its digits specification (losing decimal data
when we only want to round the total amounts, not the price before taxes).
This commit removes the field to reduce the table size, remove useless computation,
avoid misuses of the field and clean code.
Task-3018371
closesodoo/odoo#103611
Related: odoo/upgrade#3977
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When choosing an image url from non-odoo pages, there is an access token
sent at the end of url. Because of this, slide_course_publisher_standard
didn't work as it expected jpg image name at the end. Now it will simply
find a match for said jpg image and won't fail. Also, before this
commit, default image was not editable with website editor.
Task-2908029
closesodoo/odoo#103620
X-original-commit: 00f9fca584f39d028108762dccef11447747b591
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Product Category, income/expense Account only select accounts with Internal Group is income/expense.
But in Product, income/expense Account don't have that domain (although the domain above is not wrong).
=> This in my opinion causes confusion for users when using
The way to handle it, I will remove the domain part in the income/expense account to match the experience
closesodoo/odoo#103588
X-original-commit: f736f50548438cf144c7882651043fbccad72c98
Signed-off-by: Laurent Smet <las@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
When the dark mode feature was merged with [1], it adapted the
EditWebsiteSystray item with the 'text-reset' class.
But this class was not removed if the website was translatable, and it
was not added on the TranslateWebsiteSystray item, which was leading to
wrongly colored systray items on a translatable website.
[1]: https://github.com/odoo/odoo/commit/ee3aa3054cdd715720466863239d5aa56186946c
X-original-commit: 9bc4987d8a4a3d1e5ff31d6e2fd3ea4b453fe21c
Part-of: odoo/odoo#103562
In the Website Builder, when clicking on the THEME tab, and clicking on
the "Switch theme" button, the loader behind the dialog was not placed
correctly.
After [1] moved the manipulators inside the iframe, the css rule for the
loading elements was not updated to remove its right value, used to
position the loading element next to the right panel.
[1]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
X-original-commit: 106a5a56a96090ae4adfd9e7b3ea2f93d69dca22
Part-of: odoo/odoo#103562
Actually if the customer pay with a electronic payment method the order
is automatically validated.
With this commit we add the possibility to activate or not this functionality
closesodoo/odoo#103569
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.
This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.
Fixing #74647 (from 16.0 to master)
closesodoo/odoo#103572
X-original-commit: 95f8266a5b84f5faa59a713019ab713392b3ef78
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing
Issue:
When using the register payment with a token with any of the payment acquirers,
if there is a concurrent access error during the reconciliation process,
the payment intent is sent multiple times to the acquirer, making the card charged multiple times.
Steps to reproduce:
-Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing
-Configure Stripe with your public and secret key (2FA is now enforced for Stripe accounts, therefore,
we don't have a generic test account anymore. You have to create your own.It is quite fast and easy to do)
-Have a portal user PU with an already registered payment token PT
-Go to Invoicing
-Create a new invoice I:
-Customer PU
-Add anything in invoice lines
-Confirm I
-Register a payment for I:
-Journal: Stripe
-Saved Payment token: PT
AT THIS STEP, YOU MUST ENSURE A CONCURRENT ACCESS ERROR WILL RAISE DURING THE RECONCILIATION
-Create Payment
Log analysis:
A first payment intent is sent to Stripe. The card is charged and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment intent is sent again to Stripe, The card is charged AGAIN and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
For each retry, the intent is sent and the card is charged.
If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Stripe's side and the card will be charged 3 times.
This PR mitigate this behaviour.
It doesn't address the root cause but by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent mutliple payments to happen.
OPW-2662964
closesodoo/odoo#103515
X-original-commit: 5fe1c1bbba4d754eed7e8927b82752969d6f563d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This fix corrects the measure 'timesheet_revenues' calculation
in the Timesheet report.
It is now billable_time * aal.sol.price_unit.
task-3007122
closesodoo/odoo#103513
X-original-commit: 3729c024a4a76b453d21d56805b7f5d4390cf9f3
Related: odoo/enterprise#32937
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
The purpose of this commit is to fix an indeterminate error in
the test_03_sale_quote_tour.
Error: UncaughtTypeError: Cannot read properties of undefined (reading
'unselectable')
Why:
In the autocomplete component, it is possible to replace the sources
without it being rerender. It is therefore possible to click on a option
that no longer exists in the component's internal state, which causes
the crash.
Solution:
We wait that all the sources are loaded before replacing them.
closesodoo/odoo#103497
X-original-commit: f25df0be75082caf9e8ed62c581a13fe82a27546
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Steps to reproduce the bug:
- Let's consider a customer C with default sale payment term 30% Now, Balance 60 Days
- Go to the POS and open a session
- Select a product and set C as customer
- Click on Payment and select Cash and check Invoice
Bug:
A traceback was raised because several account move lines are created.
opw:3009062
closesodoo/odoo#103589
X-original-commit: 15f586b3dec5c951b10a7eea5aca219ad466da9b
Signed-off-by: Masereel Pierre <pim@odoo.com>
If the credential of Adyen are not correct and refresh POS after a payment
The cashier are unable to cancel or remove the payment line
Because the longpollong continue to reach Adyen to try to get a response.
This issue come from the last on POS_adyen commit:
262e50e2b2fb70d882fef536deb8ba253833639b
With this commit we stop the polling if we can't reach Adyen server
So the correct status is setted at the payment line and the cashier
can delete it.
closesodoo/odoo#103582
X-original-commit: 3a649dddb6d13bc96d281becc6387953c053223a
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
The Owl web client does not suppress GTK-style mnemonics, so these
should be removed, as otherwise they are explicitly displayed.
Following GTK rules, the old GTK client would use the `_` letter
prefix in labels to underline the letter and use the corresponding
character as accelerator/mnemonic for activating the
control (https://docs.gtk.org/gtk4/ctor.Label.new_with_mnemonic.html).
The web client "supported" this feature by just ignoring and dropping
the `_` it found in labels, even after it gained support for keyboard
accelerators (= hotkeys).
The new Owl form just ignores GTK-style mnemonics entirely, not
performing that preprocessing on widget labels. As a result, the
mnemonic marker (`_`) now appears literally in some labels, and needs
to be removed.
closesodoo/odoo#103563
X-original-commit: ca80632a1045b26927f72d93f4ec58e7a58b5654
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The label for due date was targeting invoice_payment_term_id
instead of due date, thus not profiting from the readonly rules
and being muted when it should not.
closesodoo/odoo#103344
X-original-commit: 9da25683e918838609ffdac87c979f883d11d027
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Move code from components to models, so that eventually all the
business logic is in models.
The benefit of business code in models is to ease proper modelling
of whole state of the discuss features, which is highly desireable
for easily maitainable code or to implement sophisticated features
in a robust way.
[IMP] mail: move code to models (AttachmentViewer)
Task-2996277
[IMP] mail: Move code from components to models (DropZone)
Task-3004211
[IMP] mail: move code from components to models (ChatWindow)
Task-3004259
[IMP] mail: Move code from components to models (ChatWindowHiddenMenu)
Task-3014736
[IMP] mail: Move code from components to models (ChatWindowHiddenMenuItem)
Task-3004253
[IMP] mail: pass only record as props (ChatWindowHeader)
Task-3001202
[IMP] mail: Move code from components to models (MessageList)
Task-3004204
closesodoo/odoo#103591
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, the website_livechat request tour would fail
in an indeterministic fashion. This was due to the fact that
the message that was supposed to be sent through the bus was
directly given to the message notification handler.
The second message could or could not be received according to
the timing of the channel subscription. Indeed, the listen/notify
mechanism is not activated during test, but the subscribe method
directly fetches notifications from database and return them through
the bus.
In order to solve this issue, let's rely solely on the bus instead
of directly calling the message notification handler.
closesodoo/odoo#103590
X-original-commit: 8964453597fb01161791b2b2064f45efa42277a6
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103579
X-original-commit: ee1a8d26f241f2f7bea6880afcc946119b0e6bd8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The same override of `_get_view` was done in `res.partner` and `crm.lead`
in order to call `_view_get_address`, to change the address format
of the partner and lead form.
The definition of `_view_get_address` was already shared between these
two models through the `format.address.mixin` mixin.
So, why not share the override of `_get_view` also in this mixin,
so only one override needs to be written, instead of two.
In addition to merge the code of the `_get_view` override
in `format.address.mixin`, also set the `_get_view_cache_key`,
so the partner and lead form are correctly cached by company,
in case multiple companies in a same db use different address views.
Before this revision, this wasn't the case for `crm.lead`,
which therefore leaded to a bug when two companies where
using different address view, and one company accessed the lead
form before the other, therefore caching its own view version
in the cache, re-used later by the second company when fetching
its own lead form.
This revision takes the opportunity to add a unit test for crm.lead,
to assert the expected form according to the company address.
There was already a test for res.partner, but not for crm.lead.
To avoid copy/pasting the unit for both models,
a common test class is created, re-used to test both res.partner
and crm.lead.
closesodoo/odoo#103438
X-original-commit: 7e4a8b77024af663c5555c6d56557e2c6136b24b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The code removed by this revision was initally introduced in
odoo/odoo@126ba0a9a8
The `_get_view` override introduced relied
on the context key `opportunity_id`,
which was set in the crm.phonecall form view with
```xml
<field name="opportunity_id" on_change="on_change_opportunity(opportunity_id)" context="{'opportunity_id': opportunity_id}"/>
```
as you can see in the above mentioned revision.
This above node was removed 7 years ago in revision
https://github.com/odoo/odoo/commit/ff2b14d4c3c5aaa62418b527585d0a19e98a23de#diff-892062d6151c1e1c1cb5f6c09035df1d5ae6d5a71f7558aacfdc8cf62627bf5fL138
Therefore making pointless the code about it in the `_get_view`
override.
In addition to this clue to make sure the override is pointless,
checking the code, we can see it relies on `get_formview_action`
to set a different view according to the result of `get_formview_action`.
Since revision
https://github.com/odoo/odoo/commit/e28d3aa4d3851d72deba08c236072d002f83216a#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2L1224
the override of `get_formview_id` is removed,
therefore making `get_formview_action` of `crm.lead` completely default
(as there is no override of `get_formview_action` either in crm.lead,
nor any dependent method)
We can therefore assume this code was useless,
at least in standard odoo,
and can therefore be removed.
X-original-commit: 82c2f4b13034c16ca5546afd777150ecb4d8ad9b
Part-of: odoo/odoo#103438
Before this commit, when a recipient is suggested in composer header
and current user click on checkbox, there was the following warning
in the console:
```
read-only SuggestedRecipientInfo/isSelected on record(SuggestedRecipientInfo_1) was updated
```
The state of a selected suggested recipient is determined by being
manually selected on UI, but also that there's a partner related
to this recipient. `isSelected` is a computed field with itself
as dependency, and it was also imperatively set. We don't want
any computed field to be set imperatively, hence the warning in
the console.
This commit fixes the issue by introducing another field that
is specific to selection on UI by current user. This field does
not depend on whether there's a partner. This field is imperatively
set, and then `isSelected` is fully declarative as a computed field
with no self dependency and no imperative update.
Task-3032869
closesodoo/odoo#103573
X-original-commit: 8e2980e1e871a8046f09d3d0affb6400ee030eeb
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Current behaviour:
We get a traceback when opening a POS session with restricted categories
Expected behaviour:
We should be able to start a POS session with restricted categories.
Steps to reproduce:
- Install POS
- In POS global settings add any category in the restricted categories
- Try opening a new POS session
Reason for the problem:
Incorrect domain right leaf, the reference field that is a pos.category
is not de-referenced.
Fix:
Add `.ids` at the tail end of the record reference
Affected versions:
- 16.0
- master
opw-3021490
closesodoo/odoo#103548
X-original-commit: 8c76afc161133b78239cf91d746a159d67f67c4e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The search bar could be hidden when there was no categories in the PoS. This
was due to the new design where the search bar has been moved to the categories bar.
closesodoo/odoo#103514
X-original-commit: eadaa267c689415eeaacaeba23c663b95a1d12d2
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This allows launching Odoo with "python -m odoo".
This manner of launching python applications is now widespread.
In particular it makes it easier to configure an IDE debugger to run with the correct python version.
closesodoo/odoo#81864
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Steps to reproduce:
- create two journals, A and B, which have the default accounts defined in the payment method manual in "outstanding receipts accounts".
- create a payment with a journal A;
- duplicate the draft of the payment (because it is not possible to change a journal if it was posted before);
- select the journal B and save (or confirm)
- The journal is changed, but the default journal B accounts are not applied.
Issue:
Despite the payment is in draft and has not been posted before, move_line accounts do not change with the journal selected for the move.
Cause:
When a payment is duplicate, records are save in the database.
Modify the journal en then save will trigger the write method of the payment model (and not the create).
During this method, we begin to find the move lines which correspond to liquidity, counterpart and writeoff lines.
Unfortunately, the line corresponding to the old journal will be detected as a writeoff and not as a liquidity line (because the journal has changed).
This fault will cause a balance error in the rest of the procedure.
Solution:
Take into account the case where writeoffs are detected when there is no liquidity line (and no counterpart line).
In this case, force the no writeoff line.
Generate the correct ORM commands taking in consideration if the line exist (1: update) or not (0: create).
opw-2998031
closesodoo/odoo#103496
X-original-commit: cf277b2685a72e0a8ca44c4a59331136a722fbed
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Followup of: odoo/enterprise@b58637f1ab
That completely removed the firebase_admin library support, making this warning
ignore line not necessary.
Task-3000338
closesodoo/odoo#103474
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Now that the module web_dashboard has been removed https://github.com/odoo/enterprise/pull/31641,
some props of the reporting views graph and pivot have become unused.
We remove the code related to those props.
X-original-commit: 7d231d1d37707dab4b0ecdd4e2e7cc4535ba6196
Part-of: odoo/odoo#102761
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Current behaviour:
When an indonesian customer buys from the POS and generates an invoice,
we get an error of missing kode_transaksi of the customer,
even tough it it correctly set on the invoice details of the contact.
Expected behaviour:
Every indonesian contact with correctly setup up invoice details,
should be able to checkout from POS and generate an invoice without
problems.
Steps to reproduce:
- Install indonesian accounting localisation, the efaktur module, POS and Contacts
- Switch to the Indonesian company
- Create a new Contact, add a VAT, check ID PKP,
and in Invoicing fill the whole "Indonesian Taxes" section
- Add a valid invoice range in the e-fakture general settings
- Setup a POS Session if non is present, it's irrelevant, start a new session
- Try to buy something with the new contact as customer, and generate a new invoice at checkout.
- You should have a pop-up error about the "Kode Transaksi" missing.
Reason for the problem:
The `l10n_id_kode_transaksi` field is not present in the values used
when generating the moves for the invoice.
Fix:
Add a compute that fetches the kode_transaksi from the partner_id linked
to the move.
In the meantime, we needed to inverse the readonly states logic (keeping
the same behaviour) in order to avoid the compute being triggered in the
constraint.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-2993838
closesodoo/odoo#103457
X-original-commit: cfa43a9ccba225c84972a5d5f9443d9997bd7b31
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
* The default order of `account.move.line` includes the `sequence` since
080d41a341
This field was not indexed and was leading to poor performances when
opening the list view of journal items or when searching without
overriding the order.
* A typo in `_get_invalid_statement_ids` was leading to recomputing all
the validity of all statements when we only needed to compute a few
* Domains on `account.move.line` often include filters on related
fields, including the accounts' and payments' types. This can lead to
multiple sub queries that are repeating the same thing.
closesodoo/odoo#103466
X-original-commit: 99d7d0a7b875ffb1e5ce00cd7f3fc2c9e0359796
Related: odoo/enterprise#32908
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, when the domain used in `read_group` and `search` to
check if the portal user can access to the fields used in the domain
does not take into account the `TRUE_LEAF` (that is, `(1, '=', 1)`) and
`FALSE_LEAF` (that is, `(0, '=', 1)`). In other words, when the
`TRUE_LEAF` or `FALSE_LEAF` is in the domain, an access error is raised
saying the field name `1` or `0` cannot be accessible by the portal user.
This commit allows to add `TRUE_LEAF` and `FALSE_LEAF` in the domain to
avoid having an access error because of that.
close#103214closesodoo/odoo#103465
X-original-commit: 953033e1ab20a01918dae7ca495654cddef14af3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
WebClientViewAttachmentViewContainer was missing in the FormRenderer components
This prevented opening account.payment lines from the Batch Content tab of Batch Payments
closesodoo/odoo#103450
X-original-commit: 2d58c5bf8679cffd4d0ad33782f47962b72cc3cd
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Skip the payment_asiapay test verifying the reference computation
with an invoice when account_payment is not installed.
Also add a dedicated helper, using the variable in payment already storing
whether the account_payment module is installed.
closesodoo/odoo#103449
X-original-commit: f1fd1c9e484025782079fc18c152269aa1723ed5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add tests to check Factur-X for a non FR/DE company (a US company here).
This US company should be able to import a Factur-X pdf and when printing
a PDF, a Factur-X should also be contained in the PDF.
closesodoo/odoo#103448
X-original-commit: 99bc6c7813df03c6d2c3ba22d37634c7debe2b36
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
This file is only necessary for the website.
closesodoo/odoo#102606
X-original-commit: 71584d7846dc76d8cbe0f19c283ccc7711e157a9
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the code that wrapped legacy fields and widgets
(coming from the legacy registries) into owl components and added
them to the wowl registries. This temporary compatibility layer,
which was incomplete and only allowed us to merge the new views
without converting all fields/widgets in once without breaking
everything, is no longer necessary as we now have converted all of
them into owl components.
X-original-commit: 555959c87e25faa71396f61479e8bb41b66ac164
Part-of: odoo/odoo#102606
Now that all views are converted to owl, that compatibility layer
is not needed anymore.
X-original-commit: 736572b5ae7692e0fe4b61f3331317ff1be16e8f
Part-of: odoo/odoo#102606
Suppose there is an invoice is issued in a foreign currency, but the statement line only has an amount in the company's currency and the `amount_foreign_currency` is empty. In this case, the exchange difference currency matches the invoice and `amount_foreign_currency` is 0,00, which is shown between the brackets in the pop-up.
Brackets should not be shown if the `amount_foreign_currency` is 0. The exchange difference currency should match company currency.
closesodoo/odoo#103433
X-original-commit: 8afccc41592d88125ab0f2678399086f83ab308d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Yannick Tivisse