This commit aims to fix an issue on forum posts, about comments being
placed directly next to each other without having a gap between them,
making it harder to visually recognize items at first glance.
To handle this issue, we simply add a `d-flex gap-x` utility classes
to ensure these elements receive some spacing between them.
closesodoo/odoo#155364
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The API of zeep changes according to the version of zeep.
We want to limit the number of used methods and attributes
of the zeep client by our developers.
Hence, we provide our own zeep Client limited to the
attribute and method we really need.
In addition, a timeout for GET/POST requests
should be applied by default when creating a new Client,
which is not the case by default.
We override that behavior to always provide a default timeout,
and an easier API for developers wanting to change
the default timeout.
Before it was needed to import `Transport` from `zeep`,
instanciate that `Transport`, with a timeout and optionally
a session, and then pass that transport instance to the creation
of the Client.
We provide a way to directly pass these timeout parameters
through the Client constructor.
In addition, we serialize the returned values of Zeep service operation
calls, to make sure we return simple types in methods of models
e.g. bools, integers, string, ...
Currently, the error arises when downloading e-Faktur without a 'Tax Number'.
Steps to reproduce:
- Install a 'l10n_id_efaktur' module (with demo data).
- Navigate to Invoicing -> Customers -> Invoices and open any invoice with
an empty 'Tax Number' field.
- Click on the action button to download e-Faktur.
Error: 'bool' object is not subscriptable while evaluating
'action = records.download_efaktur()'
When downloading e-Faktur, There's an issue at [1], Where
the system tries to access elements of 'l10n_id_tax_number', but
'Tax Number' is empty, So 'l10n_id_tax_number' is considered as a 'False'.
[1]: https://github.com/odoo/odoo/blob/9c4194ad3387c55d39ec7bbef1c6414893098c6e/addons/l10n_id_efaktur/models/account_move.py#L168-L170
This commit fixes the above issue by adding a condition to ensure that
the system only accesses an 'l10n_id_tax_number' if it is available.
sentry-5001664034
closesodoo/odoo#162749
X-original-commit: 24e65c2fe904e9a2a4e5004dc0e7ada220d1dacc
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42)
- reload the spreadsheet
- before the pivot is loaded (throttle the network in the dev tools): right click the cell
- click on "See records" menu item
=> boom
closesodoo/odoo#162759
Task: 3847477
X-original-commit: aeadd065e869a5cd6b971d6d458ba9d8e1edcc1c
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Monkey-patching C types is not straightforward.
It relies on changing the attributes or methods in memory
at the right address with the exact right size.
This requires the greatest caution.
A simple mistake can mess up the memory used by the Python interpreter,
and for instance lead to `SegmentationFault` exceptions
or unforeseen behaviors.
However, being able to patch C type is a very powerful tool.
With great power comes great responsibility.
`patch_c_type` is implemented with the greateast caution.
The Python C-API documentation has been thoroughly followed
and understood.
In addition, this patch has been battle tested in real
conditions.
In the end, this allows to patch unwanted behaviors
from types implemented in C.
Co-authored-by: Denis Ledoux <dle@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Mathieu Walravens <wama@odoo.com>
When we delay the creation of `repartition_line_ids`, the `account.tax`
gets created with default `base` and `tax` repartition lines,
which we must get rid of when we update the tax with the delayed
repartition lines.
related PR: #148370
task-3607459
closesodoo/odoo#157918
Signed-off-by: William André (wan) <wan@odoo.com>
Withholding taxes should not be used for tax closing.
This was impossible to implement before because of the bugs addressed
in the other commits of this PR.
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
`self.env.ref` -> kept of course
`deref` -> `deref_values` as it derefers for all passed values.
`defer` -> `delay`
`ref` -> kept, there's no choice, it's used in too many places
Also changed some variable names in the final loop for clarity
`data` -> `model_data`
`created_vals` -> `created_records`
`create_vals` -> `all_records_vals`
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
For `account.fiscal.position`'s submodels, REFs are not dereferenced,
they refer to virtual xmlids that only exist during import
(after account.tax.template was removed)
It should also look for: f"account.{company_id}_{template_xmlid}"
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
Added chart_template loading tests for:
- evaluation of submodel fields
- import from commands in the integer form, i.e. (0, 0, {values})
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
Files in the CSV templates that had submodels didn't get their values
evaluated.
Example:
`account.tax-xx.csv -> repartition_line_ids/use_in_tax_closing` was not
evaluated by `account/models/chart_template.py`'s `_parse_csv` function,
resulting in taxes having a "False" value still resulting as True.
This already affects `l10n_eg`.
In the process, code has been a little de-obfuscated.
*(This came out while testing the task linked below. Even if they're not
in the scope of the task itself, we noticed that withholding taxes have
`use_in_tax_closing` to `True` and putting them to False in the CSV had
no effect)*
related PR: #148370
task-3607459
Part-of: odoo/odoo#157918
This bug is generally hidden in normal localizations because the
`get_account_account` function reads `account.account-xx.csv` soon
enough to create all the needed accounts.
In `l10n_ng` there is no `account.account-ng.csv`, as it relies on the
generic_coa. The chart_template's `get_account_tax` function reads
`account.tax-ng.csv` before `get_ng_account_account` is called.
The `defer` function should check the account_tax fields and postpone
them until the creates are done, but it only checks the "first level"
and doesn't check all the way down to
`account_tax.repartition_line_ids.account_id`
By making `defer` recursive we are able to properly postpone
the creation of taxes after the accounts are made.
related PR: odoo/odoo#148370
task-3607459
Part-of: odoo/odoo#157918
When making a registry of all available chart templates from exisiting modules,
the templating function is executed 5 times per Chart template instead of once.
It may not be all this relevant, but the fix is very basic.
related PR: odoo/odoo#148370
task-3607459
Part-of: odoo/odoo#157918
The aim of this commit is to allow user to install `account_peppol`
without facing a traceback.
Context:
The commit cffd0e9dd91376dd7fe4613f4fd94e659daaeef0 introduced a check
based on a field introduced in the view by another module it depends on.
The problem is that ticking the peppol checkbox install the `account_peppol`
module but doesn't trigger an update of the `account_edi_ubl_cii`
module.
Before the commit:
Impossible to installing `account_peppol`.
After the commit:
Installing `account_peppol` will update the view
`account_edi_ubl_cii.account_move_send_form` if the field added by
commit cffd0e9dd91376dd7fe4613f4fd94e659daaeef0 can't be found.
opw-3874304
closesodoo/odoo#162677
X-original-commit: 465491d017ecf1c6efb26d3252471f17f4e9d856
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- Install Contacts, Sales, Accounting and l10n_din5008
- Configure DIN5008 as document layout in the settings
- Install German language
- Create a contact with German as language (e.g. German Contact)
- Create a SO with German Contact as customer
- Create an invoice from the SO
- Add a Customer Reference ("Other Info" tab) on the invoice
- Confirm and print the invoice
Issue:
On the printed invoice, both "Source" (i.e. the SO) and "Reference"
(i.e. Customer Reference) labels are translated with the same German
term: "Referenz".
Solution:
Translation team suggested to use "Verweis" to translate "Source"
in German.
opw-3821069
closesodoo/odoo#162622
X-original-commit: 970e2d1c35b843f83f103124eaf0ecce97bda363
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
When a portal user is created (e.g. through the `auth_signup` module),
an unnecessary write is done on the `write_date` of the default digest.
This `write` is unnecessary since a portal user is never subscribed to
the default digest.
In case of a high signup frequency, it can cause concurrent transaction
errors.
We avoid writing if no internal user is being created.
closesodoo/odoo#162563
X-original-commit: bbc427e837b08187f351febfde4339262e660944
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
General scaling of the footer font is too big. Normal Sized company names cannot
be displayed. In Fact, the Iban numbers etc. are cut off at the bottom.
This commit will reduce the size of the footer.
task-3192117
closesodoo/odoo#162557
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, we always had the address of the partner even if the address
were the same.
Now, depending on the address in the customer field or delivery address, we can
decide to display the invoicing address or shipping address or both.
Task: 3817563
Part-of: odoo/odoo#162557
Issue
-----
The activities summaries displayed by the misc. operations view in the accounting
app take up the entire screen and span across the card if the activity summary
is too long.
Steps
-----
- Open the Accounting App.
- Create a new entry from 'Miscellaneous Operations'.
- Add an activity with a long summary.
- Go back the dashboard. The summary will try to span the entire width.
Cause
-----
The activities are displayed with a field tag in the kanban view. The field tag
refers to the activities js component as a widget. Due the use of a widget attribute,
the template generates a div with class: "o_field_widget". This class is defined
to have a css "display" attribe with a default value of "inline-block". Using "inline-block"
causes the activity row to take up the whole width.
opw-3839992
closesodoo/odoo#162543
X-original-commit: dec1f870de9f7004a2935f61c79b83dada7a57a5
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
This commit improves the performance of the reference check for large
categories of Units of Measure (UoM).
After this commit, the number of UoMs in the category is counted using
the read_group method instead, resulting in faster performance.
Benchmark:
| Nbr of UoM | Before | After |
| ---------: | -----: | ----: |
| 0 | 0ms | 0ms |
| 1 | 1ms | 1ms |
| 30 | 6ms | 3ms |
| 200 | 7ms | 2ms |
| 18000 | 900ms | 15ms |
opw-3775689
closesodoo/odoo#162540
X-original-commit: 9f47341de352d08a8e325d14f25af8221bb392cb
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
Before this PR, trying to get an available operator could result in an
error.
When a live chat is created, an operator is selected based on various
criteria such as language, country, number of ongoing chats and
availability for calls. This selection process involves the
`_get_less_active_operator` method, which receives the status of all
operators and a list of operators to choose from.
Prior to this fix, an operator not included in the list of operators
to choose from could still be selected, resulting in errors when
trying to locate them in the operator list.
This PR resolves the issue by ensuring that operators are only
selected from the provided list.
opw-3874872
closesodoo/odoo#162357
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The blogs filters in mobile is breaking the layout. This commit applies
a dropdown or an offcanvas instead which is displayed next to searchbar.
In this 17.0 fix, the dropdown becomes an
offcanvas if we have a sufficient amount of blogs which allows better
navigation on mobile and makes it consistent with other website modules.
Additionally it adapts the spacing to make it even between the
navigation component.
The `t-set="_classes"` is not removed in case of potential xpath in
production. Same goes for the `container` class on the div at line 9,
being overridden by it's t-attf-class counterpart.
task-3315921
closesodoo/odoo#157757
X-original-commit: 19f34c5e0973903b47cf6a5c65cc8888986abaa8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behavior:
When entering a lot name that doesn't exist in the PoS, the lot is being
created. But the lot is not being assigned to the stock move line.
Steps to reproduce:
- Create a product with tracking by lot
- Open PoS and make an order for this product
- Enter a lot name that doesn't exist
- Validate the order
- Close the session
- Go to the order picking in the inventory app
- The lot is not assigned to the stock move line
opw-3710125
closesodoo/odoo#160533
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
1. Go to IoT > Devices
2. Select a device and add the report "Lot/Serial Number (ZPL)"
3. Create a product tracked by lots
4. Purchase 5 units of this product
5. Validate the reception (with a lot)
6. Print labels > Lot/SN Labels
- Quantity to print: One per unit
- Format: ZPL Labels
Before this commit:
When printing labels for multiple lots of the same product, the wizard
was incorrectly generating the docids as a `list[list[int]]`. It works
correctly as the ids are joined thanks to JavaScript magic. However,
when sending the report to an IoT device, the ids are sent as-is in
the context, which raises and error when calling `browse()`.
After this commit:
The docids are now generated as a flat list of integers, which is
correct and works as expected.
opw-3850631
closesodoo/odoo#162063
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
In this commit:
===============
printer icon will visible based on printer configuration
task - 3869678
closesodoo/odoo#162056
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
To reproduce:
* Add a bank account to Employee, and a bank account to your company.
* Set the company on the employee's contact to yours.
* Create an expense to be reimbursed to the employee, submit it and try
to "Register Payment".
Current behaviour: the recipient bank account in the wizard is set to
the company's.
Expected behaviour: the bank account in the wizard should be set to the
employee's bank account.
This commit solves this.
task-3837305
closesodoo/odoo#160749
Signed-off-by: William André (wan) <wan@odoo.com>
After the portal redesign, messages for no quotations or sale orders
were moved before the portal_table template, which is called when there
are entries of quotations or sale orders. However, the previous version
of the message for sale orders was left after the template call.
This commit removes the previous version of the message to avoid having
duplicated messages.
closesodoo/odoo#162546
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Fix errors in some of the spanish invoice_labels for withholding taxes.
Thanks to @AlmustafaNET odoo/odoo/#147867
closesodoo/odoo#162447
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behavior:
When generating a sale report for multiple pos sessions, the payment
name is not clear which session it belongs to.
Steps to reproduce:
- Open PoS and make some sales
- Close the session, and do the first step again.
- Go in reporting and generate the report for a period that includes
the two sessions.
- In the payments table you will see the payment name, but you won't
know which session it belongs to.
opw-3684937
closesodoo/odoo#162440
X-original-commit: 77c95c2588c3af02e6f96cd03c289671c775c0e8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Prior to this commit, the presence of an invalid order in the browser
cache could prevent the PoS from loading. This issue typically arises
after a database upgrade, where changes in fields can render unpaid
orders in the cache unloadable. This commit resolves this issue by
discarding any problematic unpaid orders that can no longer be loaded.
opw-3874858
closesodoo/odoo#162408
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Current behavior:
If you create a user that only have access to a branch of a company.
If this user try to access the QR Menu of any PoS he will get an access
error.
Steps to reproduce:
- Create a branch B for company A
- Change access of user U to only have access to branch B
- Login with user U, and try to open any PoS QR Menu
- You get an access error
opw-3745256
closesodoo/odoo#162222
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
While updating the checkout page an element was changed from div to t
To handle the intermediate value used by users who installed this version
a new selector was added to the xpath to account for both cases
Previous commit that was trying to fix the same issue 12e5296c1dclosesodoo/odoo#162064
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some parts of the translation were missing and Romanian isn't available
as a language in Transifex for this version. Therefore we add it in now.
English grammar mistakes of original string are left untouched.
closesodoo/odoo#162469
X-original-commit: f19e872698d17b93da3c2e1a3eafb20a4d098660
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound".
Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time."
Task id: 3638740
closesodoo/odoo#162464
X-original-commit: a18cb2ebb133c2e4b72ddd5d8cda23d2b71006dd
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Seif Gneedy (segn) <segn@odoo.com>
Steps to reproduce
==================
- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close
=> Cannot read properties of undefined (reading 'resId')
Cause of the issue
==================
When calling openRecord, if the record is dirty, it is saved before
proceeding.
After saving, we call super.openRecord with the old record.
Since that record is no longer linked to the root record (the
stock.picking), when we try to save it, it won't match an existing id.
Solution
========
If the record is new, we don't save as there would be no way of knowing
which of the returned line would come from this one.
If we are opening an existing record, we find the new datapoint by
matching it's ID.
opw-3777615
closesodoo/odoo#162425
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the issue:
1. Create a Storable Product and give it a UOM
2. Create an On Hand stock in a certain location
3. Go to Barcode and create a new Internal Transfer
4. Add the Product and with any quantity and click on Confirm (not Validate)
5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm
6. Validate the Transfer
7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button
8. The reserved quantity is not null
Explanation:
When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes:
- In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards.
https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61
When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`.
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422
(e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)
- There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`.
(e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)
Suggested fix:
There is a first check to make sure one of the values has changed, then each one will be assigned through a condition:
- The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called.
- The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute.
opw-3798046
closesodoo/odoo#162380
X-original-commit: 2b8e073d082620ca3ac2342fa12c7f93a07335d1
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
How to reproduce:
1. Go to any course
2. Click on the button 'Add attendees'
3. Type the recipients name
"Create and edit ..." should be displayed but is not.
To reenable this feature, we remove the option no_create_edit on partner_ids
of the slide_channel_invite_view_form form to enable the creation of partner
when adding attendee to a course.
As the support for the force_email context has been discontinued, we don't
reenable the quick_create as it can create partner without email (if the user
enter a non-valid email). But we reenable the "create edit" option with a view
that force the user to enter an email: base.view_partner_simple_form (like
done on some views in odoo/odoo#149806).
Task-3868824
closesodoo/odoo#162190
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When changing `groupby` we want to also update `user_groupby` to avoid
raising `_validate_groupby_no_child` or `_validate_formula`.
It can always be set independently after.
Detected while upgrading `account_financial_report_it_sp` because
`<field name="groupby" eval="False"/>` was set in the data but
`user_groupby` was never updated. (but the constraint was triggered
because of the write)
Note that the constraint was not fired when needed either.
closesodoo/odoo#160301
Related: odoo/enterprise#60420
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side
This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)
when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.
closesodoo/odoo#157664
Task: 3681668
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently, an error occurs when the user tries to add an order with toppings.
This is because before 17.0, [1] got values like `[6, False (1, 2)]`, where
we found the `values['topping_ids_1'][0][2] (ids (1,2))`. But after 17.0,
[1] got values like `[[4, 1], [4, 2]]`. As a result, it cannot be found in
the `[0][2]` index at [1].
This commit fixes the above issue by using 'convert_to_cach()', which returns
the ids from [[4, 1], [4, 2]]. Apart from that, this commit also improves the
code by adding a loop to get topping IDs for each topping.
[1]-https://github.com/odoo/odoo/blob/039407cf2954ce6298aa8af7aff251a1cefdc39b/addons/lunch/models/lunch_order.py#L99
sentry-4627940064
closesodoo/odoo#142701
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
closesodoo/odoo#162499
X-original-commit: 1fcc11a2ca8e18d10eaac51ce20773596db183e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund.
This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.
Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0
Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.
The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.
Since this is a rare event, we consider this difference to be acceptable.
Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.
opw-3701574
closesodoo/odoo#162416
X-original-commit: f8e78cdee3dac64a3ac3d8da529aea398cdb7393
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Co-authored-by: Robin Engels <roen@odoo.com>
At the moment, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised.
However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raise
`No EMV QR Code is available for the country of the account False.`
This commit adds a check to ensure the bank account is set and raise a better error message.
Task# 3868467
closesodoo/odoo#162500
X-original-commit: e6ca281b691e75dd9c12fb110f80f444c21729de
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo.
The test was failing because of the following:
when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`.
However the list of `event.attendee_ids` is ordered by create_date.
And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]`
So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test.
To fix this issue:
This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee.
fixes runbot-61527
closesodoo/odoo#162279
X-original-commit: 6db2614283abfc035343f021b9cfc52609aa9d44
Signed-off-by: Ahmad Almaghraby (alah) <alah@odoo.com>
Actually if a server is not configured we can click on it and
we are redirect to not reachable page
With this commit it is not possible to click if server is not configured
closesodoo/odoo#162372
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
When the iot run without server we display an certificate error.
This error is useless because we can't get a certificate without server.
Some customer a worry about this error
With this commit we hide this comment if we not connected to a Odoo server
closesodoo/odoo#162371
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Chrysanthe (chgo)
