Daily updates from Odoo
Friday, March 15, 2024
46 changes · master
Enhancements to existing features
A new automated test checks that table appointments appear correctly in the restaurant point-of-sale view. This helps prevent future changes from breaking appointment visibility for restaurant staff.
Original PR description
This commit adds a test for the pos_restaurant_appointment. The test creates an appointment for a table and checks if the appointment is displayed underneath the table.
This update standardizes how Odoo checks whether a user belongs to a group, removing older ambiguous behavior and making permission checks more predictable. It affects several business apps but is mainly an internal cleanup intended to reduce confusion and prepare for future simplification of debug-related behavior.
Original PR description
[IMP] base: Remove `user_has_groups` and env.user fallback in `has_group` The user_has_groups method calls `self.env.user.has_group`, with the difference being a split (and the negative group '!' used only for the views) of the provided string and management of `group_no_one` using `request.session.debug`. The use of `user_has_group` is quite confusing because it does not relate to the current record but to the environment. The `has_group` method is also confusing because if it is applied on an empty recordset then there is a fallback on `env.user` otherwise it uses the current record. The change makes it possible to unify the API and remove ambiguity and make method calls explicit, and make the groups independent of the session. Upcoming changes being the removal of group_no_one and decreasing the number of session.debug usages. see: https://github.com/odoo/odoo/pull/151597
Timesheets created on certain unvalidated field service tasks will no longer automatically reuse the task’s sales order line when no matching line is found for the employee. This avoids misleading billing or sales references and makes the timesheet information clearer for users.
Original PR description
Before this commit, when an employee timesheeted in an unvalidated FSM task which has a mapping for that employee and that no SOL was found in the SO according to that mapping, the SOL of the timesheet was set to the SOL of the FSM task by default. Which could lead to confusion for the user. Now, the SOL of the timesheet is set to False in such conditions. task-3510920
This update standardizes how the activity and message panel is defined across many business forms. It reduces duplicated setup behind the scenes, making future maintenance easier while keeping the user experience unchanged.
Original PR description
Remove all fields from chatter arch and simply use `<div class="oe_chatter"/>` with optional `options` attribute follow up of odoo/enterprise#57020 [Related Odoo PR](https://github.com/odoo/odoo/pull/156463) [Related Upgrade PR](https://github.com/odoo/upgrade/pull/5780)
The close reasons form for subscriptions now uses clearer wording for portal visibility and includes added guidance. When a close reason is not selectable in the portal, related portal options are hidden, making the setup easier to understand and reducing configuration mistakes.
Original PR description
In this PR, the user interface for the close reasons form is enhanced. the field string visible_in_portal is modified to Selectable in Portal and additional guidance is provided for this field. A new condition is introduced, ensuring that if the field is set to false, the subsequent section becomes invisible otherwise, it remains visible. task-3776667
Referral sharing and social push notifications were updated to keep working with a changed link tracking service. This is a behind-the-scenes compatibility improvement that helps shared links continue to be created reliably.
Original PR description
also impacted: social_push_notifications `linkTracker.search_or_create` now expects a list of dictionaries. See COM PR Task-2788965
Resolved issues and error corrections
A recent change in the HR app caused some Belgian payroll and salary configuration screens to display incorrectly. This fix restores the expected fields in those Belgian modules, helping users continue managing job-related payroll settings without disruption.
Original PR description
In response to the removal of certain fields from the hr module's job view on Task-3499251, inheritance in l10n_be_hr_payroll and l10n_be_hr_contract_salary views were disrupted. To address this issue, the affected fields have been set to invisible in the hr module and are now conditionally made visible within the dependent modules. Related PR causes issue: https://github.com/odoo/odoo/pull/141770
Images in the Social kanban view now load from the correct address after a recent URL routing change. This prevents broken image previews and keeps social content management visually consistent for users.
Original PR description
Bug === Since odoo/odoo@c63d14a0485a553b74a8457aee158384e9ae6d3f the base URL is /odoo and not /web, but the image route still use /web, so the URL must be absolute, otherwise the browser will try to fetch /odoo/web. Task-3805736
Barcode input fields are now larger in product addition, line editing, and inventory adjustment screens, making them easier to use. An unnecessary link on the location field was also removed to reduce confusion during warehouse operations.
Original PR description
With this commit =============== Enlarged barcode input fields in Add Product, Edit Line, and Inventory Adjustments sections, and removed the useless link to the location field. TaskId: 3516205
This fixes a configuration screen issue in the French payroll module caused by an invalid visibility setting. It helps ensure payroll settings display correctly and reduces the chance of confusion or errors when administrators configure French payroll.
Code cleanup and technical improvements
The grid and Gantt views were updated to use a newer internal display mechanism. This prepares these views for upcoming work while keeping the visible user experience essentially unchanged.
Original PR description
The hook useVirtual has been replaced by a new hook useVirtualGrid. We adapt the GridRenderer and the GanttRenderer to that change. This is done in preparation of task `3601456`. Co-authored-by: Bruno Boi <boi@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Miscellaneous changes
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it. # Explanation: - When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign. # Steps To Reproduce: - Go to the helpdesk > Configuration > Teams. - For a team (E.g. Customer C
Original PR description
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket…
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it. # Explanation: - When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign. # Steps To Reproduce: - Go to the helpdesk > Configuration > Teams. - For a team (E.g. Customer Care ) tick Random for Assignment Method. Then, add two users to the team. - Create a ticket and Note the Assigned to user. - Create a another one with empty 'Assigned to' field. - Create another ticket and notice how the automation did not apply and the ticket was assigned to the same user. # Solution: - add a filter in the search domain of the last_assigned_user to make sure it returns the actual last assigned user. opw-3746215 Forward-Port-Of: odoo/enterprise#58415 Forward-Port-Of: odoo/enterprise#58084
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 &
Original PR description
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 & 4, the top row of the csv file (header) should consists of: KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131 task-id: None Forward-Port-Of: odoo/enterprise#58477
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741. ### Steps to reproduce * make sure you're on an instance running on Windows [^1] * install `account_accountant` * go to any reconciliation model that has Auto-Validate enabled * click on 'Run manually' You should be met with a traceback: `TypeError: '<' not supported between instan
Original PR description
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with…
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741. ### Steps to reproduce * make sure you're on an instance running on Windows [^1] * install `account_accountant` * go to any reconciliation model that has Auto-Validate enabled * click on 'Run manually' You should be met with a traceback: `TypeError: '<' not supported between instances of 'int' and 'NoneType'` ### Cause The system expects `tools.config['limit_time_real_cron']` to be a number. However, on Windows systems, `limit_time_real_cron` and a few other configuration keys are disabled, and always set to `None`. See https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L488-L497 opw-3752912 opw-3780549 [^1]: For testing on Linux, you can modify these two conditions to behave as if `os.name != 'posix'`: https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L494-L497 https://github.com/odoo/odoo/blob/7fc9a0bd0a1871b14c508cce73e0f103de9c1283/odoo/modules/registry.py#L50-L57 Forward-Port-Of: odoo/enterprise#58550 Forward-Port-Of: odoo/enterprise#57728
Before this commit, the origin doc number set when doing a credit note from the pos was the name of the reversed move instead of its l10n_latam_document_number which is now the case. Forward-Port-Of: odoo/enterprise#58480
Original PR description
Before this commit, the origin doc number set when doing a credit note from the pos was the name of the reversed move instead of its l10n_latam_document_number which is now the case. Forward-Port-Of: odoo/enterprise#58480
Steps to reproduce: - Install appointment - Go in calendar -> Online Appointments - Click on the link button - Remove the appointment type Issues: We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired. opw-3749154 Forward-Port-Of: odoo/enterprise#58630 Forward-Port-Of: odoo/enterprise#57240
Original PR description
Steps to reproduce: - Install appointment - Go in calendar -> Online Appointments - Click on the link button - Remove the appointment type Issues: We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired. opw-3749154 Forward-Port-Of: odoo/enterprise#58630 Forward-Port-Of: odoo/enterprise#57240
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
Original PR description
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the v
Original PR description
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the value for the right country code. no task id Forward-Port-Of: odoo/enterprise#58620 Forward-Port-Of: odoo/enterprise#58585
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` compon
Original PR description
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` component, we check that condition. After this commit: - We no longer see the inspector inside the Dialog box. Task-3714496 Forward-Port-Of: odoo/enterprise#58484 Forward-Port-Of: odoo/enterprise#56056
Since the code is called in a safe_eval, instead of in the codebase in https://github.com/odoo/enterprise/pull/32970 We cannot use a variable in a lambda as it raises a NameError on the employee variable called in the filtered function. So to avoid the filtered function we loop on the leave and aggregate manually by employees. Forward-Port-Of: odoo/enterprise#58590
Original PR description
Since the code is called in a safe_eval, instead of in the codebase in https://github.com/odoo/enterprise/pull/32970 We cannot use a variable in a lambda as it raises a NameError on the employee variable called in the filtered function. So to avoid the filtered function we loop on the leave and aggregate manually by employees. Forward-Port-Of: odoo/enterprise#58590
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}` Forward-Port-Of: odoo/enterprise#58486
Original PR description
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}`
Forward-Port-Of: odoo/enterprise#58486…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
Original PR description
…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
Since the downpayment product has been removed, we are no longer able to send a invoice CFDI containing some down payment lines. ticket_id: 3795193 Forward-Port-Of: odoo/enterprise#58537
Original PR description
Since the downpayment product has been removed, we are no longer able to send a invoice CFDI containing some down payment lines. ticket_id: 3795193 Forward-Port-Of: odoo/enterprise#58537
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Chang
Original PR description
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Changes: 1. remove the fixed textarea font-size property and allow it to be set dynamically based on the zoom factor 2. apply text alignment on the multiline field Task: 3696347 Forward-Port-Of: odoo/enterprise#58289 Forward-Port-Of: odoo/enterprise#58035
At the initial evaluation of a spreadsheet with pivots/lists, almost all cells are in error because they are loading. But throwing errors is slow. With this commit, instead of throwing loading errors for every single cell, the error is returned. This commit improves the first evaluation time of spreadsheet the "BE Timesheet" dashboard on odoo.com by ~20%, from ~1716ms to ~1365ms Task: 3736190 Forward-Port-Of: odoo/enterprise#58616
Original PR description
At the initial evaluation of a spreadsheet with pivots/lists, almost all cells are in error because they are loading. But throwing errors is slow. With this commit, instead of throwing loading errors for every single cell, the error is returned. This commit improves the first evaluation time of spreadsheet the "BE Timesheet" dashboard on odoo.com by ~20%, from ~1716ms to ~1365ms Task: 3736190 Forward-Port-Of: odoo/enterprise#58616
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
Original PR description
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
Original PR description
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384
Original PR description
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
Original PR description
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
In 2024, credit card withholding tax is only required for manual documents, we improve the suggestion method and fix the tests Forward-Port-Of: odoo/enterprise#58185
Original PR description
In 2024, credit card withholding tax is only required for manual documents, we improve the suggestion method and fix the tests Forward-Port-Of: odoo/enterprise#58185
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view
Original PR description
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that…
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view of article items with /kanban or /list 4. Create an article item (-> The "New" button from the embedded view) 5. Delete the parent article using the "more options" panel 6. Click on the "Open the Trash" button 7. From the list view, click on the article item you created at step 4 8. Click on the "Restore" button from the banner => The user receives a validation error indicating that the article item should have a parent. This error occurs because the parent article is in the trash, and the article item cannot be detached from its parent. TO BE: The user should receive an error message indicating that the article item cannot be restored and that the user needs to restore the parent article first in order to restore the article item. Forward-Port-Of: odoo/enterprise#55442
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forwar
Original PR description
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forward-Port-Of: odoo/enterprise#58565
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/enterprise#58459 Forward-Port-Of: odoo/enterprise#52726
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#5
Original PR description
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#58137
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#58439 Forward-Port-Of: odoo/enterprise#56188
Original PR description
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#58439 Forward-Port-Of: odoo/enterprise#56188
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selec
Original PR description
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selected or not. This reduces the complexity from O(n^2) to O(n). Benchmark: On a laptop and with 2000 lines, selecting the last line took 7.5s before, and 600ms with this commit. opw-3754849 Forward-Port-Of: odoo/enterprise#58182
Since fixed introduced in https://github.com/odoo/enterprise/pull/57590, the context is lost when we call 'update_existing_subscriptions'. As we put a dictionnary returned by '_upsell_context' in the 'with_context' to call write on the subscription, it replace the current context by the new one. As we just want to add values to the context and not replace it, we get the key/values as named arguments to update the current context and not replace it Forward-Port-Of: odoo/enterprise#58530
Original PR description
Since fixed introduced in https://github.com/odoo/enterprise/pull/57590, the context is lost when we call 'update_existing_subscriptions'. As we put a dictionnary returned by '_upsell_context' in the 'with_context' to call write on the subscription, it replace the current context by the new one. As we just want to add values to the context and not replace it, we get the key/values as named arguments to update the current context and not replace it Forward-Port-Of: odoo/enterprise#58530
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Original PR description
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in ca
Original PR description
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in case we are in debug mode. The display of the error allows to open the incriminating views in a dialog, and see some basic information on them, as well as, obviously, the error message and type. opw-3735973 [1]: 62c167f87176674cbabad976d93eeb717f73df7a Forward-Port-Of: odoo/enterprise#58491
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the database before going to the base level default of English. **Steps to reproduce:** 1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish 2. Deactivate the default English language pack 3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Tod
Original PR description
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the…
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the database before going to the base level default of English. **Steps to reproduce:** 1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish 2. Deactivate the default English language pack 3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Todos los recibos de nómina`, then select any report and click the Imprimir (Print) button 4. Observe some sections are in English **Cause of the issue:** When an employee's language is not set, English is used as a default. **Fix:** Look to use the environment's language if the Employee's is False. Ammended to fix other situations in hr_payroll where an employee language is accessed without using `env.lang` as a primary fallback. opw-3747839 Forward-Port-Of: odoo/enterprise#57780
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at
Original PR description
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at the bottom: `[44] < ([00] + [01] + [02] + [03] + [45] + [46] + [47] + [48] + [49]) * 200 if [88] > 99.999` opw-3767675 Note: confirmed by TSB on the ticket Forward-Port-Of: odoo/enterprise#58343
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
Original PR description
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
Original PR description
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
This PR fixes a method override not calling the method on super() Forward-Port-Of: odoo/enterprise#58494
Original PR description
This PR fixes a method override not calling the method on super() Forward-Port-Of: odoo/enterprise#58494
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on th
Original PR description
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on the original subscription. As a result, the information is duplicated. Solution: --------- Do not include upsells in the sales report. Note: ----- With the fix, the value is 200 and not 170, because it is not possible to take upsell discounts into account in the sales report (we have to use the subscriptions report). opw-3646388 Forward-Port-Of: odoo/enterprise#58369 Forward-Port-Of: odoo/enterprise#57568