Daily updates from Odoo
Navigate
Branch
Friday, March 22, 2024
159 changes
62 changes
Enhancements to existing features
Sales administrators now receive permission to administer canned responses used by sales teams. This helps keep standard replies consistent and easier to maintain without involving higher-level technical administrators.
Original PR description
part of task-3334899
The default view for canned responses no longer includes the shared canned response filter, making the list simpler and less cluttered for users. The update also corrects wording issues in related labels, improving clarity in the Mail app.
Original PR description
This PR removes the "Shared canned response" filter from the default filter and corrects typos on strings. task-3814167
The web test framework now checks mock network handlers in sequence, making tests easier to control and more reliable. It also fails clearly when an unexpected network request is not mocked, helping teams catch test setup issues earlier.
Original PR description
Previously, when trying to mock a network call to a route in hoot tests, we would call the most specific handler that was registered for that route and nothing else. This makes it difficult to have a single route handler that steps all network calls during the test, because the mock server would for example only invoke the mockCallKw handler for jsonRPC method calls and not the stepping handler, as the stepping handler is less specific. This commit changes the approach to what was used in the QUnit suite: the mock server calls all registered handlers from most recently registered to least recently registered until a handler returns a non undefined value. If a handler wants to return an empty response and explicitly stop further handlers from being invoked (there are currently no such cases in the code base) it can opt for returning a MockResponse.
This update improves and fixes Odoo's internal HOOT testing tools, making automated tests faster, more reliable, and easier to maintain. The changes are limited to the unit test ecosystem, reducing risk to day-to-day product behavior while helping developers catch issues more consistently.
Original PR description
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203…
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Enterprise: https://github.com/odoo/enterprise/pull/59019 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Posting messages in Discuss channels now avoids sending a duplicate update when the channel activity timestamp has not changed. This reduces race-condition errors and makes chat and live chat behavior more stable for users.
Original PR description
Currently, posting a message to discuss channels is done in two steps: first writing the last_interest_dt to the channel, then creating the message, second triggering the notify_thread to send the message to the followers. In the first step, the last_interest_dt will be directly sent to the client if it differs from the old value. So there is no need to send the message to the client if the last_interest_dt has not changed in the second step. Also, this can lead to a racing condition in the testing files. This commit removes the notif in the second step. Also, adapting the mock_models to the new behavior as the follow-up of https://github.com/odoo/odoo/pull/155569 https://github.com/odoo/enterprise/pull/59130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The calendar year view now keeps month header backgrounds visible when users scroll. This prevents overlapping text and makes the calendar easier to read, especially in smaller browser windows.
Original PR description
In Odoo in the custom `year` FullCalendar view we embed twelve custom `month` FullCalendar views, and it has the option `height` set to `auto`. In FullCalendar (V6), when the `dayGrid` FullCalendar…
In Odoo in the custom `year` FullCalendar view we embed twelve custom `month` FullCalendar views, and it has the option `height` set to `auto`.
In FullCalendar (V6), when the `dayGrid` FullCalendar view as the option `height`/`viewHeight` equals to `auto` it is the same to have the option `stickyHeaderDates` set to `true`.
When the option `stickyHeaderDates` is enabled, the class `fc-scrollgrid-section-sticky` is added to the header of the FullCalendar view. This class as the following rule:
```css
.fc .fc-scrollgrid-section-sticky > * {
background: var(--fc-page-bg-color);
position: sticky;
z-index: 3;
}
```
And since the upgrade of FullCalendar to version 6[1], we have added the following CSS rule.
```css
.o_calendar_widget {
--fc-page-bg-color: none;
}
```
As we have set the `color` to `none`, the `background-color` of the element is `transparent` and so the text overlaps the text behind.
This commit simplifies the CSS rules and fixes the issue.
PS: the old override of the `--fc-page-bg-color` color was to support the dark theme.
From FullCalendar doc[2]
> stickyHeaderDates
> Whether to fix the date-headers at the top of the calendar to the
> viewport while scrolling.
Steps to reproduce:
* Open the Calendar App
* Select the "Year" FullCalendar view
* Resize the window to have a vertical scrollbar if needed
* Scroll down => BUG some day headers have `position` `sticky` with no background.
[1]: odoo/odoo@90f85a19deaea33cd747c969762ff20f1d59ef4c
[2]: https://fullcalendar.io/docs/stickyHeaderDates
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe manufacturing Bill of Materials overview now works correctly when Odoo is used in debug mode. This prevents an error that could interrupt troubleshooting or advanced configuration work, and adds coverage to ensure the overview appears properly in guided tests.
Original PR description
In this [commit](https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR569-R577), the updateResId has been added to the action props. This did not trigger any error as the props are not validated, except if in debug mode. Adding the standardActionServiceProps solves this problem. This bug highlighted another problem: the component does not appear in a tour. opw-3822623 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where creating a planned task from the Gantt view could miss allocated hours when Timesheets was not installed. The task form now includes the needed field so planning calculations run reliably for Project users.
Original PR description
Before this commit, when only project and project_enterprise are instaleld and we try to plan a new task in the gantt view. The compute allocated_hours is not triggered during the onchange because the field is not defined in the form view used by the gantt view. This commit makes sure the allocated_hours field of `project.task` is defined even if `hr_timesheet` is not installed to be sure the compute of that field is triggered during the onchange when we create a task. runbot-58150
Spreadsheet users now receive a more helpful error message when a pivot formula uses an invalid measure. The message shows the available measures, making it easier to correct the formula without extra troubleshooting.
Original PR description
Before this commit, applying a pivot formula with an invalid measure returns an error message without showing possible measures. This commit fixed that Task 3754942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce [17.0+]: - Create a website form of any type in which you have: - One "Name" or other text field. - One field with the "Date" type. - One field "Email" with the visibility condition: "Only visible if" a field of type "Date" "Is set". - When you complete the "Date" field, the "Email" one should show but it does not > It shows if you also add at least two characters to the text field. Starting from [1], an OWL date picker component was introduced m
Original PR description
Steps to reproduce [17.0+]: - Create a website form of any type in which you have: - One "Name" or other text field. - One field with the "Date" type. - One field "Email" with the visibility…
Steps to reproduce [17.0+]:
- Create a website form of any type in which you have:
- One "Name" or other text field.
- One field with the "Date" type.
- One field "Email" with the visibility condition: "Only visible if"
a field of type "Date" "Is set".
- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.
Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.
After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component
(including the form date[time]picker fields).
One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.
The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.
[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
opw-3778129
Forward-Port-Of: odoo/odoo#157328Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
Original PR description
Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
Prior to this commit, PoS did not support searching for products using their internal notes. This limited the search functionality. opw-3795066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157383
Original PR description
Prior to this commit, PoS did not support searching for products using their internal notes. This limited the search functionality. opw-3795066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157383
Before this fix: Receipts printed with kitchen/preparation printer does not show the details of variants products. Just the product template name. This is ambigious for kitchen as the variant information is generally necessary in order to prepare the order correctly After this fix: Restore the previous behavior regarding the product name used This bug is a side effect of: https://github.com/odoo/odoo/pull/152213 due to the changes to `set_full_product_name` Was also a good occasi
Original PR description
Before this fix: Receipts printed with kitchen/preparation printer does not show the details of variants products. Just the product template name. This is ambigious for kitchen as the variant information is generally necessary in order to prepare the order correctly After this fix: Restore the previous behavior regarding the product name used This bug is a side effect of: https://github.com/odoo/odoo/pull/152213 due to the changes to `set_full_product_name` Was also a good occasion to add some tests on the changes name & qty opw-3755391 Forward-Port-Of: odoo/odoo#156764 Forward-Port-Of: odoo/odoo#156390
Description of the issue/feature this PR addresses: Sign CLA agreement for santiagopim Current behavior before PR: No CLA signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157955
Original PR description
Description of the issue/feature this PR addresses: Sign CLA agreement for santiagopim Current behavior before PR: No CLA signed Desired behavior after PR is merged: CLA signed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157955
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157957
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157957
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157960
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157960
Signed a individual CLA Forward-Port-Of: odoo/odoo#156234
Original PR description
Signed a individual CLA Forward-Port-Of: odoo/odoo#156234
Commit [1] made it possible to stay in the backend while refreshing the page with F5 or CTRL+R when viewing a Website Preview. Pressing it too fast when the page is still loading and the iframe isn't loaded yet triggers a traceback. This commit falls back to the default refresh in such cases. [1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd task-3795143 Forward-Port-Of: odoo/odoo#157129
Original PR description
Commit [1] made it possible to stay in the backend while refreshing the page with F5 or CTRL+R when viewing a Website Preview. Pressing it too fast when the page is still loading and the iframe isn't loaded yet triggers a traceback. This commit falls back to the default refresh in such cases. [1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd task-3795143 Forward-Port-Of: odoo/odoo#157129
This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display. Forward-Port-Of: odoo/odoo#158083
Original PR description
This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display. Forward-Port-Of: odoo/odoo#158083
This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`. When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself. By design, the ORM doesn't check security on new records. A base automation of type `'onchange'` will run some server action on a new record. The server action may
Original PR description
This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`. When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself. By design, the ORM doesn't check security on new records. A base automation of type `'onchange'` will run some server action on a new record. The server action may still check access rights on the model, but should not check access rules. Forward-Port-Of: odoo/odoo#158309
This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/odoo#158351 Forward-Port-Of: odoo/odoo#125432
Original PR description
This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/odoo#158351 Forward-Port-Of: odoo/odoo#125432
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User & Companies** > **Groups** * Select `Technical/Analytic Accounting` * Add user * Go to the **Project** app * Select **Configuration** > **Settings** * Under **Time Management**, enable Timesheets * Under **Analytics** > **Analytic Plan**, select Projects * Create a new project * Go in
Original PR description
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User…
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User & Companies** > **Groups** * Select `Technical/Analytic Accounting` * Add user * Go to the **Project** app * Select **Configuration** > **Settings** * Under **Time Management**, enable Timesheets * Under **Analytics** > **Analytic Plan**, select Projects * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is set to Projects * Go to **Conffiguration** > **Settings** * Under **Analytics** > **Analytic Plan**, change Projects to Departments * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is still set to Projects Why the fix: ------------ When creating, an analytic account, the plan is computed with `_get_all_plans()`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903 Inside `__get_all_plans()` the plan is computed as follows: https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L107 However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22 This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings. opw-3751661 Forward-Port-Of: odoo/odoo#158129 Forward-Port-Of: odoo/odoo#157247
Steps: - Install sales app. - Create SO and add a product. - Confirm that SO and create invoice and post it. - Reverse that invoice via adding credit note. - Go to portal view of that SO. Issue: - `Waiting Payment` badge is displaying instead of `Paid` as invoice is reversed Cause: - Only to payment status added to display `Paid` badge. Fix: - Add `Reversed` badge in portal and display reversed badge when payment_state is in reversed state. opw-3677622 Forward-Port-Of: odoo
Original PR description
Steps: - Install sales app. - Create SO and add a product. - Confirm that SO and create invoice and post it. - Reverse that invoice via adding credit note. - Go to portal view of that SO. Issue: - `Waiting Payment` badge is displaying instead of `Paid` as invoice is reversed Cause: - Only to payment status added to display `Paid` badge. Fix: - Add `Reversed` badge in portal and display reversed badge when payment_state is in reversed state. opw-3677622 Forward-Port-Of: odoo/odoo#158418 Forward-Port-Of: odoo/odoo#157693
Related to https://github.com/odoo/odoo/commit/b6fc5ef468f47c109b2d007f211e02ca5f3fe093 Apply rule to account moves to prevent Expense Team Approver user can access to all moves **Description of the issue/feature this PR addresses**: User with Expenses: Team Approver group should not see all moves. **Example use case**: - Create a user with Expenses: Team Approver group. - Login with the created user to /my - The user will only see invoices linked to expenses. **Current behavior
Original PR description
Related to https://github.com/odoo/odoo/commit/b6fc5ef468f47c109b2d007f211e02ca5f3fe093 Apply rule to account moves to prevent Expense Team Approver user can access to all moves **Description of the issue/feature this PR addresses**: User with Expenses: Team Approver group should not see all moves. **Example use case**: - Create a user with Expenses: Team Approver group. - Login with the created user to /my - The user will only see invoices linked to expenses. **Current behavior before PR**: User with Expenses: Team Approver group will **only** be able to see invoices linked to expenses. Ping @pedrobaeza @Tecnativa TT48242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156858
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8 The following journals must have the following possible default account types: - ba
Original PR description
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account,…
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8 The following journals must have the following possible default account types: - bank: asset_cash, - cash: asset_cash, - sale: income, income_other, - purchase: expense, expense_depreciation, expense_direct_cost, - general: all account types are possible, The object of the task was mainly to allow misc journals to allow receivable or payable default account type for the following use case: Suppose a user creates a Miscellaneous Journal to manage the details of the credit card statements. Most journal entries will consist of journal items impacting the Payable Account, as this will reclassify the debt towards various vendors and address this debit to the credit card company. It would in that case be necessary that the liquidity_payable accounts can be the default account on the miscellaneous journal. Otherwise, the user will have to fill in manually the account for each line of its credit card statement, and considering there can be a lot, this could become cumbersome. task-3393017 Forward-Port-Of: odoo/odoo#157188
This issue is occurring when the user tries to add a `VAT` number, while creating a new contact To reproduce this issue: 1) Install `contacts` and `partner_autocomplete` 2) Create a new contact from `Contacts` 3) Give a valid `VAT` number e.g:- `SK2120312645`(got it from sentry) 4) Traceback occurs in the terminal Error:- ``` IndexError: list index out of range File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in
Original PR description
This issue is occurring when the user tries to add a `VAT` number, while creating a new contact To reproduce this issue: 1) Install `contacts` and `partner_autocomplete` 2) Create a new contact from…
This issue is occurring when the user tries to add a `VAT` number,
while creating a new contact
To reproduce this issue:
1) Install `contacts` and `partner_autocomplete`
2) Create a new contact from `Contacts`
3) Give a valid `VAT` number e.g:- `SK2120312645`(got it from sentry)
4) Traceback occurs in the terminal
Error:-
```
IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/partner_autocomplete/models/res_partner.py", line 158, in read_by_vat
'city': zip_city[1],
```
In some cases, the expected `zip_city` value is not at the last of the address list ,
which leads to above traceback. As `zip_city` must contain both zip and city values.
https://github.com/odoo/odoo/blob/382b64c2f14073cfff1a8ef9290b5c7834d52188/addons/partner_autocomplete/models/res_partner.py#L143-L156
After applying this commit will resolve this issue by searching `zip_city` based on regex.
sentry-5058467547
Forward-Port-Of: odoo/odoo#158368
Forward-Port-Of: odoo/odoo#157697Some taxes of skr03 and skr04 were not set for the appropriate tax group. This was fixed, and each tax was set to its appropriate tax group. Taxes should not be set with wrong tax groups. task-3800915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158555 Forward-Port-Of: odoo/odoo#158034
Original PR description
Some taxes of skr03 and skr04 were not set for the appropriate tax group. This was fixed, and each tax was set to its appropriate tax group. Taxes should not be set with wrong tax groups. task-3800915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158555 Forward-Port-Of: odoo/odoo#158034
With this PR https://github.com/odoo/odoo/pull/129717 we fixed multiple problems of the Swiss tax report but the 200 box is still not correct. Fix the computation of the box 200 of the Swiss tax report. We remove 382 and 383 boxes that are for purchases and shouldn't be included. We add box 205 and 289 so that the box 200 somehow represent the "gross" taxed amount, and 299 is therefore the "net" amount. 200 = 302 to 343 + 205 + 289 opw-3766215 Forward-Port-Of: odoo/odoo#158477 Forward
Original PR description
With this PR https://github.com/odoo/odoo/pull/129717 we fixed multiple problems of the Swiss tax report but the 200 box is still not correct. Fix the computation of the box 200 of the Swiss tax report. We remove 382 and 383 boxes that are for purchases and shouldn't be included. We add box 205 and 289 so that the box 200 somehow represent the "gross" taxed amount, and 299 is therefore the "net" amount. 200 = 302 to 343 + 205 + 289 opw-3766215 Forward-Port-Of: odoo/odoo#158477 Forward-Port-Of: odoo/odoo#158008
Issue: ------ The `partner_autocomplete` module is an automatically installed module. This module is not included in the dependencies and can therefore be uninstalled. If `partner_autocomplete` is uninstalled and we go to a shared project with a portal user for example, we get an internal server error, as we don't have access to the `partner_autocomplete` files. Solution: --------- Remove the `partner_autocomplete` files from the manifest file of the `project` module. Note: If the
Original PR description
Issue: ------ The `partner_autocomplete` module is an automatically installed module. This module is not included in the dependencies and can therefore be uninstalled. If `partner_autocomplete` is uninstalled and we go to a shared project with a portal user for example, we get an internal server error, as we don't have access to the `partner_autocomplete` files. Solution: --------- Remove the `partner_autocomplete` files from the manifest file of the `project` module. Note: If the widget is not found (in the very rare case of uninstalling the `partner_autocomplete` module), we will use the default widget (and create a log). opw-3774575 Forward-Port-Of: odoo/odoo#158090 Forward-Port-Of: odoo/odoo#157411
Steps to reproduce: ``` | Step | Move | Action | Date | Name | | ---- | ---- | ----------- | ---------- | ----------- | | 1 | `A` | Add | 2023-02-01 | `2023/02/0001` | | 2 | `B` | Add | 2023-02-02 | `/` | | 3 | `B` | Post | 2023-02-02 | `2023/02/0002` | | 4 | `A` | Cancel | 2023-02-01 | `2023/02/0003` | -> Wrong ``` Issue: The first invoice should keep its se
Original PR description
Steps to reproduce:
```
| Step | Move | Action | Date | Name |
| ---- | ---- | ----------- | ---------- | ----------- |
| 1 | `A` | Add | 2023-02-01 | `2023/02/0001` |
| 2 | `B` | Add | 2023-02-02 | `/` |
| 3 | `B` | Post | 2023-02-02 | `2023/02/0002` |
| 4 | `A` | Cancel | 2023-02-01 | `2023/02/0003` | -> Wrong
```
Issue:
The first invoice should keep its sequence to 1
opw-3757022
Forward-Port-Of: odoo/odoo#158435
Forward-Port-Of: odoo/odoo#156865Before this commit sol name was not reflacting invoice status when it moved to posted it only reflect draft and cancel state. This commit re-compute downpayment related sol name when invoice related to that sol get posted this way it'll update sol name to proper name instead of keeping always Draft string in it. opw-3768323 Forward-Port-Of: odoo/odoo#158206 Forward-Port-Of: odoo/odoo#157824
Original PR description
Before this commit sol name was not reflacting invoice status when it moved to posted it only reflect draft and cancel state. This commit re-compute downpayment related sol name when invoice related to that sol get posted this way it'll update sol name to proper name instead of keeping always Draft string in it. opw-3768323 Forward-Port-Of: odoo/odoo#158206 Forward-Port-Of: odoo/odoo#157824
Steps to reproduce: - Install contacts and base_address_extended - Install a module adding "res.city" records (e.g. l10n_co_edi) - Go to Contacts and create a new one: * Name: [any] * Country: Colombia * City (city_id): [any] - Create a "child" contact of "Contact" type - Save the contact Issue: "city_id" field of the child contact is False. It is not possible to set the address of a contact-type contact manually. Some address fields ('street', 'street2', 'zip', 'city', 'state
Original PR description
Steps to reproduce: - Install contacts and base_address_extended - Install a module adding "res.city" records (e.g. l10n_co_edi) - Go to Contacts and create a new one: * Name: [any] * Country:…
Steps to reproduce:
- Install contacts and base_address_extended
- Install a module adding "res.city" records (e.g. l10n_co_edi)
- Go to Contacts and create a new one:
* Name: [any]
* Country: Colombia
* City (city_id): [any]
- Create a "child" contact of "Contact" type
- Save the contact
Issue:
"city_id" field of the child contact is False.
It is not possible to set the address of a contact-type contact manually. Some address fields ('street', 'street2', 'zip', 'city', 'state_id', 'country_id') are synchronized with the parent contact.
"city_id" is not and is not settable at all for contact-type contact. It could be an issue for Colombian or Mexican localizations if a child contact is used for an invoice as some data have to be retrieved from "city_id" field to generate the electronic invoice.
Solution:
Add "city_id" in the list of address fields to sync.
opw-3747296
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156922This enhancement optimizes the computation of prices for expenses associated with product categories. Previously, the computation was inefficient, relying on a stored computed field directly linked to product_id.standard_price. This commit overrides the write method on the product to only update unsubmitted expenses using the product as a category. The dependence is also changed to product_id instead of product_id.standard_price for better performance. Both changes aim to improve the performance
Original PR description
This enhancement optimizes the computation of prices for expenses associated with product categories. Previously, the computation was inefficient, relying on a stored computed field directly linked to product_id.standard_price. This commit overrides the write method on the product to only update unsubmitted expenses using the product as a category. The dependence is also changed to product_id instead of product_id.standard_price for better performance. Both changes aim to improve the performance. task-3741886 Forward-Port-Of: odoo/odoo#154234
Issue: Currently if we have taxes for our Purchase no matter if we set the tax to inactive or we archive it, we will have access to it on the purchase_order_line. Steps to reproduce: - Install Purchase - Create a new Tax and set it to inactive. - Now create a new RfQ and in the lines add any product. - Try to change the tax for this product. Solution: since commit 8ff6747 we got rid of an odd domain which was allowing us to always get every tax no matter if they were active or not. I
Original PR description
Issue: Currently if we have taxes for our Purchase no matter if we set the tax to inactive or we archive it, we will have access to it on the purchase_order_line.
Steps to reproduce:
- Install Purchase
- Create a new Tax and set it to inactive.
- Now create a new RfQ and in the lines add any product.
- Try to change the tax for this product.
Solution: since commit 8ff6747 we got rid of an odd domain which was allowing us to always get every tax no matter if they were active or not. In order for this domain to work we needed to set `context={'active_test': False}` which we no longer need and It's creating a bad behavior on how we want the active field on tax to act.
opw-3776871
Forward-Port-Of: odoo/odoo#158077This commit introduces an improvement in the hr_holidays module by making the duration field of leave allocations editable even after they have been approved. This change addresses a limitation where previously, allocations had to be refused and revalidated for any adjustments. Task-3716272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154553
Original PR description
This commit introduces an improvement in the hr_holidays module by making the duration field of leave allocations editable even after they have been approved. This change addresses a limitation where previously, allocations had to be refused and revalidated for any adjustments. Task-3716272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154553
Incorporate Christihan Laurel (CLaurelB) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158615 Forward-Port-Of: odoo/odoo#158221
Original PR description
Incorporate Christihan Laurel (CLaurelB) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158615 Forward-Port-Of: odoo/odoo#158221
There are currently translation issues related to the chart template. Due to this the names of some records do not receive the necessary / intended translations when installing a localization or new language. When installing a new localization / chart some records have the following problem with the values of their translatabe fields: They are only installed in the language that was active when the localization / chart was installed. Thus when switching languages (or using a different us
Original PR description
There are currently translation issues related to the chart template. Due to this the names of some records do not receive the necessary / intended translations when installing a localization or new…
There are currently translation issues related to the chart template.
Due to this the names of some records do not receive the necessary
/ intended translations when installing a localization or new language.
When installing a new localization / chart some records have the following
problem with the values of their translatabe fields:
They are only installed in the language that was active when the localization / chart was installed.
Thus when switching languages (or using a different user with a different language)
the names are displayed in the "installation language".
Translations for all active languages should be installed (for all relevant records).
The same problem happens when installing a new language
(the same records do not receive a translation for the new language).
The translation issue concerns for example (some) accounts and journals;
see the (incomplete) list at the end of this message.
This commit tries to fix the translation issue for the translatable
fields of all relevant models.
Note!
=====
* The translation mechanism only works for records with xmlid.
If a module creates a record without xmlid it will not be translated.
* The problem is only fixed for records with xmlid for which at least 1 of the
following conditions holds:
* The record (and the translatable field value) is defined in
the body of the function decorated with 'https://github.com/template'
* The translation of the value of the translatable field can
be found in the module 'account' or in the module that
is associated with the record (by 'ir.model.data')
I.e. the problem is not solved for demo data: It is technically
difficult to determine the module they originate from.
This makes it difficult to load the right code translation (the
module information is needed for this).
* The translation mechanism is not necessarily triggered
if the record is (in principal) part of the chart template
but not installed as part of the chart template.
This can i.e. happen if a module is installed after the
localization / chart.
* Example: account.journal "Salaries" from hr_payroll_account
* We also want to "translate" / localize some untranslatable fields
(like account journal codes). For these fields the terms will be
installed in the language of the partner of the company for which
the chart will be installed (fallback to lang / user lang from the
env in case there is none set)
* Currently there is no language set for many (all?) demo comany.
Thus the values will remain in English for them (when the
respective module is installed).
Examples / Details
==================
**Reproduce**:
1. Switch to the French language (install if needed)
(Settings App > General Settings > Languages)
2. Install a localisation (e.g. l10n_fr).
3. Check the French translations of the localization
* Comptabilité > Configuration (Menu) > Journaux
(Accounting > Configuration (Menu) > Journals)
* Here the journal names are in French
* Comptabilité > Configuration (Menu) > Plan comptable
(Accounting > Configuration (Menu) > Chart of Accounts)
* All the account names are in French
4. Switch to English on the current user (or some other language)
via the user profile on the top right.
5. Check the names of the localization again
* Accounting
* The journal names are still in French
* Accounting > Configuration (Menu) > Chart of Accounts
* Some of the account names are still in French
* E.g. "Compte d'attente de la banque" ("Bank Suspense Account")
Other things to test:
* "Salaries" journal from enterprise module 'hr_payroll_account'
* Not demo data; it will (partly) work after this commit (see "Note" above)
* "IFRS Automatic transfers" journal from enterprise module
'account_auto_transfer' (installed when installing l10n_fr)
* Demo data; the problem remains after this commit
**Technically** the main problems are the following:
1. The information of some of the created records is only defined in
the code. Thus their translations have to be taken from the
translation of the code.
But at the point of translation it is not clear from which
module the data came from. This is needed to load the right translation.
* This was fixed for data from 'https://github.com/template' functions
2. Some records are created without an xmlid and thus
cannot be translated with the current translation mechanism at all.
* This was fixed for the relevant records from module 'account'
Example Records
---------------
Some affected **accounts**:
* from module 'account'
* Bank utility accounts
* Bank Suspense Account
* Outstanding Receipts
* Outstanding Payments
* Cash Discount Loss
* Cash Discount Gain
* Cash Difference Loss
* Cash Difference Gain
* Liquidity Transfer
* Bank / Cash journal default accounts
* Bank
* Cash
* Unaffected earnings account
* Undistributed Profits/Losses
Some affected **journals**
* from module 'account'
* Customer Invoices
* Vendor Bills
* Miscellaneuos Operations
* Exchange Difference
* Cash Basis Taxes
* Bank
* Cash
* from module 'account_auto_transfer' (enterprise)
* IFRS Automatic Transfers
* The problem will remain since it is demo data
* from module 'hr_payroll_account' (enterprise)
* Salaries
* The translation is only loaded if the module is installed
before the localization / chart
task info
=========
task-3414329
Forward-Port-Of: odoo/odoo#158382
Forward-Port-Of: odoo/odoo#137592Steps to reproduce ================== In 17: - Install hr_holidays,project - Switch the language to dutch - Go to project > three dots > Projectupdates We can see `x/y Genomen`, it should be `x/y Taken` Cause of the issue ================== The original term is Tasks. When loading the views, python translates them and changes Tasks to Taken. Owl then translates the template and transforms Taken to Genomen. Solution ======== Since the views are already translated, we don'
Original PR description
Steps to reproduce ================== In 17: - Install hr_holidays,project - Switch the language to dutch - Go to project > three dots > Projectupdates We can see `x/y Genomen`, it should be `x/y Taken` Cause of the issue ================== The original term is Tasks. When loading the views, python translates them and changes Tasks to Taken. Owl then translates the template and transforms Taken to Genomen. Solution ======== Since the views are already translated, we don't need to translate them with owl. We can simply set the attribute t-translation to off on the view root node. opw-3787336 Forward-Port-Of: odoo/odoo#158627 Forward-Port-Of: odoo/odoo#158278
**Current behavior before PR:** When you increase the height or width of cells in a table and subsequently delete a row or column, the adjacent rows or columns experience an increase in their height or width. This happens because the table preserves its overall dimensions even after resizing individual cells. **Desired behavior after PR is merged:** Now, the table no longer preserves its height or width. When resizing the table, the height or width of its rows or columns does not in
Original PR description
**Current behavior before PR:** When you increase the height or width of cells in a table and subsequently delete a row or column, the adjacent rows or columns experience an increase in their height or width. This happens because the table preserves its overall dimensions even after resizing individual cells. **Desired behavior after PR is merged:** Now, the table no longer preserves its height or width. When resizing the table, the height or width of its rows or columns does not increase. task-3636212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146091
This fix was merged yesterday: https://github.com/odoo/odoo/pull/154239 The fix is ok but the test is testing the display name on the product. It is not necessary for the purpose of the change. Forward-Port-Of: odoo/odoo#157546
Original PR description
This fix was merged yesterday: https://github.com/odoo/odoo/pull/154239 The fix is ok but the test is testing the display name on the product. It is not necessary for the purpose of the change. Forward-Port-Of: odoo/odoo#157546
Purpose ======= Lots of tickets are issues when the end user deleted this product category, leading to the impossibility to install another carrier as this category is referenced by all the specific carriers products Ticket example: 3789116 TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward
Original PR description
Purpose ======= Lots of tickets are issues when the end user deleted this product category, leading to the impossibility to install another carrier as this category is referenced by all the specific carriers products Ticket example: 3789116 TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158420 Forward-Port-Of: odoo/odoo#158084
Those master data would break the basic accounting pdf generation flow as those are widely used and it is not expected from end users to delete them. Example of support ticket from that issue: 3790875 TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158403 Forward-Port-Of:
Original PR description
Those master data would break the basic accounting pdf generation flow as those are widely used and it is not expected from end users to delete them. Example of support ticket from that issue: 3790875 TaskID: 3802440 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158403 Forward-Port-Of: odoo/odoo#158080
Before this commit, the header was considered as mobile at the `SM` screen breakpoint, while it is already displayed as in mobile view at `MD`. This made some of the header behaviors inconsistent: 1) A menu open at `MD` is not closed when resizing the screen: - Resize the screen at `MD` and open the menu. - Resize the screen above `LG`. - Resize back at `MD`. => The menu was not closed. It is when we start resizing at `SM`, which is inconsistent as they are both displayed like in mobil
Original PR description
Before this commit, the header was considered as mobile at the `SM` screen breakpoint, while it is already displayed as in mobile view at `MD`. This made some of the header behaviors inconsistent: 1)…
Before this commit, the header was considered as mobile at the `SM`
screen breakpoint, while it is already displayed as in mobile view at
`MD`. This made some of the header behaviors inconsistent:
1) A menu open at `MD` is not closed when resizing the screen:
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
- Resize back at `MD`.
=> The menu was not closed. It is when we start resizing at `SM`, which
is inconsistent as they are both displayed like in mobile view.
2) The menus are hoverable at `MD` but not at `SM`:
- Add sub-menus and mega menus with the menu editor.
- In edit mode, set the menus as hoverable (set the "Sub Menus" option
to "On Hover") and save.
- Hover the menus:
- above `LG` (= desktop view) => they open.
- under `SM` (= mobile view) => they do not open because we need to
click to open them on mobile view.
- between `SM` and `LG` => they open even though it is displayed like
in mobile view, so the behaviors are inconsistent.
This commit considers the header as mobile under the `LG` screen
breakpoint, to uniformize the behaviors of the mobile header.
task-3801970
Forward-Port-Of: odoo/odoo#158571
Forward-Port-Of: odoo/odoo#157601Since [1] when options on background images have been applied as soon as they were modified instead of on save, those options were not reset when the background was removed. This commit removes those options when the background image is removed. Steps to reproduce: - Drop a Text snippet. - Add a background image. - Remove the background image. - Save. => Save failed. [1]: https://github.com/odoo/odoo/commit/4a797f51ec9d3d378fc30033e4fda2bc1e73586c task-3794812 Forward-Port-Of
Original PR description
Since [1] when options on background images have been applied as soon as they were modified instead of on save, those options were not reset when the background was removed. This commit removes those options when the background image is removed. Steps to reproduce: - Drop a Text snippet. - Add a background image. - Remove the background image. - Save. => Save failed. [1]: https://github.com/odoo/odoo/commit/4a797f51ec9d3d378fc30033e4fda2bc1e73586c task-3794812 Forward-Port-Of: odoo/odoo#158326 Forward-Port-Of: odoo/odoo#157414
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor. Press Ctrl+Z. Before this commit, the value disappears -- is undone -- even though no real change happened. This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history. This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) () with: ```js //Set and get content: editor.setValue("
Original PR description
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor. Press Ctrl+Z. Before this commit, the value disappears -- is undone -- even…
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor. Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened. This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) () with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#158417
Forward-Port-Of: odoo/odoo#158279Steps to reproduce: - Install Invoicing (and Sales for product creation rights) - From a company, create a Branch company - Switch to parent company - In Invoicing settings of parent company, set default taxes - Switch to branch company - In Invoicing settings of branch company, set no default taxes - Create a user with only the branch company as allowed companies - Give the user the right to create a product (e.g. Sales: Administrator) - Connect with the created user - Try to create a
Original PR description
Steps to reproduce: - Install Invoicing (and Sales for product creation rights) - From a company, create a Branch company - Switch to parent company - In Invoicing settings of parent company, set default taxes - Switch to branch company - In Invoicing settings of branch company, set no default taxes - Create a user with only the branch company as allowed companies - Give the user the right to create a product (e.g. Sales: Administrator) - Connect with the created user - Try to create a product Issue: An Access Error is raised due to "company rule employee" rule because the system tries to fetch the default taxes from the parent company, which is not activated in the company selector. opw-3790360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158567 Forward-Port-Of: odoo/odoo#157565
**Steps to reproduce:** - Open an event and go to the Community page - Try to customize it => traceback on clicking the 'Customize' tab. **Cause:** The `_getRpcData` function called by '_computeWidgetState' method does not exist anymore since https://github.com/odoo/odoo/commit/03c5526 **Fix:** This PR eliminates the call to the `_getRpcData` function and alters the code of 'options.js' to get rpcData for the 'allow room creation' checkbox, through an implementation similar to that of
Original PR description
**Steps to reproduce:** - Open an event and go to the Community page - Try to customize it => traceback on clicking the 'Customize' tab. **Cause:** The `_getRpcData` function called by '_computeWidgetState' method does not exist anymore since https://github.com/odoo/odoo/commit/03c5526 **Fix:** This PR eliminates the call to the `_getRpcData` function and alters the code of 'options.js' to get rpcData for the 'allow room creation' checkbox, through an implementation similar to that of 'website menu'. Task: [3805901](https://www.odoo.com/web#id=3805901&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#158684 Forward-Port-Of: odoo/odoo#157831
Versions -------- - 16.0+ Steps ----- 1. Create a leave spanning multiple days; 2. create a public holiday that falls inside that leave; 3. check leave in list view & form view. Issue ----- The leave's duration no longer matches between the two views. In form view, the duration was updated, in list view, it remained unchanged. Cause ----- The field in form view uses a non-stored computed field `number_of_days_display`, whereas the field used in the list view is the stored comp
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create a leave spanning multiple days; 2. create a public holiday that falls inside that leave; 3. check leave in list view & form view. Issue ----- The leave's duration no longer matches between the two views. In form view, the duration was updated, in list view, it remained unchanged. Cause ----- The field in form view uses a non-stored computed field `number_of_days_display`, whereas the field used in the list view is the stored computed field `duration_display` which depends on the non-stored one. As a consequence, changes to the non-stored field don't trigger a recomputation of the stored field, leaving it unchanged. Solution -------- Call `_compute_duration_display` from the compute methods of its dependents, and add the dependents to the view as invisible fields to trigger recomputation. opw-3642500 Forward-Port-Of: odoo/odoo#158296 Forward-Port-Of: odoo/odoo#157210
With a SA company setup Open a jounrnal entry Hit 'Reverse Entry' > Reverse Error: "For Credit/Debit notes issued in Saudi Arabia, you need to specify a Reason" This occurs because with SA localization we need to provide a reason for move reversal but by default the reason field is invisible for journal entries opw-3789732 Forward-Port-Of: odoo/odoo#157996
Original PR description
With a SA company setup Open a jounrnal entry Hit 'Reverse Entry' > Reverse Error: "For Credit/Debit notes issued in Saudi Arabia, you need to specify a Reason" This occurs because with SA localization we need to provide a reason for move reversal but by default the reason field is invisible for journal entries opw-3789732 Forward-Port-Of: odoo/odoo#157996
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the opt
Original PR description
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore. Forward-Port-Of: odoo/odoo#149542
Steps to repreduce: - with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` tax - Reporting > Tax report **The values of Block F and G appears in negative** Cause of the issue: - The erroneous values come from the `se_48` formula of the `account_tax_report_data` which provides minus the value it should: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_report_data.xml
Original PR description
Steps to repreduce: - with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` tax - Reporting > Tax report **The values of Block F and G…
Steps to repreduce: - with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` tax - Reporting > Tax report **The values of Block F and G appears in negative** Cause of the issue: - The erroneous values come from the `se_48` formula of the `account_tax_report_data` which provides minus the value it should: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_report_data.xml#L374 This is due to the fact that the `plus_report_expression_ids` and the `minus_report_expression_ids` refering to the `tax_report_line_48_tag` are swapped on all purchase taxes, as suggested by the other report expressions in that file e.g. https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_template.xml#L361-L366 Fix: - We swap back these references for all tax tags on puchases taxes. opw-3750771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158097 Forward-Port-Of: odoo/odoo#155744
Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`. This commit fixes the issue by checking employee_ids directly and if it is found, the profile button will be displayed correctly. We don't care about which employee_id is used if there are multiple, since the user are in multiple companies as well. If looking for a specific profile,
Original PR description
Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`.
This commit fixes the issue by checking employee_ids directly and if it is found, the profile button will be displayed correctly.
We don't care about which employee_id is used if there are multiple, since the user are in multiple companies as well. If looking for a specific profile, the employee can be found in the HR application.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#157907
Forward-Port-Of: odoo/odoo#157741Many banks (Itaú, Santander, Caixa) don't support Pix codes without a reference. To fix set a dummy reference of "***" when none is set (this is what Santander bank does when generating Pix codes without a reference). Again thanks to INGO for testing. opw-3818534 Forward-Port-Of: odoo/odoo#158713
Original PR description
Many banks (Itaú, Santander, Caixa) don't support Pix codes without a reference. To fix set a dummy reference of "***" when none is set (this is what Santander bank does when generating Pix codes without a reference). Again thanks to INGO for testing. opw-3818534 Forward-Port-Of: odoo/odoo#158713
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca Issue: ====== valuation unit cost is wrong when we do backorder with real time unit price computation Steps to reproduce the issue: ============================= - Create a kit with 2 components with product quntity to produce = 3 - Put qty = 2 for the first component and qty = 1 for the second component - Assign product category to the kit product and the components as fi
Original PR description
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca Issue: ====== valuation unit cost is wrong when we do backorder with real time unit…
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca Issue: ====== valuation unit cost is wrong when we do backorder with real time unit price computation Steps to reproduce the issue: ============================= - Create a kit with 2 components with product quntity to produce = 3 - Put qty = 2 for the first component and qty = 1 for the second component - Assign product category to the kit product and the components as fifo one with automatec price computation - Create a purchase order with 30 quantity of the kit and price unit = 90 - confirm order and go to receipt - Confirm 4 qty for the first component and 2 qty for the second. - Create backorder - Go to the confirmed receipt and go to valuation - You will see that the total sum corresponds to the price of all the products and not only the confirmed ones. Solution: ========= We need to use the bom quantities and not the order line to get the unit_cost of each component. opw-3790132 Forward-Port-Of: odoo/odoo#158592 Forward-Port-Of: odoo/odoo#158072
Related to: https://github.com/OCA/l10n-spain/issues/3054 FYI: tax mapping tags have not been added, as Odoo hasn't "Modelo 123" in V14. @pedrobaeza @rafaelbn @acysos I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149476 Forward-Port-Of: odoo/odoo#124688
Original PR description
Related to: https://github.com/OCA/l10n-spain/issues/3054 FYI: tax mapping tags have not been added, as Odoo hasn't "Modelo 123" in V14. @pedrobaeza @rafaelbn @acysos I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149476 Forward-Port-Of: odoo/odoo#124688
Create a [TEST] product: - Routes: - Replenish on Order (MTO) - Buy Assign to [TEST] the following Bill of Material: - BoM Type: Subcontracting - Subcontractors: [Partner] - Components: - [component 1] - [component 2] Components are set up as follows: - Routes: - Buy - Resupply Subcontractor on Order Now create a PO: - Partner: [Partner] - Product: [TEST] Confirm the PO Go to the created resupply picking Issue: there is a smart button for manufacturing The MO should
Original PR description
Create a [TEST] product: - Routes: - Replenish on Order (MTO) - Buy Assign to [TEST] the following Bill of Material: - BoM Type: Subcontracting - Subcontractors: [Partner] - Components: - [component 1] - [component 2] Components are set up as follows: - Routes: - Buy - Resupply Subcontractor on Order Now create a PO: - Partner: [Partner] - Product: [TEST] Confirm the PO Go to the created resupply picking Issue: there is a smart button for manufacturing The MO should not be visible and the smart button should not be there. opw-3801113 Forward-Port-Of: odoo/odoo#158085
**Description of the issue/feature this PR addresses:** - Remove context which came from the calendar action to only show short name in activity message - ~Add the start and end datetime for notification of the manager, otherwise the manager has a useless email which would need to open a browser to get the notified information (waste of time)~ - Replace date connector with - as a / does not help to better understand the data given **Current behavior before PR:** Incomplete information i
Original PR description
**Description of the issue/feature this PR addresses:** - Remove context which came from the calendar action to only show short name in activity message - ~Add the start and end datetime for notification of the manager, otherwise the manager has a useless email which would need to open a browser to get the notified information (waste of time)~ - Replace date connector with - as a / does not help to better understand the data given **Current behavior before PR:** Incomplete information in the notification emails for time off approvals **Desired behavior after PR is merged:** A better and at least valuable information provided to the manager in a stable way to fix things. Info: @wt-io-it In relation to: - OPW-3628915 - OPW-3764283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157891 Forward-Port-Of: odoo/odoo#155900
Those are optional, commit [1] mimicked the python code in JS but with a mistake: "required" instead of "optional". Steps to reproduce: - Enable cookies setting on website - Drag & drop a snippet - Modify that snippet conditional visibility to "Utm Campaign: Sale" - Visit in incognito /?utm_campaign=Sale, you don't see the snippet, which is good - Now click on "Only Essentials" in the cookies banner - The snippet will be shown, because when accepting the essentials cookies, the utm ones
Original PR description
Those are optional, commit [1] mimicked the python code in JS but with a mistake: "required" instead of "optional". Steps to reproduce: - Enable cookies setting on website - Drag & drop a snippet - Modify that snippet conditional visibility to "Utm Campaign: Sale" - Visit in incognito /?utm_campaign=Sale, you don't see the snippet, which is good - Now click on "Only Essentials" in the cookies banner - The snippet will be shown, because when accepting the essentials cookies, the utm ones were set, since they were marked as required. [1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eec Forward-Port-Of: odoo/odoo#158720 Forward-Port-Of: odoo/odoo#158590
Steps to reproduce: * Activate multi-currency (Company currency `USD`, another currency activated 'EUR') * Create invoice/bill in `EUR` and post it * Archive `EUR` * Open Invoice/Bill Issue: * Alert for inactivated currency is always displayed Fix: * Alert for inactivated currency should be displayed in draft state only Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed th
Original PR description
Steps to reproduce: * Activate multi-currency (Company currency `USD`, another currency activated 'EUR') * Create invoice/bill in `EUR` and post it * Archive `EUR` * Open Invoice/Bill Issue: * Alert for inactivated currency is always displayed Fix: * Alert for inactivated currency should be displayed in draft state only Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158639 Forward-Port-Of: odoo/odoo#98341
Before this commit, it happens that the taxes display on the pdf were wrap, specially when the description in the pdf were too long. This commit will add a text-nowrap on the taxes when the len of the taxes is shorter than 10 characters. task: 3754824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158774 Forward-Port-Of: odoo/odoo#154709
Original PR description
Before this commit, it happens that the taxes display on the pdf were wrap, specially when the description in the pdf were too long. This commit will add a text-nowrap on the taxes when the len of the taxes is shorter than 10 characters. task: 3754824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158774 Forward-Port-Of: odoo/odoo#154709
Commit [1] was introduced to fix an issue where the website menu cache is incompatible with having a slug url in one of its menu. But in the enterprise build, since the website_helpdesk module is adding one menu containing a slug url, it would disable the menu cache. Unfortunately, the website_blog perf tests (at_install) are executed after website_helpdesk is installed, meaning that in enterprise, the perf test of website_blog would fail since it would require some more SQL Queries (1 or 2 d
Original PR description
Commit [1] was introduced to fix an issue where the website menu cache is incompatible with having a slug url in one of its menu. But in the enterprise build, since the website_helpdesk module is adding one menu containing a slug url, it would disable the menu cache. Unfortunately, the website_blog perf tests (at_install) are executed after website_helpdesk is installed, meaning that in enterprise, the perf test of website_blog would fail since it would require some more SQL Queries (1 or 2 depending of the test) to render a blog post as it would have to query the website.menu table. It's still unclear how commit [1] was merged in the codebase since the enterprise staging should have failed. runbot-60466 runbot-60467 [1]: https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20 Forward-Port-Of: odoo/odoo#158533
Before this commit: In POS online payment the usually the user is either the logged in user/public user which ends up raising error `The phone number is invalid` even when the customer is selected After this commit: Razorpay doesn't raise the error instead we send no phone number due to which user has to enter his/her phone number manually on the razorpay checkout page task-3786679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Before this commit: In POS online payment the usually the user is either the logged in user/public user which ends up raising error `The phone number is invalid` even when the customer is selected After this commit: Razorpay doesn't raise the error instead we send no phone number due to which user has to enter his/her phone number manually on the razorpay checkout page task-3786679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157533
2 changes
Resolved issues and error corrections
This update resolves an issue preventing sale reports from generating correctly when multiple bank accounts were used for a payment. The previous system required a single account payment, which is now corrected. This ensures accurate reporting for all sales transactions, regardless of payment method.
Original PR description
Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
This update fixes a default setting in the restaurant POS module that was incorrectly configured for US customers in the SaaS environment. Previously, the system automatically enabled tipping after payment, regardless of the user's country. This change ensures a better experience for all users by removing the US-specific default.
Original PR description
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore. Forward-Port-Of: odoo/odoo#149542
31 changes
Enhancements to existing features
The WhatsApp module is renamed to WhatsApp Messaging and receives clearer labels, placeholders, buttons, and helper text across account, template, and message screens. These updates make setup, template management, and message review easier for users without changing core business workflows.
Original PR description
In this commit, the module is renamed to 'WhatsApp Messaging'. Moreover, there are several view changes in WhatsApp accounts form view, WhatsApp templates form view and search view, and WhatsApp…
In this commit, the module is renamed to 'WhatsApp Messaging'. Moreover, there are several view changes in WhatsApp accounts form view, WhatsApp templates form view and search view, and WhatsApp message list view. - The summary of the module is changed to 'Text your Contacts on WhatsApp'. - A body field is added in the search view of WhatsApp templates. - The string for toaster notifications while syncing the templates and testing the connection is changed. - The toaster notification while resending failed messages is removed. - In the WhatsApp account form view, the field sequence is changed, buttons are renamed with new icons added to it, placeholders are added and unwanted strings are removed. - Smiling Face is added in when no accounts are configured. - Strings for failure type in WhatsApp messages are changed. - The string for action helpers of WhatsApp accounts, WhatsApp templates, and WhatsApp messages are changed. - Placeholders for name, account, users, and body fields are changed for the WhatsApp template form view. Task - 3619071
Leave durations are now computed in batches instead of one by one, improving performance when handling multiple time off records. This helps HR teams work more smoothly in planning views and related payroll processes without changing the user workflow.
Knowledge article item views now handle creation and deletion permissions more consistently, reducing access errors for users. The update also improves item list and calendar usability with a trash action, cleaner calendar headers, and richer kanban quick creation.
Original PR description
Purpose: -------- ### 1. Currently, users cannot create items from opened embed views (except for the kanban view from which it is possible to use the quickcreate feature regardless of the user's…
Purpose: -------- ### 1. Currently, users cannot create items from opened embed views (except for the kanban view from which it is possible to use the quickcreate feature regardless of the user's right on the parent article, which may lead to access errors). The limitation is due to the usage of the environment to store the user's write permission on the parent article, which is lost when opening the view. Instead of using the environment, this piece of data is now stored in the context, and is therefore set when the view is embedded and when it is opened in full screen. When the opened view is reloaded, the context is lost and the actions are enabled by default, except for - the quick creation in the kanban views as other keys needed for it to work as expected are missing - the calendar view, as it is in "missing configuration" mode in that case ### 2. Hide the delete button in the popovers of item calendar views if the user cannot write on the item. ### 3. Remove useless scrollbars in the item calendar's header. ### 4. Add a "trash" button on top of the item list view, allowing the user to send the selected items to the trash. ### 5. Add properties field on the quick create view of the item kanban view. Task-3607081
Cohort reports now show only measures that can be meaningfully summed, reducing confusing or misleading reporting options. This helps users choose accurate metrics when analyzing helpdesk trends and cohort data.
Original PR description
<h3>Current behavior before PR:</h3> - Storable fields of type `[integer, float, monetary]` with `aggregator` not undefined are visible in measure for the cohort view. <h3>Desired behavior after the PR is merged:</h3> - Only summable fields (`aggregator = 'sum'`) should only visible in measure for the cohort view. Related Community PR:- https://github.com/odoo/odoo/pull/152806 Task-3677742
Australian payroll can now include termination payment calculations directly in an employee's final payslip instead of requiring a separate payslip. This simplifies end-of-employment processing and improves handling of related withholding and unused leave rules.
Original PR description
The termination payments are added as a separate salary structure. That only allows termination payment to be made through a new payslip after the final payslip. This commit allows the rules from the temination structure to be added directly to the last payslip along with the default structure. task # 3639270
Referral emails now include job list links tailored to the companies selected by the sender. This helps recipients find relevant openings more easily when referrals cover one or multiple companies.
Original PR description
When sending an email to a friend, depending on how many companies are selected, different links related to the job list of every selected company are attached to the email body. Task-3425248
Resolved issues and error corrections
This update rewrites complex reporting queries in a safer internal format so automated checks can handle them reliably. It helps reduce false alarms and maintenance risk in accounting and localization reports without changing day-to-day user workflows.
Original PR description
After some improvements the SQL checker now sees those queries, and can't cope with their complexity. Also deprecate `AccountReport._query_get`, literally all it does is unwrap `_get_table_expression` making things harder to check.
Users can now duplicate read-only Sign templates without encountering an error. This makes it easier to reuse existing templates and continue document workflows without interruption.
Original PR description
Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206
The Helpdesk team setup screen now displays the Team Members label correctly when automatic assignment is enabled. This small visual fix makes the configuration form look cleaner and easier to read for administrators.
Original PR description
Steps to reproduce: - install helpdesk - under configuration, click on helpdesk teams - In helpdesk teams form view enable automatic assignment Issue: - under automatic assignment, the 'team members' label is not centered Solution: - By giving d-flex to the div tag of label the issue will be solved. task-3683976
Code cleanup and technical improvements
This update simplifies internal grouping logic used across several Odoo apps, reducing duplicated code and making future maintenance easier. Users should see the same grouping behavior in views and reports, with lower risk of inconsistencies between modules.
Original PR description
### [REF] *: use the default group_expand of fields.Selection The selection field already has a method for `group_expand` (which expands each selection value) called `_default_group_expand`. Unfortunately, it is undocumented and unknown. Use it if possible and remove any clones of it. ### [REF] core, *: remove order parameter of group_expand methods The order sent to group_expand is either None (groups on non-relational fields) or equal to the comodel _order. The only exception is when the order is reversed. To simplify the API, remove this parameter and instead reverse the result if the order is reversed. https://github.com/odoo/odoo/pull/139294
Point of Sale data handling has been reworked so records are linked more consistently with the back office structure. This makes the system easier to reuse in Self-Order flows and should simplify future changes across localized PoS features.
Original PR description
Refactoring of model operation in all Point of Sale modules. The aim is to facilitate access to the various records and enable the use of PoS classes in the Self-Order. Records are now linked as in the backend. This link is managed via field information from the backend (many2many, many2one...). Remapping of field names has also been removed, so that frontend variable names correspond to backend variable names. Example: - Avant order.product.name - Now: order_id.product_id.name Example of model usage: ``` const pos_order = this.pos.models["pos.order"].getAll(); const lineProducts = pos_order.lines.map((l) => l.product); ``` It's very important not to access any more services / dependencies specific to the Point of sale in the model classes, as these will be used outside the PoS. Part 1: https://github.com/odoo/enterprise/pull/51000
Miscellaneous changes
Task: 36213 Forward-Port-Of: odoo/enterprise#58767 Forward-Port-Of: odoo/enterprise#55068
Original PR description
Task: 36213 Forward-Port-Of: odoo/enterprise#58767 Forward-Port-Of: odoo/enterprise#55068
Currently, posting a message to discuss channels is done in two steps: first writing the last_interest_dt to the channel, then creating the message, second triggering the notify_thread to send the message to the followers. In the first step, the last_interest_dt will be directly sent to the client if it differs from the old value. So there is no need to send the message to the client if the last_interest_dt has not changed in the second step. Also, this can lead to a racing condition in the t
Original PR description
Currently, posting a message to discuss channels is done in two steps: first writing the last_interest_dt to the channel, then creating the message, second triggering the notify_thread to send the message to the followers. In the first step, the last_interest_dt will be directly sent to the client if it differs from the old value. So there is no need to send the message to the client if the last_interest_dt has not changed in the second step. Also, this can lead to a racing condition in the testing files. This commit removes the notif in the second step. Also, adapting the mock_models to the new behavior as the follow-up of https://github.com/odoo/odoo/pull/155569 https://github.com/odoo/odoo/pull/158134 Forward-Port-Of: odoo/enterprise#59130
The clipboard handler of the comments did not account properly for the pasting from the OS clipboard. Task: 3813759 Forward-Port-Of: odoo/enterprise#58827
Original PR description
The clipboard handler of the comments did not account properly for the pasting from the OS clipboard. Task: 3813759 Forward-Port-Of: odoo/enterprise#58827
There were a few problems reported with the KMD INF and VD reports. 1. The namespace of the VD (EC Sales) XML export was incorrect, causing the file not to be accepted on the autorities platform. This was fixed. 2. In the VD XML export, the numbers were floats, while they had to be integers for the platform to accept the file. This was fixed. 3. Customer credit notes were not taken into account in the KMD INF report. This was a small issue in the SQL query, were we only considered lines wit
Original PR description
There were a few problems reported with the KMD INF and VD reports. 1. The namespace of the VD (EC Sales) XML export was incorrect, causing the file not to be accepted on the autorities platform. This was fixed. 2. In the VD XML export, the numbers were floats, while they had to be integers for the platform to accept the file. This was fixed. 3. Customer credit notes were not taken into account in the KMD INF report. This was a small issue in the SQL query, were we only considered lines with a tax balance > 0, where for credit notes it is < 0. opw-3758841 Forward-Port-Of: odoo/enterprise#58897
In Approvals, you can create Approval Request where you select Products (in demo data : Create RFQ). When you do that, on the request creation itself, you'll be able to pick products and add it in lines. There's a column description, but that column is not populated correctly, it's just a copy of the name. It should be the description from the product, purchase tab. TaskID: 3794627 Forward-Port-Of: odoo/enterprise#58909 Forward-Port-Of: odoo/enterprise#58492
Original PR description
In Approvals, you can create Approval Request where you select Products (in demo data : Create RFQ). When you do that, on the request creation itself, you'll be able to pick products and add it in lines. There's a column description, but that column is not populated correctly, it's just a copy of the name. It should be the description from the product, purchase tab. TaskID: 3794627 Forward-Port-Of: odoo/enterprise#58909 Forward-Port-Of: odoo/enterprise#58492
The values of blocks F and G have been changed on the sweedish tax report on the `l10n_se` module. This commit adapt the tests accordingly. Forward-Port-Of: odoo/enterprise#58870 Forward-Port-Of: odoo/enterprise#58508
Original PR description
The values of blocks F and G have been changed on the sweedish tax report on the `l10n_se` module. This commit adapt the tests accordingly. Forward-Port-Of: odoo/enterprise#58870 Forward-Port-Of: odoo/enterprise#58508
One of our future bank synchronization provider, bLink, is asking us to make sure that customers can only connect to their banks if they have a 2FA to login on their database. As we don't want to enforce this behavior for other providers, we decide to send the value when we open the bank selection view. If a customer tries to connect with a bLink institution, an error will be sent by Odoo Fin proxy telling that connection with bLink need a 2FA enabled. NB: This commit is only for sending th
Original PR description
One of our future bank synchronization provider, bLink, is asking us to make sure that customers can only connect to their banks if they have a 2FA to login on their database. As we don't want to enforce this behavior for other providers, we decide to send the value when we open the bank selection view. If a customer tries to connect with a bLink institution, an error will be sent by Odoo Fin proxy telling that connection with bLink need a 2FA enabled. NB: This commit is only for sending the info when opening the iframe, all the logic is handled by Odoo Fin. task-id: 3637581 Forward-Port-Of: odoo/enterprise#58941 Forward-Port-Of: odoo/enterprise#56582
When a user reads an article from the frontend view of Knowledge and clicks on the "Sign in" button to sign in: internal users will be redirected to the Odoo backend while portal users will be redirected to the `/my` page. The current redirection process is confusing because users may lose track of the article they were reading. If people re-open Knowledge after being redirected, they may no find the article they were reading as it could be hidden in the sidebar. When people click on the "
Original PR description
When a user reads an article from the frontend view of Knowledge and clicks on the "Sign in" button to sign in: internal users will be redirected to the Odoo backend while portal users will be…
When a user reads an article from the frontend view of Knowledge and clicks on the "Sign in" button to sign in: internal users will be redirected to the Odoo backend while portal users will be redirected to the `/my` page. The current redirection process is confusing because users may lose track of the article they were reading. If people re-open Knowledge after being redirected, they may no find the article they were reading as it could be hidden in the sidebar. When people click on the "Sign in" button from Knowledge, we assume that they probably wanted to edit the article, change the permissions, add new members, access their own workspace, etc. So, we will now redirect the user to the article they were reading after they sign in. With that change, portal users can still access the '/my' page from Knowledge by clicking on the home icon of the sidebar and internal users can view all apps of the backend by clicking on the home button of the Odoo navbar. task-3776350 Forward-Port-Of: odoo/enterprise#57972
Since [1], it's now possible to set a display name on a client action, but a fallback to the action's name was also added. The issue with this, is that the action's name is a very technical one, and we don't want to display it to the user. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe Forward-Port-Of: odoo/enterprise#59028
Original PR description
Since [1], it's now possible to set a display name on a client action, but a fallback to the action's name was also added. The issue with this, is that the action's name is a very technical one, and we don't want to display it to the user. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe Forward-Port-Of: odoo/enterprise#59028
Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed. opw-3700809 Forward-Port-Of: odoo/enterprise#59015
Original PR description
Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed. opw-3700809 Forward-Port-Of: odoo/enterprise#59015
Add an userError to prevent the user selecting quantity quality check Type with manufacturing operation types. opw-3770822 Forward-Port-Of: odoo/enterprise#58152 Forward-Port-Of: odoo/enterprise#57802
Original PR description
Add an userError to prevent the user selecting quantity quality check Type with manufacturing operation types. opw-3770822 Forward-Port-Of: odoo/enterprise#58152 Forward-Port-Of: odoo/enterprise#57802
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company - In Accounting settings, run the automatic currency rates service ([PE] SUNAT) - Create a product: (e.g. Product X) * Sales Price: 990.00 * Withhold code: Arrendamiento de bienes muebles * Withhold Percentage: 10.00 - Create an invoice: * Customer: [a Peruvian contact] (e.g. Comercial Co
Original PR description
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company - In…
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company
- In Accounting settings, run the automatic currency rates service ([PE] SUNAT)
- Create a product: (e.g. Product X)
* Sales Price: 990.00
* Withhold code: Arrendamiento de bienes muebles
* Withhold Percentage: 10.00
- Create an invoice:
* Customer: [a Peruvian contact] (e.g. Comercial Constructora los Patitos S.A.)
* Operation Type: [1001] Operation Subject to Detraction
* Payment terms: End of Following Month
* Journal in: USD
* Invoice Lines:
- Product: Product X
- Account: 7012100 Merchandise - Merchandise - Local sale - Third parties
- Price: 990.00
- Taxes: 18%
- EDI Affect. Reason: Taxed- Onerous Operation
- Confirm the invoice
- Process to EDI service
Issue:
The remaining amount after deducting the withholding is not correct in the generated EDI document.
The total is 990.00 + Taxes (18%) = 1168.20
The withholding is 1168.20 * 10% = 116.82
The remaining amount should be 1168.20 - 116.82 = 1051,38
However, the remaining amount set in the EDI document is 1052,20, which is not correct.
Cause:
The rounding used to compute the withholding amounts are not correct.
The amount in the selected currency should contain 2 decimal digits (precision_rounding should be 0.01, instead of 2).
Also, the Detraction amount should be declared in PEN currency in the EDI document and should not contain the decimal part (precision_rounding should be 1, instead of 2).
opw-3747620
Forward-Port-Of: odoo/enterprise#58944
Forward-Port-Of: odoo/enterprise#58473This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/enterprise#58992 Forward-Port-Of: odoo/enterprise#42790
Original PR description
This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/enterprise#58992 Forward-Port-Of: odoo/enterprise#42790
Before this commit assets from `website_sale_stock_renting` was loaded before `website_sale_renting` because there was prepend in parent module assets PR: https://github.com/odoo/enterprise/pull/49610 So method `_getInvalidMessage` written in child(`website_sale_stock_renting`) get overridden by parent module(`website_sale_renting`) This commit add `website_sale_stock_renting` module assets after `website_sale_renting` module assets in order to execute method in proper order opw-3679735 F
Original PR description
Before this commit assets from `website_sale_stock_renting` was loaded before `website_sale_renting` because there was prepend in parent module assets PR: https://github.com/odoo/enterprise/pull/49610 So method `_getInvalidMessage` written in child(`website_sale_stock_renting`) get overridden by parent module(`website_sale_renting`) This commit add `website_sale_stock_renting` module assets after `website_sale_renting` module assets in order to execute method in proper order opw-3679735 Forward-Port-Of: odoo/enterprise#58947 Forward-Port-Of: odoo/enterprise#58639
Steps to reproduce: - Install both ups_rest and ups legacy - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: in ups legacy credential fields are only accessible to the admin sudo is used on the request on the new app they aren't hidden so no sudo was added on the request Fix: it makes sense for me to keep the credentials hidden for the new module and use sudo on the request opw-3771840 Forward-Port-Of: odoo/en
Original PR description
Steps to reproduce: - Install both ups_rest and ups legacy - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: in ups legacy credential fields are only accessible to the admin sudo is used on the request on the new app they aren't hidden so no sudo was added on the request Fix: it makes sense for me to keep the credentials hidden for the new module and use sudo on the request opw-3771840 Forward-Port-Of: odoo/enterprise#58895
Since `account.full.reconcile` doesn't have a `display_name`, the header of the group is not displayed nicely. By grouping per `matching_number` instead, we can have a nicer display. Forward-Port-Of: odoo/enterprise#58840
Original PR description
Since `account.full.reconcile` doesn't have a `display_name`, the header of the group is not displayed nicely. By grouping per `matching_number` instead, we can have a nicer display. Forward-Port-Of: odoo/enterprise#58840
Steps to reproduce the problem: - create a product and list it on eBay - uncheck the sell on eBay setting for the product. Don't archive it - create a second product and list it to the existing listing in eBay - sync an order with that product ==> First created product is shown in the sale order The eBay_id stays on the product, even after unchecking the setting. This seems to be voluntary as when relisting a product, after some time without selling it on eBay for instance, this id will t
Original PR description
Steps to reproduce the problem: - create a product and list it on eBay - uncheck the sell on eBay setting for the product. Don't archive it - create a second product and list it to the existing listing in eBay - sync an order with that product ==> First created product is shown in the sale order The eBay_id stays on the product, even after unchecking the setting. This seems to be voluntary as when relisting a product, after some time without selling it on eBay for instance, this id will then be used. We now take the first product that is checked as used in eBay. opw-3503924 Forward-Port-Of: odoo/enterprise#58852
Currently, we have some code repeating in SixDriver, WorldlineDriver_L and WOrldlineDriver_W. The goal of this PR is to move this code to a parent class for easier maintenance and better code strcture Additionally, it applies the code to every ctypes dependant terminal driver, adding some features like "smart sleep" or rejecting double request processing when the terminal is busy for every single of them task-3707945 Forward-Port-Of: odoo/enterprise#58877 Forward-Port-Of: odoo/enterpri
Original PR description
Currently, we have some code repeating in SixDriver, WorldlineDriver_L and WOrldlineDriver_W. The goal of this PR is to move this code to a parent class for easier maintenance and better code strcture Additionally, it applies the code to every ctypes dependant terminal driver, adding some features like "smart sleep" or rejecting double request processing when the terminal is busy for every single of them task-3707945 Forward-Port-Of: odoo/enterprise#58877 Forward-Port-Of: odoo/enterprise#57064
Forward-Port-Of: odoo/enterprise#58846
Original PR description
Forward-Port-Of: odoo/enterprise#58846
Before this commit, when toggling the Signing Order option in a template with more than one sign role, the signer emails would disappear (only their names would be kept). After this commit, by adding the context variable show_email as true in the Send action, the signers emails no longer disappear. This will make the emails labels persist after performing onchange calls in the user interface. task-3659895 Forward-Port-Of: odoo/enterprise#58175
Original PR description
Before this commit, when toggling the Signing Order option in a template with more than one sign role, the signer emails would disappear (only their names would be kept). After this commit, by adding the context variable show_email as true in the Send action, the signers emails no longer disappear. This will make the emails labels persist after performing onchange calls in the user interface. task-3659895 Forward-Port-Of: odoo/enterprise#58175
5 changes
Enhancements to existing features
This update improves the error messages displayed when issues occur with Argentine electronic invoicing (EDI) processing. Users will now receive clearer, more helpful error messages when problems arise, making it easier to understand and resolve issues with their electronic invoice submissions.
Original PR description
Task: 36213 Forward-Port-Of: odoo/enterprise#55068
Resolved issues and error corrections
Fixed an issue in the Journal Report where certain columns, particularly the Invoice Date column, were not appearing in the report after upgrading to version 17.0. The fix reorganizes how columns are arranged so that all columns display properly in the correct order.
Original PR description
This PR addresses an issue with the Journal Report where columns positioned after 'additional_col_1' or 'additional_col_2' were not being displayed. Furthermore, in databases migrated to version…
This PR addresses an issue with the Journal Report where columns positioned after 'additional_col_1' or 'additional_col_2' were not being displayed. Furthermore, in databases migrated to version 17.0, a new record 'invoice_date' is inserted into the account_report_column table, but the corresponding 'Invoice Date' column is not visible in the journal report.
### Current situation:
account_report_column
```
aksi_test=# select id, name, sequence , report_id, expression_label from account_report_column where report_id = 17 order by id;
id | name | sequence | report_id | expression_label
----+---------------------------+----------+-----------+------------------
63 | {"en_US": "Account"} | | 17 | account
64 | {"en_US": "Label"} | | 17 | label
65 | {"en_US": "Debit"} | | 17 | debit
66 | {"en_US": "Credit"} | | 17 | credit
67 | {"en_US": ""} | | 17 | additional_col_1
68 | {"en_US": ""} | | 17 | additional_col_2
85 | {"en_US": "Invoice Date"} | | 17 | invoice_date
(7 rows)
```
### After Fix:
Journal Report
Users can now successfully export custom composite reports to Excel format. The fix resolves an issue where exporting would fail due to inconsistent data handling in company options. The system now ensures all company data is properly formatted and passed through the export process.
Original PR description
The aim of this commit is to allow the user to make xslx export with custom composite report. Context: The customer made a custom report in which he is calling some other reports. Before this commit:…
The aim of this commit is to allow the user to make xslx export with custom composite report. Context: The customer made a custom report in which he is calling some other reports. Before this commit: Exporting the report would results in a traceback. This happenned because a keyError is raise when trying to access the `companies` key which isn't present in the dictionnary. The initializers for the `companies` key weren't consistent with each other. In some initializer, the `currency_id` key was set. In other, it wasn't. In method `_add_options_xlsx_sheet` only the exact same options were kept before pursuing the operations. As the `currency_id` wasn't set for all the options, it was ignored. After this commit: The file can be exported with success. To solve the `currency_id` key difference issue and prevent it to happen again, we centralize the place where the dictionnaries are created to be sure the exact same keys are set for the `companies` options regardless of how those companies are chosen. opw-3802602
The Swedish tax report has been updated with new values for specific report sections (blocks F and G). This change updates the corresponding test cases to ensure they accurately validate the new report calculations. This ensures the tax reporting functionality continues to work correctly with the updated report structure.
Original PR description
The values of blocks F and G have been changed on the sweedish tax report on the `l10n_se` module. This commit adapt the tests accordingly. Forward-Port-Of: odoo/enterprise#58870 Forward-Port-Of: odoo/enterprise#58508
This update refreshes the X (formerly Twitter) logo and branding colors throughout the social media integration module. The changes ensure that Odoo's social media features display the current X branding, keeping the platform aligned with the rebranded service.
Original PR description
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59056 Forward-Port-Of: odoo/enterprise#53644