Thursday, April 6, 2023
57 changes · master
Enhancements to existing features
The installation documentation now includes guidance for configuring system language settings. This helps prevent setup failures and warning messages caused by misconfigured server locales, making deployments more reliable.
Original PR description
Fix the following errors:
- `DataError: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII) HINT: Use the same encoding as in the template database, or use template0 as template.`
- https://www.odoo.com/es_ES/forum/ayuda-1/question/dataerror-new-encoding-utf8-is-incompatible-with-the-encoding-of-the-template-database-sql-ascii-52124
- `/werkzeug/filesystem.py:63: BrokenFilesystemWarning: Detected a misconfigured UNIX filesystem: Will use UTF-8 as filesystem encoding instead of 'ANSI_X3.4-1968'`
- https://stackoverflow.com/questions/34515331/werkzeug-raises-brokenfilesystemwarningThis update adds automated checks for the shared tag display component and removes configuration that was no longer actually used. It helps keep tag displays consistent across areas like Project and the general web interface while reducing maintenance risk.
Original PR description
*: project This commit adds test to this component and removes unused props. Since commit (1), it is now considered as a core component. Those props have been removed from the props declaration, to better match the real usage of the component. Since the className props was not present: - The o_kanban_tag class given in theory were not set in practice. The rules corresponding to that class were already adapted to fix the display of tags in the kanban view. It was possible to get rid of the references to the o_kanban_tag class. - The o_field_property_tag_readonly class was also missing, and the logic to prevent the click on tags was duplicated in the onTagClick function. This makes the class useless. I removed mentions to this classname. (1): 129fa3f150fe8b084f054036da7f399855d3ef0c
Odoo can now handle requests to place empty values first or last when sorting records. This makes list ordering more predictable, especially for descending sorts and related records where empty values previously could appear in confusing positions.
Original PR description
Recent Odoo versions require modern postgres (e.g. use of jsonb), the `NULLS {FIRST | LAST}` clause was added in 8.3 so should be well supported. While Odoo's use of nulls is not always consistent,…
Recent Odoo versions require modern postgres (e.g. use of jsonb), the `NULLS {FIRST | LAST}` clause was added in 8.3 so should be well supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering clauses can be quite useful especially when sorting `DESC`: `NULLS FIRST` and `NULLS LAST` are literal positions so they put nulls at that location regardless of sort order whereas the default Postgres ordering is to consider nulls larger than every other value so they appear first when sorting DESC, which is often undesirable (putting nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and consistently, also update `regex_order` to use named groups to make the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST` to correctly flip the original as `NULLS` clauses are not relative to the sorting order (they put the `NULL`-valued records at the specified location regardless). Therefore apply `reverse_direction` to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the clause through the join would yield unexpected and illogical results when mixing NULL m2o fields and non-NULL m2o fields with NULL `_order` fields (as they would get mixed rather than clearly layered / separated).
However because SQL booleans are ordered the usual way (`true > false`) the `NULLS` clause is fundamentally equivalent to sorting on the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So we can prepend the expanded m2o's ordering with such a clause to get the correct behavior.
Replaces #116464
Supersedes #116664Small icon menus in the Odoo navigation bar are now easier to use because they no longer open automatically while moving across nearby menus. This reduces accidental menu openings and makes navigation smoother, especially around debug, messaging, and activity menus.
Original PR description
The first commit removes the manualOnly prop on the Dropdown component and all its related code because it seems unused. The second commit adds a new prop to the Dropdown component: autoOpen. It is true by default and follows the current behavior of all current dropdowns (automatically open the dropdown when it is hovered and a sibling is already opened) when set to true and disable this feature for the dropdown when set to false. The commit also applies this new property and set it to false on all dropdowns that are present by default in the enterprise navbar to facilitate navigation with those that are too small (debug, messaging and activity) opw-3259473
Call participant cards now show a clickable error indicator that lets users retry playback when browser media restrictions interrupt audio or video. This makes online calls easier to recover without leaving or restarting the call.
Original PR description
This commit improves the overlay icon that appears on call participant cards when an error in the media players occur. The icon is now clickable, which restarts an attempt to play all the `HTMLMediaElement`s of the call as a recoverable error can occur when the browser does not allow `HTMLMediaElement`s being played outside a user interaction. other related changes: * removing the `pointer-event:none` from the overlay as it was preventing hover events, and the title tooltip from appearing. * removing the try/catch around the `srcObject` assignment, as it should only crash on old browsers without support for `srcObject` for which the support of using the alternative (`URL.createObjectUrl` with `src`) is being dropped.
Project profitability now includes manually added analytic accounting lines when they clearly belong to a single project, giving managers a more complete view of costs and revenues. Portal pages also show the specific task, ticket, or project name, and task dependency notifications are clearer for users.
Original PR description
This commit purpose is - to add the all the user adds manually to the panel of project profitability if there is only project linked to the analytic account. - to remove the stage tracking for task dependencies, and instead log a note to warn the user when all the blocking tasks are closed. If one of those task is reopened, message is sent to warn that the task is blocked again - to display the name of the current task/ticket/project on the portal page instead of the generic My tasks/etc - to update the name of notification sub-types task/project dependcy task-2960753 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
Helpdesk portal ticket pages now use the current ticket name instead of a generic “My Tickets” page title, making it easier for customers to understand where they are. Related field service sales profitability tests were updated to stay aligned with recent underlying changes.
Original PR description
This commit purpose is to - update the test of test_project_profitabilty in accordance to the changes made in the communty part of this task. - change the generic My tickets page name of the portal into the name of the current ticket task-2960753
Odoo Studio now shows a helpful message in the sidebar when a separator element is selected. This avoids an empty properties panel and makes the editing experience clearer for users configuring views.
Original PR description
This commit simply provides some feedback in the properties tab of the sidebar when a separator element is selected instead of displaying nothing. opw-3259505
Odoo’s document scanning has been upgraded to a newer OCR version for invoices, expenses, and recruitment documents. This improves compatibility with the latest extraction service and adjusts how extracted results are handled, including cases where suggested values may be missing.
Original PR description
Upgrade to the latest OCR version (app: 102, exp: 132, inv: 122). With this version, we do not send the `global_taxes` nor the `global_taxes_amount` anymore. `words` in the response were replaced by the more suitable `candidates`. It is now possible to not have `candidates` in the response, and it is also possible to have no `selected_value`.
The Helpdesk overview page now gives clearer performance context with an updated success rate explanation and color-coded performance indicators against daily targets. Urgent ticket actions also open with the urgent filter applied by default, helping teams focus on priority work faster.
Original PR description
In this PR change following UI changes in helpdesk overview page: - change the 'success rate' tooltip to - "Percentage of tickets whose SLAs have successfully been reached on time over the total number of tickets closed within the past 7 days." - 'Today' and 'Avg Last 7 days' my performance buttons in btn-success if the value is >= to their daily target else btn-warning. - set the 'urgent' filter by default in team kanban card urgent action task-3186583
Portal users can now see how many shared documents are linked to a project task even when the shared project is editable. This makes document access more consistent and reduces confusion for external users collaborating on projects.
Original PR description
**Before this commit:** Currently, documents are available to portal users when the project is shared in read-only, but not when it is shared in editable. It is inconsistent and prevents portal users from easily accessing their documents. **In this commit:** - A new computed field shared_document_count added to project.task containing the number of shared_documents_ids. - A new stat button is added to project.task in portal view showing the number of shared documents and redirecting to shared documents page. task-3092925
Resolved issues and error corrections
The kanban avatar field now checks whether a user has the needed access rights before showing actions such as adding users. This prevents employees with limited permissions from seeing controls they cannot use, reducing confusion and avoiding failed actions.
Original PR description
This commit creates a new useAccessRights hook which can be used by field components to check if the user has access to the specified model. This allows to hide features of the field that could only be used with the right access rights. The bug that it fixes in this case is the add user icon that appears in the kanban many2many_tags_avatar_field for any user while it is not possible to use with insufficient access rights. Steps to reproduce: give minimal access rights to Marc Demo user, log in as Marc Demo, go to calendar, go to online appointments and check if the add user icon is available. opw-3265086
Code cleanup and technical improvements
This change removes unused internal logic from Point of Sale invoice generation related to cash rounding. It does not change expected behavior, but helps keep the code simpler and easier to maintain.
Original PR description
When generating invoice for PoS orders, if a cash rounding is applied, a cash rounding line is generated. Thus it is not possible to have `rounding_applied` and NOT `rounding_line`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
## Current behaviour When creating a timesheet, if in the vals passed the AAL doesn't have a company (possible since it's not required), then the `uom` of the timesheet is False, which doesn't make sense. ## Expected behaviour The timesheet `uom` should fallback on the uom of the company of the project. ## Steps to reproduce - Install hr_timesheet, Accounting - Activate the AAL in the settings - Create a project with an AAL - Remove the company on the AAL of the project - In that pr
Original PR description
## Current behaviour When creating a timesheet, if in the vals passed the AAL doesn't have a company (possible since it's not required), then the `uom` of the timesheet is False, which doesn't make…
## Current behaviour When creating a timesheet, if in the vals passed the AAL doesn't have a company (possible since it's not required), then the `uom` of the timesheet is False, which doesn't make sense. ## Expected behaviour The timesheet `uom` should fallback on the uom of the company of the project. ## Steps to reproduce - Install hr_timesheet, Accounting - Activate the AAL in the settings - Create a project with an AAL - Remove the company on the AAL of the project - In that project create a task and log some timesheet. - `uom` field should be empty ## Reason for the problem When setting the `product_uom_id` in the vals when creating/writing a timesheet, we just take the `project_time_mode_id` on the company linked to the AAL. The problem is that the company on an AAL is not a required field, so it can be `False`, leading the setting the val for `product_uom_id` to `False`. ## Fix In case the AAL has no company, we get the `uom` from the company linked to the project. ## Affected versions - 14.0 - 15.0 - saas-15.2 - 16.0 - saas-16.1 - saas-16.2 - master --- opw-3245671 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117362 Forward-Port-Of: odoo/odoo#117012
Deleting a link preview in Mail no longer triggers an unexpected error. This keeps message cleanup smooth for users and avoids interruptions when managing conversations.
The task activity view now displays correctly again, resolving a broken layout that could make it harder for users to review task-related activities. This helps project teams navigate task information more easily and reduces visual confusion.
Original PR description
In this PR, we fixed the broken layout of the task activity view. task-3231708
Customer rating notifications for project tasks now match the configured rating setting. Users can subscribe to task rating updates only when customer ratings are enabled, and those subscriptions are removed for projects where ratings are turned off.
Original PR description
The customer rating field is disabled though in the chatter of the project we'll able to subscribe Task Rating subtype. This PR ensures that when the customer rating field is enabled, the user can get a subscription to Task Rating. If the user disables customer rating for an individual project then for that particular project Task Rating subtype will unsubscribe task-3231708
This fix prevents Point of Sale sessions from failing to load when product packagings with barcodes are configured. Businesses using packaged products can start sales sessions normally and see packaging information correctly.
Original PR description
Happen since 29d55e44 To reproduce the error: - Settings > Inventory > Enable "Product Packagings" - Inventory > Configuration > Products > Product Packagings - Create a new packaging having a barcode - Start a Point of Sale session - The session is not loaded and a traceback is raised Reason: we try to apply the find() method on an object instead of an array After this commit, the session is loaded and the packaging is correctly displayed
The chat window styling has been adjusted so its borders look cleaner and more consistent. This is a small visual fix that improves polish and readability without changing how chat works.
Original PR description
Before <img width="1033" alt="Screenshot 2023-04-06 at 17 49 24" src="https://user-images.githubusercontent.com/6569390/230431489-cb403194-3fe5-4873-8190-2a3cafcb5e62.png"> After <img width="1033" alt="Screenshot 2023-04-06 at 17 47 21" src="https://user-images.githubusercontent.com/6569390/230431527-bcd6160f-081e-470b-92be-50802e068ff8.png">
The chat window now shows a user's own message bubble with the correct visual orientation. This small correction improves readability and polish in Odoo messaging without changing how chat features work.
Original PR description
Before/After <img width="347" alt="Screenshot 2023-04-06 at 17 12 20" src="https://user-images.githubusercontent.com/6569390/230422343-bcccfe8b-7384-4946-9f94-73b2f5660c09.png"> <img width="342" alt="Screenshot 2023-04-06 at 17 10 40" src="https://user-images.githubusercontent.com/6569390/230422239-7bda3098-fd7f-4086-b843-7e69a2ceb489.png">
This update simplifies how Odoo's web views prepare and load data by removing unused internal parameters. It does not introduce visible feature changes, but it helps keep the web interface code easier to maintain and less error-prone over time.
Original PR description
This commit removes the onCreate param in Kanban, as it is no longer useful since [1]. It also removes the beforeLoadProm param and replaces it by an onWillStart option, which is slightly cleaner (there was no reason for this to be a model param as it is only used by the useModel hook). [1] 067bcac53336b5f66f695b1c10b333d8c722225d Part of task 3179751 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 modernizes the Point of Sale internals by removing older technical dependencies and centralizing how customer-facing displays are managed. It also adds basic testing infrastructure, helping future PoS changes be delivered with more confidence and fewer regressions.
Original PR description
This PR continues the ongoing refactoring work on the PoS. It removes the use of the legacy environment, refactors the way the customer display is handled, and introduces a bit of unit testing infrastructure. More information can be found in the individual commits Enterprise: https://github.com/odoo/enterprise/pull/39123
Message lists now load in a continuous order, preventing gaps that could make some messages unreachable when scrolling or reloading conversations. This improves reliability in Mail, Discuss, and live chat conversations and prepares the system for future conversation jump features.
Original PR description
Adapt code of message fetch so that fetching of (needaction) messages are controlled in a way to keep continuous sequence of messages at all time. This code design solves the "holes" problem in a message list by not allowing holes. This fixes many scenario that generated these holes, resulting in unfetchable messages. Example of such a scenario: - post 40 messages - post a new message that is reply of the oldest message - page reload and scroll up until load more => 10 messages are missing in-between replied message and following message (that should have been 11 messages apart) This code is also in preparation to allow jumps in a conversation.
This update adapts Point of Sale enterprise modules to a newer internal structure for customer displays and device integrations. It helps keep certified localizations and IoT-connected POS setups compatible with the latest platform changes, with little direct change for end users.
Original PR description
Community: https://github.com/odoo/odoo/pull/117290
Steps to reproduce: - Install website_mass_mailing - Go to the frontend and activate the editor. - Add a newsletter block, change it to subscription form. Issue: The name of the newsletter is displaying also the number of subscribers (e.g. "Newsletter (1)"). Solution: Change the name we are using to display the newsletter name to use the `name` and not the `display_name`. opw-3145571 Forward-Port-Of: odoo/odoo#117582
Original PR description
Steps to reproduce: - Install website_mass_mailing - Go to the frontend and activate the editor. - Add a newsletter block, change it to subscription form. Issue: The name of the newsletter is displaying also the number of subscribers (e.g. "Newsletter (1)"). Solution: Change the name we are using to display the newsletter name to use the `name` and not the `display_name`. opw-3145571 Forward-Port-Of: odoo/odoo#117582
Issue: With the "Extra Step During Checkout" setting, it is possible to click on the "Configure Form" button which should redirect us to the form in order to edit it. However, we will always be redirected to the first website (even if we have modified it in the settings). Furthermore, if we don't have a cart in progress, we will be redirected to the shop. Solution: Add a parameter specifying that it is for editing. In this way, we can modify the form without having to create a cart.
Original PR description
Issue: With the "Extra Step During Checkout" setting, it is possible to click on the "Configure Form" button which should redirect us to the form in order to edit it. However, we will always be redirected to the first website (even if we have modified it in the settings). Furthermore, if we don't have a cart in progress, we will be redirected to the shop. Solution: Add a parameter specifying that it is for editing. In this way, we can modify the form without having to create a cart. Due to a technical limitation (reloading settings after saving), we will always be redirected to the first website. But it is possible to change the website (with the website editor) and modify the second website if necessary. opw-3245772 Forward-Port-Of: odoo/odoo#116975
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer have a relative positionning. As a result, most elements having an absolute position and placed relatively to those elements will be incorrectly placed. In website_event, the badges of the event cards are currently placed on the upper border of the card because they are now placed relatively to the whole card instead of the card body container having a `col-*` class. As a result, the badges isn't where it should be and
Original PR description
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer have a relative positionning. As a result, most elements having an absolute position and placed relatively to those elements…
After the migration of Bootstrap to 5.1.3, the `col-*` elements no longer have a relative positionning. As a result, most elements having an absolute position and placed relatively to those elements will be incorrectly placed. In website_event, the badges of the event cards are currently placed on the upper border of the card because they are now placed relatively to the whole card instead of the card body container having a `col-*` class. As a result, the badges isn't where it should be and get cropped by the container. Steps to reproduce the issue: 1. Create a new event 2. Set a template 3. Go to the /event page 4. Click on the edit button from the Odoo navbar to edit the page (editor) 5. Go to the "Customize" page 6. Click on the "Templates" toggle button To fix that issue, we will add a `position-relative` class on the card body container having the `col-*` class. This ensure that the badge will be placed as before between the card body and the card image. task-3251110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116879
[FIX] point_of_sale: random error when running PaymentScreenTotalDueWithOverPayment PaymentScreenTotalDueWithOverPayment result to random runbot error because the test is performing a series of steps that clicks the validate button which will randomly result to going to the ReceiptScreen which is not the goal of the test. In this commit, we replace the use of `pay` method with a more granular series of steps to make sure that the test doesn't click the validate button and will properly
Original PR description
[FIX] point_of_sale: random error when running PaymentScreenTotalDueWithOverPayment PaymentScreenTotalDueWithOverPayment result to random runbot error because the test is performing a series of steps that clicks the validate button which will randomly result to going to the ReceiptScreen which is not the goal of the test. In this commit, we replace the use of `pay` method with a more granular series of steps to make sure that the test doesn't click the validate button and will properly make the succeeding checks on the amounts in the PaymentScreen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117678 Forward-Port-Of: odoo/odoo#117501
By checking the script checking if all the account supposed to be in the BS are. The account 1380 of skr03 and the account 9090 of skr04 seems to be miss configured. For the first account, we went back to task 31826 when the account was added. And we think that the account 1380 was indeed misconfigured. For the other, by comparing with skr03 which has the same account, we can see that the type of the account is wrong. Also, the balance sheet works with tags. Some accounts added after the l
Original PR description
By checking the script checking if all the account supposed to be in the BS are. The account 1380 of skr03 and the account 9090 of skr04 seems to be miss configured. For the first account, we went back to task 31826 when the account was added. And we think that the account 1380 was indeed misconfigured. For the other, by comparing with skr03 which has the same account, we can see that the type of the account is wrong. Also, the balance sheet works with tags. Some accounts added after the load of the chart template were missing some tags. By overriding those methods, we can add tags afterward and be sure that those account are present in the Balance sheet. task-id: 3041738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117212 Forward-Port-Of: odoo/odoo#115143
steps: project > kanban card > task analysis > list view of report cause: trying to open a project from the list view issue: looking for __count in read_group fix: add no_open to project_id in the list view because we can open a project from kanban card and configuration task-3111378 Forward-Port-Of: odoo/odoo#117733 Forward-Port-Of: odoo/odoo#110405
Original PR description
steps:
project > kanban card > task analysis > list view of report
cause:
trying to open a project from the list view
issue:
looking for __count in read_group
fix:
add no_open to project_id in the list view because we can open a project from
kanban card and configuration
task-3111378
Forward-Port-Of: odoo/odoo#117733
Forward-Port-Of: odoo/odoo#110405Steps: - Install Project - portal view > task Issue: - the private task was displayed in the portal view Cause: - the domain was not set for the private portal project Fix: - displayed task whose project_id is not false - so private project was not displayed in the portal view task-3147011 Forward-Port-Of: odoo/odoo#117617 Forward-Port-Of: odoo/odoo#111456
Original PR description
Steps: - Install Project - portal view > task Issue: - the private task was displayed in the portal view Cause: - the domain was not set for the private portal project Fix: - displayed task whose project_id is not false - so private project was not displayed in the portal view task-3147011 Forward-Port-Of: odoo/odoo#117617 Forward-Port-Of: odoo/odoo#111456
Following the refactor done in [1], it is no longer possible to use the `value` prop. Instead, the field should explicitly use `props.record.data[props.name]`. However, while [1] tried to adapt all the existing fields, `website_publish_button` was forgotten. This commit adapts website_publish_button. Steps to reproduce: - Install website_sale - Go to the website app - In the configuration menu select Shipping Methods - Chose one of the shipping method - Try to toggle the "Unpubl
Original PR description
Following the refactor done in [1], it is no longer possible to use the `value` prop. Instead, the field should explicitly use `props.record.data[props.name]`. However, while [1] tried to adapt all the existing fields, `website_publish_button` was forgotten. This commit adapts website_publish_button. Steps to reproduce: - Install website_sale - Go to the website app - In the configuration menu select Shipping Methods - Chose one of the shipping method - Try to toggle the "Unpublished/Published" button => The value does not update properly [1]: https://github.com/odoo/odoo/commit/688986f888f2fe2371d58b74ded81315ba6bb353 task-3223146 Forward-Port-Of: odoo/odoo#116147
Current behavior: When you create a contact and a delivery adress for this contact. If you add the delivery adress as a vendor to a product, and purchase this product from the delivery adress, the contact will be added to the product vendor list. Steps to reproduce: - Create contact C - Create delivery adress D for C - Create product P - Add D as a vendor to P - Create PO for P from D, and confirm it - Go to P, and check the vendor list (C is there) opw-3177309 --- I confirm I hav
Original PR description
Current behavior: When you create a contact and a delivery adress for this contact. If you add the delivery adress as a vendor to a product, and purchase this product from the delivery adress, the contact will be added to the product vendor list. Steps to reproduce: - Create contact C - Create delivery adress D for C - Create product P - Add D as a vendor to P - Create PO for P from D, and confirm it - Go to P, and check the vendor list (C is there) opw-3177309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117696 Forward-Port-Of: odoo/odoo#115709
Since 8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9, Order model is no longer a backbone model therefore, we can no longer call the "trigger" method on it. Normally, the old "trigger" call means we want to rerender the screen and persist the new order information in the local storage. The order object is already setup to do those mentioned (rerendering and saving to local storage) when it's mutated. Therefore, we can just simply remove the "order.trigger" and "this.render" calls as proposed in this c
Original PR description
Since 8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9, Order model is no longer a backbone model therefore, we can no longer call the "trigger" method on it. Normally, the old "trigger" call means we want to rerender the screen and persist the new order information in the local storage. The order object is already setup to do those mentioned (rerendering and saving to local storage) when it's mutated. Therefore, we can just simply remove the "order.trigger" and "this.render" calls as proposed in this commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117828 Forward-Port-Of: odoo/odoo#116642
Since 5da90dfc4 a test has been added in which a global readonly variable from `window` is reassigned. Furthermore, it is the global "parent" which is read-only and should nerver be modified. Forward-Port-Of: odoo/odoo#117895
Original PR description
Since 5da90dfc4 a test has been added in which a global readonly variable from `window` is reassigned. Furthermore, it is the global "parent" which is read-only and should nerver be modified. Forward-Port-Of: odoo/odoo#117895
the error will occur because when you first add the menu that's menu can not store in the database without clicking on the save button and that id is temporary store in string format now you delete that menu and click on save they try to browse that menu but it is not available in the database and also it has a string. see:  steps to produce this error: 1) go to the website and c
Original PR description
the error will occur because when you first add the menu that's menu can not store in the database without clicking on the save button and that id is temporary store in string format now you delete that menu and click on save they try to browse that menu but it is not available in the database and also it has a string. see:  steps to produce this error: 1) go to the website and click on 'menu editor' 2) click on 'Add Menu Item' button 3) Add name and URL and click on the ok button. 4) now delete the newly added menu and save it. So here we can check the id type and only browse the integer type ids. sentry-3931666290 Forward-Port-Of: odoo/odoo#116153
… Forward-Port-Of: odoo/odoo#117019
Original PR description
… Forward-Port-Of: odoo/odoo#117019
How to reproduce ================ 1. Load the accounting & any of the modified l10n modules 2. Take any of the languages supported by the selected l10n module You'll see that all the terms remain in english opw-3114100 Forward-Port-Of: odoo/odoo#112966
Original PR description
How to reproduce ================ 1. Load the accounting & any of the modified l10n modules 2. Take any of the languages supported by the selected l10n module You'll see that all the terms remain in english opw-3114100 Forward-Port-Of: odoo/odoo#112966
Recently the tax report was updated with new tax report lines, but translations weren't added. This commit adds translations in FR, DE. task-3264626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117862 Forward-Port-Of: odoo/odoo#117790
Original PR description
Recently the tax report was updated with new tax report lines, but translations weren't added. This commit adds translations in FR, DE. task-3264626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117862 Forward-Port-Of: odoo/odoo#117790
As the number of `account.move`, `account.move.line`, `account.bank.statement.line` and `account.journal` is growing, the accounting dashboard, which is the entry point of the app, gets slower and slower. There are multiple issues being addressed in this commit: * The data for each journal is computed journal by journal. This means that the number of queries run increases linearly with the number of journals. While the boilerplate around running multiple queries is negligible com
Original PR description
As the number of `account.move`, `account.move.line`, `account.bank.statement.line` and `account.journal` is growing, the accounting dashboard, which is the entry point of the app, gets slower and…
As the number of `account.move`, `account.move.line`, `account.bank.statement.line` and `account.journal` is growing, the accounting dashboard, which is the entry point of the app, gets slower and slower. There are multiple issues being addressed in this commit: * The data for each journal is computed journal by journal. This means that the number of queries run increases linearly with the number of journals. While the boilerplate around running multiple queries is negligible compared to the running time of the queries in this case, some queries take as much time to run for one journal or for many. To improve this, all the queries are now batched. This has been done by refactoring the code; all these functions are now called on as many records as needed[^1]: - `_get_journal_bank_account_balance` - `_get_journal_outstanding_payments_account_balance` - `_get_last_bank_statement` - `get_line_graph_datas` - `get_bar_graph_datas` - `get_journal_dashboard_datas` * The gap detection and the entries' count are computed fields (`has_sequence_holes` and `entries_count` respectively). We don't need to display/compute these fields for all types of journals, but since they were mentioned by using a `<field/>` node in the view, they were computed for all journals displayed. Instead of using the `<field/>` node, we are now setting the value in the `kanban_dashboard` field. * Documents in foreign currencies on journals in foreign currencies need to get the rate in order to be aggregated in the journal's currency. There are 3 cases: - Document in journal's currency - Company's currency is the same as the journal's - Document, company and journal have 3 different currencies Before this commit, the second case will still fetch the daily rate for the document in order to do the conversion, but we actually already know the conversion; it is stored on the document. Benchmark ========= On a `populate` database with: - 4 `res.company` (with accounting enabled) - 45 `account.journal` - 19k `account.move` - 140k `account.move.line` - 4k `account.bank.statement.line` - 4 `account.bank.statement` | | Query count | Query time | Remaining time | | --------------------------- | ----------- | ---------- | -------------- | | Before fix | 279 | 0.333s | 0.375s | | After fix (without update) | 40 | 0.120s | 0.170s | | After fix (with update[^2]) | 38 | 0.100s | 0.170s | Note that the currency conversion was disabled because the populate database doesn't represent a realistic dataset regarding this. Disabling it only improves the numbers before the fix. Note ==== A lot of the time remaining comes from the aggregation of draft/unpaid invoices with the correct rate done in python instead of in SQL. This commit doesn't change the behavior but this could be rethought from a function point of view. [^1]: the old functions have been kept for compatibility, new ones are suffixed by `_batched` and made private if it wasn't the case. [^2]: some optimization require the views and indexes to be updated Forward-Port-Of: odoo/odoo#103697
Since the `account` module contains a CoA and is installed before any other `l10n_` module, the condition `and not self.env.company.chart_template` was always preventing the installation of a foreign CoA. By delaying until the registry is fully loaded, we will take the last CoA declared in the installation stack. [task-3256385](https://www.odoo.com/web#id=3256385&model=project.task) Forward-Port-Of: odoo/odoo#117370
Original PR description
Since the `account` module contains a CoA and is installed before any other `l10n_` module, the condition `and not self.env.company.chart_template` was always preventing the installation of a foreign CoA. By delaying until the registry is fully loaded, we will take the last CoA declared in the installation stack. [task-3256385](https://www.odoo.com/web#id=3256385&model=project.task) Forward-Port-Of: odoo/odoo#117370
A small part of the accounts type were incorrectly changed in Odoo 15 by odoo/#83039 We are bringing the old type back. Task link: https://www.odoo.com/web#id=3263687&model=project.task task-3263687 Forward-Port-Of: odoo/odoo#117924 Forward-Port-Of: odoo/odoo#117795
Original PR description
A small part of the accounts type were incorrectly changed in Odoo 15 by odoo/#83039 We are bringing the old type back. Task link: https://www.odoo.com/web#id=3263687&model=project.task task-3263687 Forward-Port-Of: odoo/odoo#117924 Forward-Port-Of: odoo/odoo#117795
Because we are getting the default journal from a hypothetical move from the same type, there needs to be a journal existing before being able to create that hypothetical move. To reproduce: * install `documents_account` without demo data Forward-Port-Of: odoo/enterprise#39200
Original PR description
Because we are getting the default journal from a hypothetical move from the same type, there needs to be a journal existing before being able to create that hypothetical move. To reproduce: * install `documents_account` without demo data Forward-Port-Of: odoo/enterprise#39200
Adapt the code to community changes Forward-Port-Of: odoo/enterprise#33165
Original PR description
Adapt the code to community changes Forward-Port-Of: odoo/enterprise#33165
Issue 1: - Allocated hours will not appear in parentheses if the plan date is empty. - A hyphen will appear if a plan date is set. Steps to reproduce (small device ) : - Install the sale_planning, - Got to planning Gantt view - Click on Plan Icon - Check the planning kanban view Issue 2: - A sale order line does not appear if the resource is empty.Because xpath is wrong. task- 3099432 Forward-Port-Of: odoo/e
Original PR description
Issue 1:
- Allocated hours will not appear in parentheses if the plan date is empty.
- A hyphen will appear if a plan date is set.
Steps to reproduce (small device ) :
- Install the sale_planning,
- Got to planning Gantt view
- Click on Plan Icon
- Check the planning kanban view
Issue 2:
- A sale order line does not appear if the resource is empty.Because xpath is wrong.
task- 3099432
Forward-Port-Of: odoo/enterprise#35121Recently the tax report was updated with new tax report lines, but translations weren't added. This commit adds translations in FR, DE. task-3264626 Forward-Port-Of: odoo/enterprise#39410 Forward-Port-Of: odoo/enterprise#39373
Original PR description
Recently the tax report was updated with new tax report lines, but translations weren't added. This commit adds translations in FR, DE. task-3264626 Forward-Port-Of: odoo/enterprise#39410 Forward-Port-Of: odoo/enterprise#39373
Create a receivable Account A (different from the default one) Have a customer C1 and set the receivable account A Have a customer C2 and set the receivable account A Create an invoice for C1 and C2 Generate DATEV zip (Accounting > Reporting > General Ledger) In customer_accounts.csv Konto for both customers will be the same opw-2976869 Forward-Port-Of: odoo/enterprise#35465
Original PR description
Create a receivable Account A (different from the default one) Have a customer C1 and set the receivable account A Have a customer C2 and set the receivable account A Create an invoice for C1 and C2 Generate DATEV zip (Accounting > Reporting > General Ledger) In customer_accounts.csv Konto for both customers will be the same opw-2976869 Forward-Port-Of: odoo/enterprise#35465
In the timesheet grid view, there is an incosistency between _apply_grid_grouped_expand and _group_expand_employee_ids. - The first one that take care of adding the project under the employee section if the employee has some timesheet whithin the past week for task in that project that are active or ts not link to any task `'|', ('task_id.active', '=', True), ('task_id', '=', False)` - The second one take care to show the section (the employee) if there is some timesheet link to a pro
Original PR description
In the timesheet grid view, there is an incosistency between _apply_grid_grouped_expand and _group_expand_employee_ids. - The first one that take care of adding the project under the employee section…
In the timesheet grid view,
there is an incosistency between _apply_grid_grouped_expand and _group_expand_employee_ids.
- The first one that take care of adding the project under the employee section if the employee has some timesheet whithin the past week for task in that project that are active or ts not link to any task
`'|', ('task_id.active', '=', True), ('task_id', '=', False)`
- The second one take care to show the section (the employee) if there is some timesheet link to a project the past week
Combine with the ts automatically created when any employee take a day off. Those timesheet are link to an inactive task in an inactive project.
We end up with a lot of empty section because the first method ignore those TS (they are in an inactive task) but the second one find them and display the employee
This lead for example in a company with 2.5k employee were only 750 really timesheet to display more than 1500.
The size of the answer may lead to memory error.
We actually don't want to see empty section without project and we don't want to see the employee that have only timesheet when they take a day off
Solution
--------
Make both method consistent by not looking for ts in inactive task in _group_expand_employee_ids. This help to show only the relevant project and employee reducing the size of the answer (avoiding the memory error) and making the page a bit more responsive.
Forward-Port-Of: odoo/enterprise#37770The employee created in the test would get the resource calendar of the company it was created with (YourCompany). This would make this part [1] of the code fail as Laurie Poiret doesn't have access to the company. [1] : https://github.com/odoo/enterprise/blob/b75361c75cef44100f04a31f20856dd5198cd0cb/l10n_hk_hr_payroll/models/resource_calendar.py#L12 Forward-Port-Of: odoo/enterprise#39389
Original PR description
The employee created in the test would get the resource calendar of the company it was created with (YourCompany). This would make this part [1] of the code fail as Laurie Poiret doesn't have access to the company. [1] : https://github.com/odoo/enterprise/blob/b75361c75cef44100f04a31f20856dd5198cd0cb/l10n_hk_hr_payroll/models/resource_calendar.py#L12 Forward-Port-Of: odoo/enterprise#39389
Steps to reproduce: 1. create a sale order with international UPS shipping 2. confirm the sale order and try to validate the delivery 3. get error: `Invalid or missing product unit number for product number 1. Valid length is 1 to 7 numeric` The issue comes from the fact that Odoo sends the quantity as a float (e.g. `2.0` instead of `2`) The quantity is already rounded to be a whole number, so it can be fixed without losing any information, by representing the unit number as an integer.
Original PR description
Steps to reproduce: 1. create a sale order with international UPS shipping 2. confirm the sale order and try to validate the delivery 3. get error: `Invalid or missing product unit number for product number 1. Valid length is 1 to 7 numeric` The issue comes from the fact that Odoo sends the quantity as a float (e.g. `2.0` instead of `2`) The quantity is already rounded to be a whole number, so it can be fixed without losing any information, by representing the unit number as an integer. opw-3264342 Forward-Port-Of: odoo/enterprise#39368
The formula for the "tax report (mod303)" line "[27] Total cuota devengada" has a duplicated item. Steps to reproduce : -Activate developer mode -Go to "accounting/configuration/management/accounting reports" -Open "Tax report (mod303)" -Open line "[27] Total cuota devengada" -Edit the formula - You can see the item aeat_mod_303_15.balance exists 2 times opw-3225565 Forward-Port-Of: odoo/enterprise#39206
Original PR description
The formula for the "tax report (mod303)" line "[27] Total cuota devengada" has a duplicated item. Steps to reproduce : -Activate developer mode -Go to "accounting/configuration/management/accounting reports" -Open "Tax report (mod303)" -Open line "[27] Total cuota devengada" -Edit the formula - You can see the item aeat_mod_303_15.balance exists 2 times opw-3225565 Forward-Port-Of: odoo/enterprise#39206
When the user embeds a list view in Knowledge and chooses to hide and show some columns, the configuration will be shared among all embedded list views. Steps to reproduce the issue: 1. Create a new article 2. Create two embedded views with the /list command 3. In the first view, hide/show some fields 4. Reload the view => Both embedded views will have the same configuration. Here, we would like the configuration to be specific to each embedded view so that people can configure the
Original PR description
When the user embeds a list view in Knowledge and chooses to hide and show some columns, the configuration will be shared among all embedded list views. Steps to reproduce the issue: 1. Create a new…
When the user embeds a list view in Knowledge and chooses to hide and show some columns, the configuration will be shared among all embedded list views. Steps to reproduce the issue: 1. Create a new article 2. Create two embedded views with the /list command 3. In the first view, hide/show some fields 4. Reload the view => Both embedded views will have the same configuration. Here, we would like the configuration to be specific to each embedded view so that people can configure the embeds as they want. To determine which columns should be visible, the list render uses all available information about the view to generate a key. The system will then use that key to retrieve the active columns from the user's local storage. As we use the same action to open the article items, every list renderer will generate the same key and fetch the same cache entry. To avoid that, we will overwrite the `createKeyOptionalFields` function of the renderer to make sure that every embedded view uses a unique key. The embedded views will therefore not use the same cache entry and will be independent of each other. task-3217640 Forward-Port-Of: odoo/enterprise#39378 Forward-Port-Of: odoo/enterprise#39058
Currently when adding other input's in the payslip, when there are multiple inputs of the same type, example : - Commission 150 - Commission 150 Only the last commission will get taken into account in the sheet computation. After this PR, both inputs will be taken into account and the result in the computed sheet will be their sum. Forward-Port-Of: odoo/enterprise#39388 Forward-Port-Of: odoo/enterprise#36927
Original PR description
Currently when adding other input's in the payslip, when there are multiple inputs of the same type, example : - Commission 150 - Commission 150 Only the last commission will get taken into account in the sheet computation. After this PR, both inputs will be taken into account and the result in the computed sheet will be their sum. Forward-Port-Of: odoo/enterprise#39388 Forward-Port-Of: odoo/enterprise#36927
The Account Coverage Report should only be available for P&L and BS. For instance, in India, they have GSTR-3B (IN) on which the ACP shouldn't be run. task-id 3252976 Forward-Port-Of: odoo/enterprise#39269
Original PR description
The Account Coverage Report should only be available for P&L and BS. For instance, in India, they have GSTR-3B (IN) on which the ACP shouldn't be run. task-id 3252976 Forward-Port-Of: odoo/enterprise#39269
steps: helpdesk > Kanban card > ticket closed view shows all closed tickets of every team cause: the context was not applied correctly in view issue: the wrong context was given in the method fix: improved the context by removing unnecessary operators on condition task-3111378 Forward-Port-Of: odoo/enterprise#39340 Forward-Port-Of: odoo/enterprise#34517
Original PR description
steps: helpdesk > Kanban card > ticket closed view shows all closed tickets of every team cause: the context was not applied correctly in view issue: the wrong context was given in the method fix: improved the context by removing unnecessary operators on condition task-3111378 Forward-Port-Of: odoo/enterprise#39340 Forward-Port-Of: odoo/enterprise#34517
Recurring product may have different prices depending on period and pricelist (*Time based pricing*). On search preview the price was always shown for the first pricelist. Fix it by using website's current pricelist. The similar logic is already applied in `website_sale`'s `_get_combination_info` STEPS 1. Create two selectable pricelists 2. Create a subscription product with *Time based pricing* per each pricelist 3. Go to the website > Select one of the pricelist 4. Search product
Original PR description
Recurring product may have different prices depending on period and pricelist (*Time based pricing*). On search preview the price was always shown for the first pricelist. Fix it by using website's current pricelist. The similar logic is already applied in `website_sale`'s `_get_combination_info` STEPS 1. Create two selectable pricelists 2. Create a subscription product with *Time based pricing* per each pricelist 3. Go to the website > Select one of the pricelist 4. Search product in search bar > You can see price from another pricelist (if you don't, try another pricelist on the step 1). [1]: https://github.com/odoo/odoo/blob/1dff3eb1385108f9b55b6e21c556645a0ccfb358/addons/website_sale/models/product_template.py#L230-L233 opw-3185013 Forward-Port-Of: odoo/enterprise#39059
## Current behaviour When you have a SO with an undelivered backorder, you are unable to return the already delivered products from the helpdesk's ticket "return" button, you are met with an UserError that the deliveries needs to be "Done" so they can be returned. ## Expected behaviour You shouldn't be met with an UserError, and the user should be able to return the the deliveries that are already made, even if they have an undelivered backorder. ## Steps to reproduce - Install Helpdesk
Original PR description
## Current behaviour When you have a SO with an undelivered backorder, you are unable to return the already delivered products from the helpdesk's ticket "return" button, you are met with an…
## Current behaviour When you have a SO with an undelivered backorder, you are unable to return the already delivered products from the helpdesk's ticket "return" button, you are met with an UserError that the deliveries needs to be "Done" so they can be returned. ## Expected behaviour You shouldn't be met with an UserError, and the user should be able to return the the deliveries that are already made, even if they have an undelivered backorder. ## Steps to reproduce - Install Helpdesks, Sales, Inventory, helpdesk_stock - Create a SO, sell 5x storable product, confirm - Deliver only some of the quantity (ex: 3) - Create a backorder - Create a helpdesk ticket for that costumer we just made the so - Click on the Return button - We are met with an UserError ## Reason for the problem When we open the wizard for the return, an onchange is triggered with the picking_id chosen for the wizard, which happened to be the "last" picking that is linked to the so, which happens to be the backorder that is not done. The onchange has an assertion that picking in done should be returnable. ## Fix Filter the chosen picking for the wizard to select only picking in the SO that are actually in the `suitable_picking_ids`. ## Affected versions - saas-15.2 - 16.0 - saas-16.1 - saas-16.2 - master --- opw-3192714 Forward-Port-Of: odoo/enterprise#39227 Forward-Port-Of: odoo/enterprise#38272