Daily updates from Odoo
Wednesday, February 5, 2025
53 changes · 18.0
Enhancements to existing features
Point of Sale customer searches now look for exact matches across key customer details instead of relying on fuzzy scoring. This makes search results more predictable and helps cashiers find the right customer faster, reducing checkout mistakes.
Original PR description
Before this commit, we was using fuzzy search which was creating a score for each partner and then sorting the partners based on that score. This was causing error in search result. Now we use exact match search which will search for the exact match of the search string in the partner name, phone, mobile, email, street, city, state, country, zip, vat, and barcode. taskId: 4517586
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
Fixes a problem where one failed scheduled message could repeatedly stop all other scheduled messages from being sent. Failed scheduled messages now notify their author and are removed, and messages tied to deleted records are cleaned up automatically.
Original PR description
Purpose: -------- Currently, when posting a scheduled message failed due to an error, the cron interrupts and will attempt to resend the message on each of its subsequent runs and fail again, preventing any scheduled message to be posted. This commit changes the cron behavior to catch any exceptions raised during message posting, notify the author of the message about the failure, and delete the failed scheduled message. This prevents infinite retry attempts. The notification to the author of the scheduled message contains the content of the scheduled message. The rationale is that the posting might fail because the user does not have access to the record it will be posted on anymore, and won't be able to see the scheduled message again. The scheduled messages will now be unlinked when unlinking the record on which they are scheduled. Task-4531402
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
This update refreshes Odoo's spreadsheet component with several bug fixes. Users should see more reliable formulas, cleaner rendering of hidden headers, borders, and boxes, plus fewer display issues in unusual spreadsheet views.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/90f2af4ff [REL] 18.0.14 Task: 0 https://github.com/odoo/o-spreadsheet/commit/3590a49ee [FIX] formulas: accept simple…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/90f2af4ff [REL] 18.0.14 Task: 0 https://github.com/odoo/o-spreadsheet/commit/3590a49ee [FIX] formulas: accept simple values on search range for lookup formulas Task: 4543381 https://github.com/odoo/o-spreadsheet/commit/48e368c47 [FIX] Rendering: Skip hidden headers Task: 4535794 https://github.com/odoo/o-spreadsheet/commit/fc0aa2a66 [FIX] SheetView: avoid some array allocation https://github.com/odoo/o-spreadsheet/commit/4bcac65b0 [FIX] SheetView: remove useless/costy calls to Object.x https://github.com/odoo/o-spreadsheet/commit/a1ab57a4e [FIX] Renderer: Do not draw if no canvas Task: 4535794 https://github.com/odoo/o-spreadsheet/commit/95266d1ab [FIX] SheetView: Fix viewports with negative dimensions Task: 4535794 https://github.com/odoo/o-spreadsheet/commit/8c4ee5d8f [FIX] Borders: Fix border continuity Task: 4523890 https://github.com/odoo/o-spreadsheet/commit/e1ffbf678 [FIX] renderer: Re-fix box rendering Task: 4526742 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
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.
Portal users can now select how long a newly created API key remains valid instead of always being limited to one day. Available durations follow the user's group settings, giving administrators control over the maximum validity period for portal users.
Original PR description
Before this commit, for a portal user, the creation of an API key will always be valid for one day. This commit adds the option of selecting a period for which the API key will be valid. The periods proposed take into account of the user's group. Consequently, in the case of a portal user, the administrator must enter a maximum number of days for the portal group (the `api_key_duration` field in the `res.groups` model). opw-4414586
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
Point of Sale order reports now count products correctly when a product belongs to more than one POS category. This prevents duplicate report lines and avoids overstating quantities or sales activity for affected orders.
Original PR description
**Description:** - If a product belongs to multiple POS categories and is added to a single order, the order report may show duplicate lines based on the number of categories the product is assigned…
**Description:** - If a product belongs to multiple POS categories and is added to a single order, the order report may show duplicate lines based on the number of categories the product is assigned to. **Steps to reproduce:** - Install the 'point_of_sale' module. - Create a product and assign it to multiple POS categories. - Open the POS interface, add that product and validate the order. - Check the order report for this order—the lines will be duplicated based on the number of POS categories the product belongs to. **Screenshots for clarity:** - Product configuration  - Add the product from any of the category.  **Before FIX** - Reporting view for **Orders** you may notice that the product is already double `2` even though we have added single quantity.  - Double line created with same `id` for both the categories.  **After FIX** - Reporting view for **Orders**  - Single line with same product quantity added on the order line.  OPW - 4478667 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
Coupon discounts now calculate correctly when product prices already include tax. This prevents sales orders and point-of-sale orders from showing an incorrect remaining total when a coupon should fully discount the purchase.
Original PR description
Steps to reproduce: - Configure a product with a price of 229. - Assign a tax to the product with the 'Included in Price' option enabled under advanced settings. - Create a new Discount Program with the program type set to 'Discount Code'. - Set a discount of per order, using the same tax as the product. - Create a sales order with the configured product. - Apply the coupon code to the order. Issue: - The total amount of the sales order does not reduce to 0 as expected. - The computed coupon discount amount is incorrect. Cause: - The case for handling tax-included pricing was not taken into consideration when calculating the discount. Fix: - Use the sum of line.price_total when tax-included pricing is applied to accurately compute the price_unit of the reward. opw-4486030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
This fixes onboarding tour drag-and-drop actions when the target is inside an embedded page such as an iframe. It helps guided setup flows, including signing-related tours, behave reliably by detecting drops in the right page context and positioning drop zones correctly.
Original PR description
Before this commit, only pointerup was listened and was on the global document. Now, the event is listened on the ownerDocument of the element. Like that, if the element is inside an iframe, it will be correctly listened. The "drop" is also added to the listened events, because sign doesn't use the draggable hook of owl, instead it uses the vanilla drag and drop system of javascript. The dropzone shown during an onboarding tour is also fixed and takes into account the offset of the iframe in the top document. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale Restaurant module now handles Arabic language settings without crashing when dates are formatted. This keeps restaurant operations running smoothly for users working in Arabic by ensuring compatible date digits are used behind the scenes.
Original PR description
When the Arabic language was selected, the PoS Restaurant module would error due to date formatting using Arabic numerals. This commit forces Latin digits in the date format to prevent the error. opw-4544010 --- 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 .
Manufacturing planning now accounts for existing stock and lead times when calculating component demand. This prevents overestimating needed components and improves replenishment timing when products have bills of materials, starting quantities, or maximum replenishment limits.
Original PR description
Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see https://github.com/odoo/enterprise/pull/70232 Fix: Subtract the starting qty from the indirect demand qty for the corresponding subproduct. This is to make sure that the real `subproduct_indirect_demand` is compared to the 'ratioed' `replenish_qty` of the subproduct when selecting the date to use. task 4381021
This fix prevents crashes when migrated document actions are run after upgrading to Odoo 18. It makes accounting document actions handle migrated journal references correctly, so users can continue processing documents without interruption.
Original PR description
After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. While the method originally supported only recordsets, it's actually convenient to support `int`s here to avoid browse in the action (more readable and more accessible to end-users). opw-4453249
This fix ensures subscription records include invoices linked directly through subscription lines, even when no invoice is found through the original sales order line lookup. This helps users and automated processes see complete invoice information across company access scenarios.
Original PR description
Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the invoice. Solution: Invoice by origin_order_id should come from the result of the query + move_by_origin
This fixes demand calculations in manufacturing planning for warehouses that use multi-step delivery flows. It ensures the planning view counts the right delivery movement so businesses see more reliable actual demand and can plan production more accurately.
Original PR description
If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137
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
Fixed an error that could occur when inserting a CRM graph view into a spreadsheet. The spreadsheet now correctly uses the current context, preventing failures for users working with sales team pipeline charts.
Original PR description
Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397
Copying a previous week in Planning now creates the expected number of shifts when the employee has time off in the new week. This prevents duplicate shift entries on available days, keeping schedules clearer and reducing manual cleanup for planners.
Original PR description
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and…
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two copied slots instead of just one. Fix: ------------------- Currently, the _merge_slots_values() method is called when we use copy previous week on a forecasted slot (> 24 hours), which is the case here. This method takes work intervals and unavailabilites in parameters, and returns merged slots by taking into account the unavailabilites. To fix the issue mentioned above, we removed a condition that only allows slots to be merged if their combination creates a forecasted slot (> 24 hours). But we argue that we should also be able to merge smaller slots (< 24 hours). task-4368919 version-18.0
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-4497656Miscellaneous 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
`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