Tuesday, April 23, 2024
29 changes
1 change
Resolved issues and error corrections
Corrects subscription-related list settings so new entries are added in the expected place when lists span multiple pages. This reduces confusion and prevents records from appearing on the wrong page during editing.
Original PR description
The "editable" attribute in list views can be set to either "top" or "bottom". List views are rng validated, and no other value can be used. However, x2many list inside form views aren't validated, and a few of them have editable="1". This seems to work, but only partially: the list is editable indeed, but if the list is multi page, there'll be issues when adding records (they'll be added in the last page, not the current one). This commit thus fixes the few views with incorrect editable attribute. opw~3860903
24 changes
Resolved issues and error corrections
This fix resolves an issue where financial reports would hang indefinitely when using cross-report expressions that reference data from other reports. The problem occurred because the system was only looking for required calculation references within the current report, not in other linked reports. This update ensures all necessary references are properly found, allowing reports to load correctly.
Original PR description
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single…
To reproduce:
- Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance"
- Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))"
- Another expression of any engine labelled 'dudu'
==> Try opening the first report; it loads forever.
This is because the bound expression is only searched in the expressions of the active report ; not in the expressions loaded from other reports. In our case, the aggregation needing the bound is from the second report, so the bound belongs to its report as well. The looping occurs because that value, since it's not present in the first report's evaluated data, is considered as not yet computed, and the computation is continuously delayed at the end of the treatment queue, causing it to never become empty.
Forward-Port-Of: odoo/enterprise#59175
Forward-Port-Of: odoo/enterprise#58339Fixed 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 fix removes an unnecessary restriction that prevented some employees from seeing the Documents button in their profile. Now all internal employees can access the Documents application from their profile to view their important documents like contracts and payslips, regardless of their specific user permissions.
Original PR description
HOW TO REPRODUCE ================ Log in as an internal user who is not a member of the `documents_user` group. Go to your profile. You should see the "Documents" smart button. However, the button has a `groups` attribute to restrict its visibility to the members of the `documents_user` group. HOW TO FIX ========== This issue is already known and a tolerated side-effect (see this [commit](https://github.com/odoo/odoo/pull/29659/commits/3651a3721865a465f5457b67436939a91f904bd1)) Moreover, it makes sense for any internal user to be able to access the Documents application, whether they have rights on it or not. As an employee, they may have documents they need to access (e.g.: contract, payslip...) The solution would be to remove the `groups` attribute from the smart button to reduce confusion among developers. And also, clarify that, indeed, any internal users can see the "Documents" smart button in their profile. task-3688377
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
This update resolves a critical performance issue in the Spanish tax report (Model 347) that occurred when processing large numbers of partners with small transactions. Previously, the system would crash when trying to exclude too many partners from the report. The fix optimizes the database query to include relevant partners instead of excluding irrelevant ones, allowing the report to generate successfully even with thousands of partners.
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The partners are not excluded in the domain but the other partners are included in the SQL query. opw-3770944
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 update resolves a critical issue in the German localization module where balance sheet report updates were failing during system upgrades. The problem occurred because the migration script was attempting to rename accounting tags that already existed, causing duplicate name conflicts. The fix adds a safety check to skip the renaming process if the target tag already exists, preventing upgrade failures for German companies using Odoo's accounting features.
Original PR description
Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is…
Forward port [commit](https://github.com/odoo/odoo/pull/132219) because the [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing when we try to rename [ref](https://github.com/odoo/odoo/blob/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py#L24) the tag due to the duplicate name constraint.
The implementation of forward porting has become necessary as the script attempts execution with each version, encounter failure due to the presence of the existing tag 'tag_de_liabilities_bs_B_1'. To prevent duplication, we have introduced a pre-check. If the 'B1' tag already exists, script execution is skipped.
Note: The [request](https://upgrade.odoo.com/web#id=1454059&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) is failing for the 17.0 version. However, if we migrate to the version saas-16.3, it also fails. Therefore, we are creating a PR in the saas-16.3 version to forward port it for subsequent versions as well.
Upgrade request traceback group: 813
```
File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 45, in migrate
rename_tag(cr, "tag_de_liabilities_bs_C_1", "tag_de_liabilities_bs_B_1")
File "/home/odoo/src/odoo/17.0/addons/l10n_de/migrations/2.0/pre-migrate.py", line 5, in rename_tag
cr.execute(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_model_data_module_name_uniq_index"
DETAIL: Key (module, name)=(l10n_de, tag_de_liabilities_bs_B_1) already exists.
```
In odoo#126249 the german balance sheet report was updated and
during the 15.2 FW port, some issues needed fixing. The
issues and their fixes are:
- Deleted tags: As the script didn't run, some tags (like F and all D tags) would be deleted and not renamed. As the tag might already be used as a FK in another table, we remove it from ir_model_data so it's not deleted by the ORM. Also, this means that the tags xml adds the B1 as a new tag which means renaming C1 to B1 will not work in the script due to the unique name constraint, this is handled by checking if B1 exists and if it does we do not run the script.
Enterprise PR: odoo/enterprise/pull/45899
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#161629This 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#160354A recent update to the website module contained a typo in a template where "full string" was incorrectly used instead of "full screen". This fix corrects that typo to ensure the website displays the proper text to users.
Original PR description
Recent commit [1] made a typo when converting templates [1]: https://github.com/odoo/odoo/commit/02461534d2b74410bcdfb5cccaac8157fe806127
This update fixes tests in the web interface that were randomly failing due to timing issues. The tests now wait the correct amount of time for the system to process URL changes and update the display, making the tests more reliable and reducing false failures.
Original PR description
Before this commit, several qunit load state tests sometimes failed. They all follow the same pattern: - trigger an "hashchange" event to simulate an update of the url - wait twice for nextTick -…
Before this commit, several qunit load state tests sometimes failed. They all follow the same pattern: - trigger an "hashchange" event to simulate an update of the url - wait twice for nextTick - check the DOM reflects the url change However, waiting for 2 ticks isn't enough. Indeed, when the url hash is set, our mock location object dispatches a "real" hashchange event on window, but it does it after a setTimeout [1]. Then, the webclient is notified (via the router service) of the url change, and reacts by loading the appropriate action. This then requires 2 ticks, because we first clear the DOM with the BlankComponent, and then we mount the requested action/view. This commit makes those tests more robust by waiting for a setTimeout before the 2 nextTicks. [1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52 Runbot issue~37030 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This 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-prFixed incorrect demo data in the survey module where a sample user response was marked as correct when it should have been incorrect. The answer "Pinaceae" was being treated as correct for the question about Dogwood's tree family, when the correct answer is actually "Cornaceae". This correction ensures the demo data accurately reflects the proper quiz answers.
Original PR description
Fix the demo user input lines which were considering "Pinaceae" as a correct answer to the question "Dogwood is from which family of trees ?" even though the suggested answer was declared as incorrect for the question. Dogwood is indeed from the "Cornaceae" family of trees, not the "Pinaceae". Fixing the issue by updating the user input lines to be incorrect. related: odoo/odoo#72298 Task-3856668 Forward-Port-Of: odoo/odoo#162392 Forward-Port-Of: odoo/odoo#160911