Wednesday, February 5, 2025
39 changes · 18.0
Enhancements to existing features
Preparation tickets in Point of Sale now show ordered products and notes in a larger text size. This makes kitchen or preparation staff tickets easier to read, helping reduce mistakes and speed up order handling.
Original PR description
This commit increases the text size of the ordered product and notes on the preparation ticket, ensuring better readability. task-4535901
Resolved issues and error corrections
Fixes a visual issue in the website editor where resizing page elements could briefly make the scrollbar jump or flicker. This makes editing pages feel smoother and avoids distracting layout changes during routine website customization.
Original PR description
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This…
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This happens because when we start resizing, a `div` is added at the end of the body, with a `height` set at `100%`. It was added in commit [2], when the website was moved in an iframe, in order for the mouse events to not be absorbed by it. The scroll bar flicker is therefore due to the addition of this `div` in the body, which makes the page bigger. Before commit [1], the body had its `overflow` property set to `hidden`, which is why adding the `div` had no visual effect, since it was hidden. (Note that the body has a fixed size, which is the size of the viewport with no overflow.) But with commit [1], this property has been removed, making the `div` appear at the bottom of the page. To fix this issue, we could simply set this `div` height to `0px` or its `top` position to 0, so it would never overflow the body. But in fact, it appears that this `div` is simply not necessary anymore since commit [3], which restored the overlay computation. This commit therefore removes the handler in charge of adding this `div` when we start resizing, as it is not needed anymore. [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e [2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af [3]: https://github.com/odoo/odoo/commit/2ae4e6434112a676c1cfa100e88fd756fe17f000 task-4190506
Miscellaneous changes
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
Original PR description
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
When a refused applicant is restored, the referral page now shows them as ongoing instead of incorrectly marking them as not hired. This keeps recruitment and referral information aligned for users reviewing applicant progress.
Original PR description
Description of the issue/feature this PR addresses: The `reset_applicant` method previously did not reset the `referral_state` to `'progress'`, causing the referral page to incorrectly display the applicant as "not hired" even when their actual state was ongoing. This commit explicitly sets `referral_state` to `'progress'` to ensure proper state management when an applicant is restored. opw-4523156 Related commit: f48ae97c2cadcdc085d32be25be365fdbb5605ef Current behavior before PR: Refuse an applicant and restore it, go to the referral app, the state will be displayed as not hired instead of ongoing Desired behavior after PR is merged: It should display as ongoing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now prepares its synchronization process as soon as it starts, before contacting the server. This helps avoid startup timing issues and makes request handling more reliable for cashiers and stores.
Original PR description
Initialize the synchronization class at startup of the PoS before making any request to the server. This will ensure that the synchronization class is ready to handle the requests.
This change prevents an automated test tool from opening the Attendance kiosk menu, which was causing test failures. It helps keep routine quality checks reliable without changing normal user workflows.
Original PR description
Fixing Click All test broken since 662081ca3ad31170961eaf384f8aa2311d39f086
Product pages now limit unusually tall images so they do not make the page excessively long. This keeps shopping pages easier to browse when merchants upload narrow, very tall product photos.
Original PR description
In commit[1] we implemented improvement for the images on the product page which makes the single image fill the total width of the column. While it was fitting most of cases, uploading an image with particular aspect ratio w/ a height significantly longer than the width will render a very long image, extending the page. This fix constraints the height to a maximum of 75vh, avoiding extra long images. Note: the fix is done in CSS to be stable friendly, in master the goal will be to implement a dropdown allowing precise aspect ratio for single images. This will require improvement on the way the carousel / grid render it's single image. This will likely be handled in the e-commerce redesign (task-4252024) [1]: odoo/odoo@da76f10558ea240a5f1b539cd4ce3ed3fc6628ab opw-4458614 task-4522225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where resequencing a payment's journal entry changed the journal entry number but left the related payment with the old reference. Payments and their accounting entries now stay consistently named, reducing confusion during reconciliation and audits.
Original PR description
- Configure an outstanding receipt account (e.g., Bank) for the Bank journal. - Create an invoice and process the payment. When attempting to resequence the journal entry corresponding to the `account.payment`, the journal entry is renamed, but the `account.payment` record is not updated accordingly. https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892 made the journal entry optional for payments, which broke the resequence. opw-4437481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The course website test setup now avoids confusing demo courses with the intended test course. This helps keep automated checks accurate and reduces the chance of unnoticed issues in the course experience.
Original PR description
The slide course member tour tests use a channel called `Basics of Gardening - Test`. When the course is completed, clicking on `End course` will redirect the user to the courses home page. Since there is already a course (from demo data) called `Basics of Gardening`, the selector in the tour test actually selects this as the first match not the test course and the tour continues with the wrong course. It doesn't crash because both demo and test courses are public, so it's possible for demo and portal users to access them anyway and add/update a comment is done on the demo course. By this commit: - Demo data is removed in the tests to ensure that there is no collision between demo data and test data. - Since there are no predefined messages in the test data (the tour flow relied on the demo data messages before), the `update` does not happen in the tour without demo data. Some extra steps are also added to check the update message .
The mobility budget field is now limited to Belgian employee contracts instead of appearing on every contract when the feature is installed. This reduces confusion for users working with contracts outside Belgium and keeps country-specific payroll information relevant.
Original PR description
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227
The Planning Gantt progress bar now shows flexible employees' expected hours down to the minute instead of rounding to whole hours. This prevents schedules such as 42 hours 30 minutes per week from appearing as only 42 hours, giving managers a more accurate view of planned capacity.
Original PR description
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: ------------------- 1. Create an employee with flexible hours ex. 42:30h per week (8:30h per day) 2. Create a shift for the same employee on planning. 3. In the gantt view, when setting the date range to a week, the expected working hours of the period is showing 42h instead of 42:30h task-id: 4506633
This fixes an automated walkthrough in the Sign app so it works correctly with the updated tour system. It helps ensure the document signing setup flow can be reliably tested, reducing the risk of issues reaching users.
Original PR description
Fix the drag_and_drop run of sign_tour to fit in the new tour system.
This update fixes an issue that could prevent Chilean electronic invoicing point-of-sale orders from validating and syncing correctly. Businesses using this localization should see fewer interruptions when processing POS orders.
Original PR description
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705
The Documents control panel now keeps its action buttons usable and neatly displayed on narrow screens and mobile devices. This prevents awkward button resizing while ensuring users can still access all available actions.
Original PR description
When you reduce the screen width or view the page on devices with small screens, the control panel button group rearranges itself in an unsightly way (e.g. excessive button height). For mobile devices, we use overflow auto on the action btns of the panel. Then they keep their aspects and are still accessible to users. FW-PORT until 18.1 task-4471881
This fix prevents scheduled Dutch SBR status checks from crashing after a prior certificate handling change. Businesses using the Dutch reporting flow should see more reliable automated status updates without manual intervention.
Original PR description
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435
This update fixes an automated test issue affecting the restaurant preparation display. It helps keep the restaurant workflow validation reliable and prevents false failures in the release checks.
Original PR description
Fix runbot error: 113710
Fixed an issue that could cause Planning pivot data to fail when inserted into a spreadsheet. This improves reliability for users exporting planning information, especially when some expected workload fields are unavailable.
Original PR description
Steps to reproduce: ------- - Install the `project_timesheet_forecast` module. - Open Planning > Pivot View. - Click on "Insert in Spreadsheet." - Confirm the action. Issue: --------- While inserting…
Steps to reproduce:
-------
- Install the `project_timesheet_forecast` module.
- Open Planning > Pivot View.
- Click on "Insert in Spreadsheet."
- Confirm the action.
Issue:
---------
While inserting into the spreadsheet, the readgroup result does not have `effective_hours` and `percentage_hours`,
which causes a traceback.
EX:
[{'__count': 6, 'allocated_hours_sum_id': 50.0, 'effective_hours_sum_id': 0.0,
percentage_hours_sum_id': 0.0, '__domain': ['&', ('start_datetime', '!=', False),
('end_datetime', '!=', False)]}]
Root Cause:
----------------------
The `read_group` result does not always contain the expected key, causing a traceback when accessed.
Fix:
--------
Used a getter method to safely retrieve the value. If the key is missing, it returns `None` instead
of raising an error.
Example:
--------------
temp = {'a': 1}
temp['b'] -> tracrback
temp.get('b') -> None
ticket-4497656`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple
Original PR description
`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple DBs post upgrade. Since this is a new field the value is not filled in some cases. It is also possible that due to misconfiguration the value is set to something other than `official`. In this patch we propose to fetch the information only for modules that are already marked as `industry`. opw-4516992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195540
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196430 Forward-Port-Of: odoo/odoo#190938
Original PR description
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196430 Forward-Port-Of: odoo/odoo#190938
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
Original PR description
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#1948
Original PR description
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#194886
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
Original PR description
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 For
Original PR description
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 Forward-Port-Of: odoo/odoo#196360
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreak
Original PR description
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreakable()` function has been updated to ensure that nav items (tabs) are treated as non-splittable elements. This prevents the tab from being split when the Enter key is pressed. Additionally, a test case has been added to cover the scenarios outlined in [commit]( https://github.com/odoo/odoo/commit/439e491608bab07f3f001d38b7774040a4b18980) as well to ensure the fix is effective. task-4316648 Forward-Port-Of: odoo/odoo#196159 Forward-Port-Of: odoo/odoo#193239
When we display more than one chart in the mobile view, the height of the elements is being adjusted to fill 100%, which in some cases causes a size that makes it impossible to view the chart.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  cc @Tecnativa TT50972 ping @chienandalu @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196364 Forward-Port-Of: odoo/odoo#181335
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales. Steps to reproduce: --- - Install ``Sale_management`` and ``event`` module (without demo data) - Open ``Products`` in Sales > Delete ``Event Registration`` - Now upgrade ``event_sale`` module - The error appears in the log. Traceback: --- ``` Exception: Cannot update missing record 'event_product.product_product_event' ParseError: w
Original PR description
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales. Steps to reproduce: --- - Install…
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales.
Steps to reproduce:
---
- Install ``Sale_management`` and ``event`` module (without demo data)
- Open ``Products`` in Sales > Delete ``Event Registration``
- Now upgrade ``event_sale`` module
- The error appears in the log.
Traceback:
---
```
Exception: Cannot update missing record 'event_product.product_product_event'
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/event_sale/data/event_sale_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product">
<field name="invoice_policy">order</field>
</record>
```
This commit resolves the issue by preventing the creation of a product using ``forcecreate="False"``.
sentry-5731062091
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195433**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; - Update the product's `Quantity` to 1 at least; *The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.* - Update the field `Quantity` of components to: - **C1**: 1 unit - **C2**: 3 units -
Original PR description
**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; -…
**Steps to reproduce:**
- Create a storable product `P1` with the following BoM:
- Qty: 1 unit
- Components:
- C1, C2, C3: 3 units
- Create a MO to produce one unit of `P1`;
- Confirm the order;
- Update the product's `Quantity` to 1 at least;
*The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.*
- Update the field `Quantity` of components to:
- **C1**: 1 unit
- **C2**: 3 units
- **C3**: 4 units
___
**Issue:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less than the <ins>total needed</ins> value → highlights in green;
- **C2**: equal to the value → highlights in black;
- **C3**: higher than the value → highlights in orange.
___
**Expected:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less -> black;
- **C2**: equal -> green;
- **C3**: higher -> orange.
___
**Cause:**
Text decorations are based on a wrong logic by getting the quantities from wrong field. This field has been changed during an apocalypse.
https://github.com/odoo/odoo/blob/c43297435cfcaf560d5c952ac3c4a383a6f1dc28/addons/mrp/views/mrp_production_views.xml#L405-L406
___
**Fix:**
Reset good field to check quantities, inspired by Odoo 16 using the computed `should_consume_qty` value to check the consumption status:
https://github.com/odoo/odoo/blob/67c78b38e794333eae55758ad4610515df5c49d2/addons/mrp/views/mrp_production_views.xml#L342-L343
___
**Forward:**
To forward up to master.
Odoo 17 :
```
<field name="quantity" string="Quantity"
decoration-success="product_uom_qty - quantity > -0.0001 and product_uom_qty - quantity < 0.0001"
decoration-warning="quantity - product_uom_qty > 0.0001"
```
___
opw-4393156
opw-4391582
opw-4391600
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196291
Forward-Port-Of: odoo/odoo#190162Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196180 Forward-Port-Of: odoo/odoo#194014
Original PR description
Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196180 Forward-Port-Of: odoo/odoo#194014
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
Original PR description
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
This commit change a bit the behaviour of drag & drop feature in multiple account view. The main goal is to avoid users to drag and drop text in files drop zones. So now, if a user is dragging a text, we hide the files drop zones. Linked:https://github.com/odoo/enterprise/pull/76565 opw-4366605 Forward-Port-Of: odoo/odoo#193355
Original PR description
This commit change a bit the behaviour of drag & drop feature in multiple account view. The main goal is to avoid users to drag and drop text in files drop zones. So now, if a user is dragging a text, we hide the files drop zones. Linked:https://github.com/odoo/enterprise/pull/76565 opw-4366605 Forward-Port-Of: odoo/odoo#193355
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko)
Original PR description
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and…
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 HTTP/1.0 200 OK Server: Werkzeug/2.0.2 Python/3.11.11 Etag: "1710849406-32964-706485214" Expires: Tue, 28 Jan 2025 13:18:36 GMT Content-Disposition: inline; filename=Lato-Bla-webfont.woff Content-Type: application/font-woff Date: Tue, 28 Jan 2025 13:18:36 GMT Last-Modified: Tue, 19 Mar 2024 11:56:46 GMT Content-Length: 32964 Cache-Control: no-cache, max-age=0 Accept-Ranges: bytes ``` The second request from the footer is ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Cache-Control: no-cache Pragma: no-cache If-Modified-Since: Tue, 19 Mar 2024 11:56:46 GMT User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip If-None-Match: "1710849406-32964-706485214" Accept: */* Accept-Language: en-US,* HTTP/1.0 304 NOT MODIFIED Server: Werkzeug/2.0.2 Python/3.11.11 Date: Tue, 28 Jan 2025 13:18:36 GMT Accept-Ranges: bytes Content-Disposition: inline; filename=Lato-Bla-webfont.woff Cache-Control: no-cache, max-age=0 Expires: Tue, 28 Jan 2025 13:18:36 GMT Etag: "1710849406-32964-706485214" ``` When running wkhtmltopdf manually, we obtain the following output: ``` Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This might be an indication of an iframe taking too long to load. ``` This indicates that wkhtmltopdf is not handling the cache headers correctly and fails to recognize the fact that it should reuse the previously received version of the file. Solution ======== In production, odoo should run behind a reverse proxy that handles static files, and the debug assets mode should not be used. Nevertheless, since wkhtmltopdf misinterprets cache headers, we simply remove them in case opw-4413445 Forward-Port-Of: odoo/odoo#195826
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78223 Forward-Port-Of: odoo/enterprise#66033
Original PR description
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78223 Forward-Port-Of: odoo/enterprise#66033
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
Original PR description
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78323 Forward-Port-Of: odoo/enterprise#56896
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
Original PR description
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
**How to reproduce:** - As Mitchel Admin, create an appointment type, keep it unpublished - Send an invite (with token) to Demo - Log in as Demo (User access level) - Book a meeting with your manager - You get a calendar event in your agenda - Try to open its form **Before this PR:** It gives access error because the user does not have permission to read the appointment type. **Technical reason:** The record rules only grant access if the appointment is scheduled based on resource
Original PR description
**How to reproduce:** - As Mitchel Admin, create an appointment type, keep it unpublished - Send an invite (with token) to Demo - Log in as Demo (User access level) - Book a meeting with your manager - You get a calendar event in your agenda - Try to open its form **Before this PR:** It gives access error because the user does not have permission to read the appointment type. **Technical reason:** The record rules only grant access if the appointment is scheduled based on resources or if the user is part of the staff. **After this PR:** Users will be able to access the appointment type because sudo will be added. Task-4526059 Forward-Port-Of: odoo/enterprise#78155
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#76565
Original PR description
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#76565
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Original PR description
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Forward-Port-Of: odoo/enterprise#78460
Original PR description
Forward-Port-Of: odoo/enterprise#78460