Tuesday, April 23, 2024
24 changes
3 changes
Enhancements to existing features
This change improves how planned hours are calculated for sale-related timesheet planning by removing a limiting filter. This helps businesses get a more complete view of expected work effort, supporting better planning and forecasting.
Original PR description
temp task-3857649
Users can now upload spreadsheet JSON files downloaded from Odoo and have them recognized as spreadsheet documents in the Documents app. This helps teams move spreadsheets from test or staging databases to production more easily, though replacing an existing document with such a file is still not supported.
Original PR description
In debug mode, you can download the spreadsheet json file from the spreadsheet itself with the menu File > Download as JSON In the Documents app however, try uploading the json file: => it's not recognized as a spreadsheet document. Advanced users such as our own business analysts or ourselves often download the spreadsheet files and re-upload it. One use case is to build a spreadsheet on a test/staging database, then upload the spreadsheet to the production server. Current limitation (to keep it simple): uploading such a file on an existing document doesn't work. Task: 3596641
Room users can now end an active booking directly from the room front-end display, making the room available again without deleting the booking record. Button labels, icons, colors, and remaining-time alignment were also refined to make booking actions clearer and easier to understand.
Original PR description
Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. This commit also rewords the "schedule booking" button to "Add a booking" and changes the "booked room" icon to not use the same as in the new button. Task-3792497
21 changes
Enhancements to existing features
This update improves the survey experience by reducing the width of survey question pages and print layouts to use half the screen size, matching previous improvements made to results pages. Font sizes for thank you messages and titles have been adjusted accordingly. Additionally, the live chat feature has been repositioned to prevent it from overlapping with survey navigation.
Original PR description
Reduce the survey questions page in every display mode and the print page display to be the half screen size. This is done to match the previous results page improvements. Also reducing the font size of the "Thank you" message and the print page questions and sections titles to best match the new half screen display. related odoo/odoo#152263 Task-3789479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed an issue in the PDF manager where special keyboard keys (Backspace, Space, and S) were triggering unintended functions instead of being recognized as search input. When users opened the command palette and tried to search for documents, pressing these keys would close the dialog instead of adding them to the search. This fix ensures these keys are properly handled as regular search characters.
Original PR description
Steps to reproduce 1. Select a PDF 2. From the Inspector click on the split button 3. Press Control+k (opens command palette) 4. Type s or press the space/backspace key 5. It closes the dialog Issue: Special hotkeys like "Backspace," "Space", and "S". Instead of being counted as regular characters during searches, they're being used for other functions, which is the default behavior of the useCommand. Fix: To fix this, we need to give these hotkeys more meaningful names than no dialog will close while searching. Task:3725189 Forward-Port-Of: odoo/enterprise#60143
Fixed an issue where applying an Analytic Filter to accounting reports would lose that filter when clicking on amounts to audit journal items. Now when auditing, the journal items remain filtered by the selected Analytic Filter, ensuring consistent data visibility and accurate financial reviews.
Original PR description
Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/152897 Forward-Port-Of: odoo/enterprise#60413 Forward-Port-Of: odoo/enterprise#55972
A bug in the spreadsheet list reinsertion dialog was treating user-entered numbers as text instead of actual numbers, causing the system to incorrectly add too many records. This fix ensures numbers are properly recognized as numbers, so the correct quantity of records are inserted when users reinitialize lists in spreadsheets.
Original PR description
## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#60923 Forward-Port-Of: odoo/enterprise#60642
The inventory adjustment buttons in the Barcode app were misaligned, with the -1/+1 buttons stacking vertically instead of appearing side-by-side. This fix corrects the button layout so they display properly on both desktop and mobile devices, improving the user interface and making the adjustment controls easier to use.
Original PR description
Before this commit, there was an issue with the line's buttons for the Inventory Adjustment in the Barcode app. The -1/+1 buttons were placed above/below each other instead of being on the same line,…
Before this commit, there was an issue with the line's buttons for the Inventory Adjustment in the Barcode app. The -1/+1 buttons were placed above/below each other instead of being on the same line, causing the edit button and the set button to be misplaced on the left. This commit fixes that, now these buttons will be placed correctly: - On the same height if there is only two buttons; - On two lines if there is four buttons. #### On Desktop - Before:  - After:  #### On mobile - Before:  - After:  Forward-Port-Of: odoo/enterprise#60769
This fix resolves a crash that occurred when users tried to group tasks by custom properties in the Gantt view. The system now prevents grouping by these properties until full support is available, preventing errors and improving stability. Users will no longer encounter crashes when attempting this operation.
Original PR description
### Issue: Grouping by a field.properties in the gantt view will give a traceback. ### Steps to reproduce: - Go on a project - Swap to the gantt view - Create a task in the calendar - Go back to the…
### Issue: Grouping by a field.properties in the gantt view will give a traceback. ### Steps to reproduce: - Go on a project - Swap to the gantt view - Create a task in the calendar - Go back to the list view, click on the task - Click on the wheel icon and add a property with a value - Go back to the project and its gantt view - Group by the property you have added to your task #### > traceback ### Cause of the Issue: The fields given in the groupby parameters are added to the read_specification of the "get_gantt_data" by the "_fetchData" method: https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/static/src/gantt_model.js#L635-L638 https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/static/src/gantt_model.js#L915-L920 However, as a fields.properties such as task_properties represent a dictionary of "pseudo field", the "field name" of a given property is of the form "task_properties.hashKey". The read_specification of the gantt view will therefore contain a "field_name" of that form. However, the ORM does not support to read such fields and the code will crash here: https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/models/models.py#L89 pseudo fields such as "task_properties.12c97bca432np24" are not expected to be read (this is not supported by the ORM). ### Fix: If we were to format field names in the "_fetchData" method we would be able to group records by fields.properties in the gantt view. However, the framework is not ready to plainly support this operation as for instance other tracebacks will be encountered when you drag and drop tasks in the gantt view after a group by a given property. It was therefore decided with the framework team to remove the fields.properties from the fields appearing in the groupedBy parameters of the gantt view until these other operations become supported. opw-3847341
This fix resolves a system error that occurred when posting closing entries for tax reports in Mexican companies. Users were experiencing a crash when trying to generate and post closing entries in the Generic Tax Report. The issue was caused by incorrect code inheritance in the Mexico tax reporting module, which has now been corrected.
Original PR description
With an MX company setup Accounting > Reporting > Tax Report Choose "Generic Tax Report", select last fiscal year period Generate Closing Entry (Tax accounts needs to be configured) Post the closing entry Traceback will raise AttributeError: 'account.report' object has no attribute 'action_periodic_vat_entries' It is caused by a wrong inheritance of the MX tax report opw-3846942
This update corrects how salary rules are processed in the UAE payroll module following a technical upgrade. The system was using outdated syntax that no longer works with the current version, causing salary calculations to fail. This fix ensures salary arrears and other payroll inputs are properly recognized and processed.
Original PR description
From 17.0 we switched from browsable object to dictionaries. This the following syntax is incorrect: result = inputs.SALARY_ARREARS Instead: result = 'SALARY_ARREARS' in inputs This commit fixes these errors
A typo in the Dutch financial reports module was causing the system to crash when processing partner address information. This fix corrects the error so that address data is properly handled without interruption.
Original PR description
In this [commit](https://github.com/odoo/enterprise/pull/60205/commits/c903c38952fdbc12af611b0f95c037b411291363), we introduced a small typo when processing the partner's address, resulting in a traceback. opw-3883752 Forward-Port-Of: odoo/enterprise#61215
This update fixes a bug where the search dropdown menu would expand the page height when placed in the website footer. The fix intelligently detects when the dropdown would overflow at the bottom of the page and either reduces its height or repositions it above the search bar to keep the page layout intact.
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag & drop a "inner content" search snippet into the footer. - Save the page. - Enter the letter "h" in the input. - Bug: The dropdown doesn't adapt properly and increases the height of the page. This commit fixes this issue by detecting if the searchbar menu overflows at the bottom of the page when it's open. If it does, we reduce its height, and if it still overflows despite the reduced height, then we move it above the search bar instead of below. task-3751401 Forward-Port-Of: odoo/odoo#156480
This fix ensures that when users click on accounting report amounts to audit journal items, any Analytic Filters they had applied remain active. Previously, these filters would be lost during the audit process, requiring users to reapply them. The system now maintains the filtered view throughout the auditing workflow.
Original PR description
Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. In order to do that, we extend the search function in the analytic mixin to allow searching on analytic account ids. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/enterprise/pull/55972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161273 Forward-Port-Of: odoo/odoo#152897
This fix resolves a crash that occurred in the Point of Sale self-ordering QR menu when the optional "sale_product_configurator" module was not installed. The system now properly checks if the optional product field exists before attempting to use it, allowing the self-ordering interface to work correctly regardless of which optional modules are enabled.
Original PR description
When the module "sale_product_configurator" is not installed, an AttributeError is raised Steps to reproduce: - Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module - Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface Cause: The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module opw-3850421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a bug where error messages displayed when editing job application forms would show "undefined" instead of the actual action name. The issue occurred when users tried to modify forms with required fields. The fix ensures the action name is properly set before displaying any validation error messages, making error alerts clearer and more helpful to users.
Original PR description
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system…
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing required fields. The bug manifests when an alert is triggered, and the action name becomes undefined due to the condition `this.modelCantChange` evaluating to `true` within the `willStart` function. Consequently, invoking `_super` results in the return of `willStart` without assigning a value to `currentActionName`. **After this commit:** Now, before returning the function, it sets a value for `currentActionName` and then proceeds with the necessary steps. This prevents the issue where an action was `undefined`. [1]: https://github.com/odoo/odoo/pull/120874/commits/491a25b2baaa415a9bc26340eba5a11af8605411 task-3680483 Forward-Port-Of: odoo/odoo#157501
Fixed an issue where receipts would fail to print and show an error when company logos or images couldn't be loaded (such as during offline printing). Now receipts will print successfully even if images fail to load, with an error message logged for troubleshooting purposes.
Original PR description
Current behavior: When trying to print a receipt offline, the image will not be loaded and you get a traceback. Now the receipt is printed, and an error is logged in the console if the images couldn't be loaded Steps to reproduce: - Add a logo to the company - Launch PoS - In the browser devtools network tab turn the connection down - Do an order, and try to print the receipt - You get a traceback and the receipt is not printed opw-3811663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an error that occurred when users cleared the start date field in the leave allocation form. The system was attempting to process accrual plans with an empty date, causing a technical error. Now the system properly validates that the date field has a value before processing.
Original PR description
**Issue**: On the Allocation form, Error when the `date_from` field is left blank. **Cause**: When deleting the `date_from` field, the onchange `_onchange_date_from` is triggered. It will call the `_process_accrual_plans` function and report an error as shown below: ``` first_level_start_date = allocation.date_from + get_timedelta(first_level.start_count, first_level.start_type) TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' ``` **Solution**: - Check the `date_from` condition before calling next function - Handle it only in the onchange because the `date_from` field is required --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when creating an alternative purchase order for a dropshipped product, the system properly links the resulting delivery to the original sales order. Previously, alternative purchase orders were not maintaining the necessary connection to the sales order's dropship delivery, which could cause confusion about order fulfillment status.
Original PR description
**Steps to reproduce the issue:**
- Create a storable product “P1”:
- Route: dropship
- Vendor: Azure interior and deco addict
- Create a sales order with one unit of P1
- Confirm the sales order
- A purchase order is generated with a dropship-picking (linked to the SO)
- Create an alternative PO and confirm it
**Problem:**
The alternative PO is linked to the SO, but the dropship-picking is not linked. This is because the procurement is not propagated when creating the alternative PO.
opw-3828132
Forward-Port-Of: odoo/odoo#162072
Forward-Port-Of: odoo/odoo#160354This update fixes a bug in the Point of Sale refund process where the system would crash when trying to process certain orders that weren't properly synced. The fix adds a safety check to verify an order exists before attempting to read its details, preventing refund failures and improving system reliability.
Original PR description
Prior to this commit, there were scenarios where sync orders did not contain an order, leading to a failure when reading its state. This commit introduces a check to ensure the order exists in sync before its state is read, thereby preventing this error. opw-3856451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where draggable list views (those with handle fields) were not sorting records consistently, which could result in unpredictable ordering when multiple records had the same sequence number. The fix ensures records are always sorted by their ID as a secondary sort criterion, providing stable and predictable results for users.
Original PR description
Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification.…
Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification. This could include "order".
In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC".
Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python using the "natural order" of the model (the `model._order` slot), which usually had the right parameters. (see `sale.order.line` for example). When fetching the ids of the one2many, those were already sorted in natural order.
In unity read, the natural order is overriden by the specification and became only "[handle_field] ASC". This was insufficient as more often than not, sequences on model are set up with a default. So eventually, all records couls have the same sequence. The sorting in SQL becomes undeterminate.
After this commit, we had the sorting key "id ASC" to avoid any unwanted results.
opw-3790378
see discord https://discord.com/channels/678381219515465750/687338039717920792/1231977078564585555 for a detailed discussion.
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-prA recent theme update in version 17.0 broke the visual appearance of the Odoo mega menu title underlines, making them appear faded or invisible. This fix restores the proper colors to these underlines by adjusting how the styling is applied, ensuring the website navigation menu looks correct again.
Original PR description
Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible. As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they do not work as well in 17.0 as they did in 16.0. This will be reviewed in master to use better colors and a more reliable and beautiful way. [1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e
This fix resolves an issue where users navigating through grouped list views would lose their page position when opening a record and returning via breadcrumb. Previously, clicking back would reset to page 1 instead of maintaining the current page offset. Now the page position is correctly preserved when navigating back to the list.
Original PR description
Issue: Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1. After this commit, the offset is correctly kept. opw~3851390 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#162904 Forward-Port-Of: odoo/odoo#162844
The color picker tool was appearing in the wrong position when editing mass mailing templates. This fix adjusts how the positioning library handles elements within the editor's iframe, ensuring the color picker displays correctly when users try to change text colors in their campaigns.
Original PR description
Issue: ====== Colorpicker doesn't appear in mass mailing Steps to reproduce the issue: ============================= - Create a new mass mailing with a some template other than plain text - Try to…
Issue: ====== Colorpicker doesn't appear in mass mailing Steps to reproduce the issue: ============================= - Create a new mass mailing with a some template other than plain text - Try to change the color of some text - The position of the colorpicker is wrong. Origin of the issue: ==================== When wysiwyg was converted to owl in [1], an effort was made to speed up the loading of the iframe in mass_mailing. One of the changes that were done in that regard was to remove assets from the iframe to make it load faster. This required to create the sidebar (SnippetsMenu) outside of the iframe since the iframe did not have the required files anymore, and insert it back in the iframe afterwards, since it was designed to work inside the iframe. This change actually had an impact on the positioning of the colorpicker, and basically anything that relied on popper.js for positioning, because since popper.js was outside of the iframe then the checks it did based on `instanceof HTMLElement` were returning false for every node inside the iframe. At the time of [1] this went unnoticed because the chatter was not yet in the side of the screen for mass_mailing, so the wrong positioning of the colorpicker was actually only slightly off the right position, thus being hard to catch while not specifically looking for that particular issue. As soon as the chatter was made to be on the side even in the case of mass_mailing, the wrong colorpicker position became visible but the issue went unnoticed at the time as well, probably because the two changes were completely unrelated. This went live in saas-16.4 and is the case in 17.0 as well. However, the issue does not exist anymore in saas-17.1 due to the refactor of mass_mailing to have the sidebar (SnippetsMenu) working from outside of the iframe instead of inside. Solution: ========= Fixing this issue properly would require huge changes to how the SnippetsMenu is constructed and would most likely require going back to the slow iframe with all the assets inside. That would not be a desirable outcome, especially in a stable version. With that in mind, and considering the issue doesn't exist in saas-17.1, we decided it was a prime example where a local change in the popper.js library was actually the best fix. The library is very unlikely to be updated in a stable version and the change won't reach saas-17.1. [1]: https://github.com/odoo/odoo/commit/76d4f98 co-authored with dmo-odoo task-3614965 Forward-Port-Of: odoo/odoo#160505