`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form`
All these extension views have the same priority and in this case the later is trying to access the div before it is even created.
We fix this issue by changing the priority of the view that creates the div from 16 to 15.
closesodoo/odoo#161902
X-original-commit: 67e7289296ea12e69cb07864a2974cd5d4e46cf2
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adds a new module to allow delaying the sending of sales
order confirmation emails, thus removing a performance bottleneck in the
order confirmation flow.
This is particularly useful for "flash" sales in which a large number of
event tickets are sold in a very short time span. When the emails are
scheduled to be sent right away, the email rendering that is part of the
payment post-processing keeps the worker busy. When the system parameter
`sale.async_emails` is set to `True`, the email rendering is delegated
to a cron, allowing the payment post-processing to execute much faster.
task-3782827
closesodoo/odoo#157612
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Login as "Mitchel Admin"
- Install hr_skills_survey
- Delete all employee except "Mitchel Admin"
- Open "My profile"
- Open "Resume"
- Add a skill
Actual result:
- Error due to missing employee
- default_employee_id is using the current record id so a user id
- default_employee_id is not the correct ID
- Can lead to record not existing error or access error
Expected result:
- No error
- default_employee_id is the correct employee of the user
- Default employee in dialog is "Mitchel Admin"
opw-3852542
closesodoo/odoo#161636
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Create a vendor bill with landed costs
- Add section and note lines
- Try posting the bill (ERROR)
Bug:
display lines should be skipped
opw-3715660
closesodoo/odoo#161791
X-original-commit: 3174c4a793f24782d835a15d96376e45b5f333e4
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
Create and print an SO for a customer based in Luxembourg
Expected behavior:
According to Bpost and to the Post of Luxembourg, the zip code should be
displayed before the city name in the address format in Luxembourg.
Current behavior:
The zip code is displayed after the city name.
opw-3791142
closesodoo/odoo#161738
X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
In IT localization open tax "0% S (Services)"
Issue: invoice repartition line tax tag is "+02", it should be "+03"
opw-3860109
closesodoo/odoo#161696
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
There is 2 issues with it:
- People that want to use multiple picking type or multiple store after
manufacturing locations. It's not possible since the equals is strict
on the warehouse store after manufacturing picking type.
- The procurement group always use the default manufacture picking type
and ignore the picking type on the manufacture rule that will be use.
This commit checks if the location is a child of the post production in
order to create the procurement group. It would be an issue for people
having multiple step in post prod. But it could be fix by using a subset
of the warehouse post production location.
Check if we have a manufacture rule with the same warehouse in the
current route. It's not perfect but it could give a more accurate result than
today.
closesodoo/odoo#161690
X-original-commit: f82a0f2ea8f3c57bae915520f9e4a25b54b81ce4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue
-----
Reconciliation models are not searchable by specific fields (e.g. name).
Steps
-----
- Open Accounting -> Configuration -> Reconciliation Models.
- Try typing something into search.
- No field are suggested to search on.
Cause
-----
No search fields are defined for `account.reconcile.model`, only filters.
opw-3847744
closesodoo/odoo#161648
X-original-commit: 973ad96c7cf4b37fbdeea463bbf676cfee920975
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Change the recruitment access rights of Marc Demo to "Interviewer".
- Go to Recruitment > Applications > All Applications.
- Create a new application and add Marc Demo as follower of the chatter.
- Write and send a message on the chatter.
> Marc Demo will not be notified
Expected behavior:
As discussed the PO of the recruitment module (gmf), since users with
"interviewer" access rights have access to the chatter and since the
sensible informations are now shared via the salary offer model instead
of relying on the chatter of the application model, the followers of the
chatter with "interviewer" access rights should be notified if pinged on
a log note or if a general message is sent.
Cause of the issue:
Since sensitive informations used to pass through the chatter, users
with "interviewer" access rights did not have access to it, and were
removed on purpose from the recipients of the notifications:
https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379
to avoid any leak of sensible information.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161198
X-original-commit: 6e8795cf5a7d51c4682941a253fb158e8e7e874e
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
An update made to the tremol device has changed the expected content of
the price field. It now expects up to 15 characters in this position,
with a maximum of 5 decimal places.
At present we can send prices with a decimal position greater than 5,
doing so will result in an error from the fiscal device.
This commit adapts the content that gets serialised in order to ensure
that the decimal provided is no longer than 5 decimal places.
closesodoo/odoo#161804
Task-id: none
X-original-commit: 3373ac3a7945d25fee70d114816ce23a16d6e0ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to Reproduce :
- install indian Accounting module
- click on invoice
- go to vendor bills
- create new
Issue:
- while creating new and confirming, it will throw a warning message, as this
warning required only for eInvoice only (while confirming the invoice) not for
vendor Bills.
Cause:
- while generating warning message there is no specific condition like that it
is not for vendors
Solution:
- if we gave condition that this warning message is only for out_invoice then
the issue will be solved.
task-3657558
closesodoo/odoo#161333
X-original-commit: 6480dccfea696e759d0ed4225f4edc033adbfc0e
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit will make a `willDrag` information available to the
draggable_hook_builder context.
This is needed to fix a resize issue in the gantt view.
See correlated enterprise pull request.
closesodoo/odoo#161670
X-original-commit: 53254591c4a6a31483f409aa2fa072ac2ed0b3db
Related: odoo/enterprise#60623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
- Transfer move line with amount_currency $0, balance 1000đ
- Wizard transfer not generate counterpart lines
closesodoo/odoo#161727
X-original-commit: e5b84edd7a5aefc3f08db23e6ede8a380c2cb6f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The patch function was changed at commit [1]. This introduced a call to
`Object.hasOwn` which is the preferred way to check if an Object has a
property as its own. However, after multiple user reports, it seems like
a significant amount of user and website visitors still use browsers
that do not have Object.hasOwn implemented.
This commit adds a polyfill to add Obejct.hasOwn in case it is not
found.
[1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe
Fixes https://github.com/odoo/odoo/issues/142022
opw-3824593
Part-of: odoo/odoo#160758
It's not possible to push in intercompany location because the warehouse
is set base on the initial move. However in intercompany we don't
have a warehouse in the most cases.
Also there is an issue with the cache holding the route on the product
for the current company. So we invalidate it to retrieve all the routes
among the different companies
closesodoo/odoo#161717
X-original-commit: f16e0a2c954f1dce14880d62b6c07518f7317d1b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Company A Stock -> Interco -> Push to Company B stock
- Create a SO from company A with company B as customer
- Create a pull from WH/A to interco
- Create a push interco to WH/B
- Confirm the SO
Current behavior:
Wrong company on stock.move from interco to WH/B due to rule with
company A
Expected behavior:
Pushed to stock B
It happens because the rule_id is not set during the copy of push_apply.
So it just keep the same rule than the move triggering the push (WH/A ->
interco).
X-original-commit: dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9
Part-of: odoo/odoo#161717
The linked PR: https://github.com/odoo/odoo/pull/155157/files
Added a default props 'productType' for ProductCatalogOrderLines, the value of this prop wasn't loaded by the backend correctly
resulting in a traceback when in debug mode and trying to open the catalog from sale/fsm
and another traceback when trying to open the catalog from the purchase form
This PR loads the type of the product into the dictionnary corretly
closesodoo/odoo#161541
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Create a Customer Invoice CI
- Register a full payment P
- Create a Bank Transaction BT
- Reconcile BT with P
- Go to the payment's move and click on "Reverse Entry" button
-> First issue: Two buttons ("Reverse" and "Reverse and create invoice")
It should be only one ("Reverse")
- Click on "Reverse" button
-> The invoice is still marked as "paid", it should be "not paid"
The reason is that `is_cancel_needed` variable is not well computed
in `reverse_moves()` as since 4d3ac4cbd8,
there is no `refund_method` on the reversal wizard, which was used
instead of `is_modify` parameter, which is not enough in our case.
opw-3772117
closesodoo/odoo#161534
X-original-commit: 5f3c1957b391e3395dbebac4ccb6592af9e4a7dd
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Steps to reproduce:
- Drop an Text - Image block
- Click on the Image
- Click on the link button next to replace
- Try typing a URL
=> Typing a URL is hard because the widget keeps re-rendering
Reason: Since [1], the jQueryUI urlcomplete widget was changed into an
OWL widget. This added a call to `urlChosen` on input, which leads to
the SnippetsMenu re-rendering the options.
This commit fixes that by remove the call to `urlChosen`. Nothing is
lost since the input is already handling its own changes. Instead,
urlChosen is only called when selecting an element from the dropdown.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#161045
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Co-authored-by: =?UTF-8?q?Nguy=E1=BB=85n=20=C4=90=E1=BA=A1i=20D=C6=B0=C6=A1ng?= <daiduongnguyen2709@gmail.com>
In `SET_FILTER_MATCHING_CONDITION` we would call `SEE_RECORDS_PIVOT_VISIBLE`
twice but since the function returns a boolean value, the second call
was useless as we already knew the outcome. This revision alleviates a
bit the cost of computing the cells' clickable actions.
On A sheet with 480 visible cells, each of them matching the full
condition, the time spent in `getClickableCells` goes from 19ms to 14
ms on Google Chrome and from 42ms to 29 ms on Firefox.
closesodoo/odoo#161656
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Issue: When a course is set to 'On Payment' and
linked to our 'Course Access' product, users
encounter an issue where they cannot view the
final screen of the payment process when selecting
payment methods like 'wire transfer'. This occurs
because the payment status remains 'pending', and
the user has not yet been granted access to the
course, meaning no invitation link is available.
Steps to Reproduce:
1. Install website_sale_slides.
2. Create or modify a course with the 'On Payment'
status.
3. Link it to a 'Course Access' product.
4. Navigate to the website and attempt to purchase
the course.
5. Proceed through all the steps of the payment
process.
Solution: The template needs to accommodate
scenarios where certain payment methods do not
immediately provide an invitation link.
Even without the invitation link, it should still
display the last payment screen, awaiting payment
confirmation to grant access.
opw-3683024
closesodoo/odoo#161618
X-original-commit: eee6222763b4d88f75994b498d15cd4358899fc1
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Create company A with company currency USD, company B with company
currency VND.
Set company B-VND in payment terms
closesodoo/odoo#161044
Expect: currency payment terms is VND
Signed-off-by: William André (wan) <wan@odoo.com>
Issue: In Link Tracker for our website, when generating the link, if we
try to copy the generated url with the copy value, instead of copying
the url we are getting undefined.
Steps to reproduce:
1. Install website_links.
2. Go to the website and go to Site > Link tracker.
3. Generate a new link and try to copy.
Solution: Due to the recent changes that came from the changes made in
9638423 where we replace the ClipboardJS with Web API and hombrew
polyfill, there are still some button that is not adapted yet, and in
this case what happens is that we have a difference dataset format for
the clipboard content, being 'clipboardText' instead of 'clipboard-text'
opw-3806495
closesodoo/odoo#159674
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When updating the categories, if by any chance there is a loop in the
category hierarchy, the current code was falling into an infinite loop.
With this commit, the graph loop is broken by clearing a parent_id, and
if the resulting module category path is wrong, a clean new one will be
recreated anyway.
This allows unblocking uncomfortable situations where people cannot
update the modules list any more. In 15.0, [a check][1] has been
introduced to prevent the existence of recursive categories, but as it
is a python check it doesn't prevent corrupted data to remain corrupted.
OPW-3704007
Related to odoo/upgrade#5574
[1]: odoo/odoo@6932714200closesodoo/odoo#161583
X-original-commit: f2765d2cab5671a010404c36842bf1b4c4d6350b
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The goal is to modify the acconuts that take please in those entries.
A typical example is a company that wants to recognize cost of goods
sold for the input and output at the same time, instead of waiting
for the customer invoice.
closesodoo/odoo#161505
X-original-commit: f477433a9092deb21236b90114759316b13bc1bc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After `_check_combo_inclusion` was added, it broke product creation for
users without sales rights (e.g. stock managers). This commit fixes
the issue by using `sudo().search`.
closesodoo/odoo#161313
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
[This first commit] made it possible to have an error when there was no
comparator for a field with conditional visibility. [This second commit]
prevented an error from occurring in this case. The purpose of this
commit is to prevent the user from getting a conditional visibility
configuration for a form field where there is no comparator.
Steps to reproduce the problem:
- Go to /contactus.
- Edit page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Click on "Visible Only If" again.
=> The comparator is not defined.
Another way to have the issue was:
- Drop a form on a page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Set visible only if Your Name is equal to "test" as condition.
- Click on Your Name field.
- Change the field type to Radio Buttons.
=> The comparator is not defined.
This commit fixes those two cases.
Technical information:
When we change the field's visibility to conditional (`setVisibility`),
we add a default visibility dependency (`_setVisibilityDependency`). At
this point, the comparator is removed and added in `_renderCustomXML`.
`_renderCustomXML` was only called if the visibility dependency had
changed.
[This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Prior to this commit, splitting an order would create a new order,
causing it to appear again on the preparation display. This could
lead to the kitchen preparing the same order twice. The sequence of
events was as follows:
1. The order is placed.
2. The kitchen receives and prepares the order.
3. The waiter delivers the order to the table.
4. The client receives the bill and requests a split.
At the point of splitting, a new order is created. This duplicate order
should not be sent to the kitchen as it represents a meal that has
already been prepared and consumed. This commit resolves this issue by
preventing display of duplicate orders to the kitchen during order
splitting.
Enterprise PR: https://github.com/odoo/enterprise/pull/60537
opw-3809693
closesodoo/odoo#161498
Related: odoo/enterprise#60537
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue:
======
traceback when clicking on gradient colorpicker in mass_mailing
Steps to reproduce the issue:
=============================
- Got to email marketing
- Add some text
- Select the text and go to graadient and activate custom
- click any color in the colorpalette -> traceback
Origin of the issue:
====================
Some colorpickers are created inside the snippets sidebar and then gets
removed by `_updateRightPanelContent` in `SnippetsMenu` so the owl
components corrosponding to them will have `this.el = null` which will
cause a problem when updating the props since we will use it in the
update.
task-3834112
closesodoo/odoo#161275
X-original-commit: 9ccd820813f6c0bd7608e80570a6999577aff513
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Context
In a previous fix https://github.com/odoo/odoo/pull/83276
, the `_notify_get_reply_to_formatted_email` method was introduced
to prevent edge-cases where the cypthon `email` library might incorrectly
fold the “Reply-To” email header.
We identified an other corner case where DKIM signature verification
might fail on the recipient’s end depending on the tech stack used to
verify the DKIM signature vs the one used to DKIM sign it on the
sending end.
This might be related to how RFC5322 and RFC6376 interact with each other :
In RFC5322 defines folding white spaces as follows :
```
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
with obsolete FWS = 1*WSP *(CRLF 1*WSP)
```
While RFC6376 uses :
`FWS = [*WSP CRLF] 1*WSP
`
Based on this, it seems that for proper header content folding,
the specifications expects at least one WSP (space or tab) before a CRLF.
Currently when using the `email` cpython library to handle email
objects, we observed that when the header value for the “Reply-To” is
longer than 68 characters, it will return a folded string representation
adding a linebreak after the colon.
Example:
`Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n`
Notice that the there is no WSP between the colon character an `\r\n`.
It seems that in this corner case, certain DKIM verification tech stacks
(from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to”
header as empty, while others correct for it (Gmail). This in returns leads
to the DKIM signature verification failing.
As it is impossible to test every possible combination of DKIM tech
stacks in the email ecosystem and that until the `email` cypython library
handles this corner case correctly, this fix tries to preformat the
“Reply-To” more defensively.
We also print a warning log if the `record_email` alone is longer than
68 characters (as it will not be folded), inviting the user to shorten
it to prevent DKIM verification issues.
Unit test fixing:
- shortened alias name to prevent the 68 character
limit from being triggered during the test_notification_reply_to_batch
performance test (as we are not testing the 68 char here)
- changed language in test_mail_message_values_fromto_long_name
to reflect the new 68 character limit and mutted
logger, as it now print a warning message
Considerations for the future
This PR only prevents the “Reply-To” from being malformed. In theory,
the miss-folding could happen to any email header constructed using the
`email` cpython library. In practice, the probability of the “To” and
“From” being affected is low, as they usually don’t exceed a total of
78 characters as per RFC.
Nevertheless if the future shows that this might be a bigger issue, one
should think about:
* On Odoo side: add a more robust header value formatting applied to all
affected headers before the email gets sent out
* On Python’s side: work with the `email` library maintainer to find a
longterm solution
opw-3826296
fixed test and conflicts in 17.0 FW
closesodoo/odoo#161014
X-original-commit: 894f981d04195861e757c052b7d10155cb5975b4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
**Current behavior:**
Entering kiosk mode in the webclient in a multi-company env
will display the logo of the default company.
**Expected behavior:**
The logo on the kiosk screen will belong to the currently
selected company.
**Steps to reproduce:**
1. Make a second company, give the default company and the new
one distinct logos
2. Select the second company from the company selector menu
3. Enter kiosk mode in the Attendance app, observe the logo
is that of the inactive company
**Cause of the issue:**
After arriving at the URL route for the kiosk page from the
_action_open_kiosk_mode() method, the context has been rebuilt
to a somewhat default state which no longer informs the current
company id. `self.env.company` references the default company of
the user.
**Fix:**
Add an id slug in the URL route which identifies which company's
kiosk we should be seeing.
opw-3802916
closesodoo/odoo#159702
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
STEP TO REPRODUCE:
=================
* Unistall hr_org_chart application
* Click on hr application
You will have an error due to the missing hiercharchy view.
closesodoo/odoo#158523
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Steps to reproduce:
-------------------
- create a storable product and set a quantity on hand
- create a delivery for this product and set to draft
- add a demand for this product on the delivery
- click on "Mark as Todo"
- go to the product form
- click on the Forecasted smart button
- click on "Unreserve" button (to process business logic ans reload report)
Issue:
------
The report is reloaded with all products.
Cause:
------
When we setup/start the `StockForecasted` component, if we can't find an active model
in the action's context, we try to find it in the action's props
(via res_model or on the original action if necessary).
If the original action is used, the active model must be
in the context of the original action.
Unfortunately, this is not the case.
Without `resModel` the domain determined in the `graphDomain` method
will not filter on the product (which corresponds to the `active_id`).
Solution:
---------
If no resModel is found via the context, add it to the context
when it is determined.
Add the action id to handle the case of reloading the page
directly via the browser's refresh button.
opw-3793065
closesodoo/odoo#161569
X-original-commit: 288e1e0f8d7bc343b90a22692bdf44ccb9b21725
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
When generating the PDF, the translatable fields (the note of the
payment terms, the name of the products, etc) will use the language set
on the partner_id of the invoice.
The xml generated should do the same.
opw-3842885
closesodoo/odoo#161543
X-original-commit: a1afcc896fa61db561eb7be6624083ac4ee11a4b
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, you cannot send a credit note to Facturae if it was created
from a paid invoice
Steps to reproduce
------------------
* install `l10n_es_edi_facturae`
* create an invoice and register its payment
* created and confirm a credit note from your invoice
* attempt to send that invoice to Facturae
You should be met with the following traceback:
`psycopg2.ProgrammingError: can't adapt type 'account.move'`
Cause
-----
In the function `_l10n_es_edi_facturae_get_corrective_data()`, there is
an attempt to browse the output of a call to
`_l10n_es_edi_facturae_get_refunded_invoices()`. This function is
expected to return a mapping of id to id. However, in certain scenarios,
it may return a mapping of id to recordset instead.
opw-3811170
closesodoo/odoo#161549
X-original-commit: a0172cb5f8efc35c4138aadc56beebca328457f4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This reverts commit 436c1c6.
The commit was fixing an issue where the product configurator dialog
would not be shown for custom attribute, no variant, and dynamic
attribute using the quick buy add button on the '/shop' page.
The commit introduces an undesirable behavior: the product configurator
would always be open if customers choose none of the multi-checkbox
options.
closesodoo/odoo#161144
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when a DM chat had a custom name, the
search was not taking it into account.
Steps to reproduce:
- Log in as Mitchell Admin
- Open a DM chat with Marc Demo in Discuss app
- Rename conversation to "Test"
- Open more than 20 chat/channels (can create 20 channels)
- type "Test" in the quick search of discuss app sidebar
=> The DM chat with Marc Demo is not visible in filtered sidebar.
This happens because the quick search was relying on `thread.name`,
which actually only matches exactly the UI when this is the name
of a channel or when a group chat is explictly named.
The actual thread field used that matches textual name of thread
is `thread.displayName`, and this field is synced with custom DM
chat if any.
closesodoo/odoo#161540
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This lead to some error in the Mexican EDI.
Suppose 2 lines of 17983.80 with 16% tax.
17983.80 * 0.16 = 2877.408
2877.408 * 2 = 5754.816 ~= 5754.82
If we distribute, 2877.408 becomes 2877.41.
However, the government allow the value to be between 2877.408 & 2877.409.
closesodoo/odoo#161487
X-original-commit: 84f7ddc5a029a25524d58867ae4a5497de907d5a
Related: odoo/enterprise#60532
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Clean up field value when is not used, this because is only
show when some conditions applies, if not we need to clear it to
avoid having wrong data on taxes.
We want to behave as an onchange, to se change the field to a compute
one, in this case stored and also can be edit by the user
closesodoo/odoo#156808
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to Reproduce:
- Install Project App
- Go inside any project and set the state of task as done
- Click on project burger menu and click on settings
Issue:
- The count on the stat button refers to count of all tasks
Causes:
- Reference of wrong field in the XML i.e ., 'task_count' instead of
'open_task_count'.
Solution:
- Changing the field to reference it to open tasks count i.e., 'open_task_count'
task-3741260
closesodoo/odoo#153984
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The payment with MobilePay payment method failed due to the wrong code.
opw-3859956
closesodoo/odoo#161481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fixes a few things:
- A couple placeholders existed for non-required fields, which means in
certain cases they would be printed in real reports (i.e. not just
shown in studio)
- hide the UoM from the deliveryslip when the setting isn't active
(this is broken in earlier versions too, but fix can be backported if
someone finally complains about it since it's been there for awhile)
- Updates a placeholder that was confusing (a location instead of a
package name)
Note only `stock` reports were checked for this fix, there are probably
still other problematic reports.
See PR: https://github.com/odoo/odoo/pull/129310 for reference of when
placeholders were added in
closesodoo/odoo#161420
X-original-commit: 90104d0133ab54ac12e466c6187601029e50b4d9
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
agrabsi