Daily updates from Odoo
Friday, March 22, 2024
62 changes · saas-17.2
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