Tuesday, May 28, 2024
27 changes · master
New functionality added to Odoo
Adds localized payroll rules, contract fields, and payslip handling for companies operating in Egypt. It also connects Egyptian payroll with accounting setup and includes tests, helping businesses calculate and post payroll according to local requirements.
Original PR description
TaskID: 2653839
Enhancements to existing features
The expense onboarding process has been improved with a smoother flow and better user experience on both desktop and mobile. This helps employees get started with expense processing more easily and reduces friction when submitting or managing expenses.
Original PR description
Improved onboarding, flow, and UX on desktop and mobile for expense. A more detailed overview could be found here https://app.excalidraw.com/l/65VNwvy7c4X/73HONs7UUCz task-3919542
Resolved issues and error corrections
Dashboard Admin users can now insert CRM pivot views into spreadsheet dashboards without needing full system administrator rights. This fixes a permission gap so authorized dashboard editors can complete their work as intended.
Original PR description
Steps to reproduce: - install CRM (make sure Documents is not installed) - login with a user with "Dashboard Admin" group (but not system admin) - go to CRM and try inserting a pivot view in a spreadsheet => you can't Since odoo/odoo@0c50cbe18ce3f1 a new user group was created allowing to create and edit spreadsheet dashboards. However, members of that group are not able to insert anything because the group was not updated in the registry. Task: 3795574
Code cleanup and technical improvements
The accounting interface code for attachment previews was simplified without changing user-facing behavior. This makes the area easier to maintain and reduces the chance of future issues when developers update it.
Original PR description
`attachmentPreviewState.previewEnabled` was more complex than needed: it was a state solely made to make a getter reactive, due to lack of observing UI service state reactively with `useState()`. By putting `useState()` around the ui service in the component, this let us simplify the code of `previewEnabled` to simplify it being a getter.
Miscellaneous changes
## Task Description: When copying a chart in a spreadsheet, the link to the Odoo menu is not kept This PR aims to fix it by taking advantage of the new clipboard refactoring, with a new clipboard handler saving the odooMenuLink in the clipboard data and putting it back in the newly created chart. ## Related Task: - Task: 3380568 - https://github.com/odoo/o-spreadsheet/pull/3670 Forward-Port-Of: odoo/enterprise#58564
Original PR description
## Task Description: When copying a chart in a spreadsheet, the link to the Odoo menu is not kept This PR aims to fix it by taking advantage of the new clipboard refactoring, with a new clipboard handler saving the odooMenuLink in the clipboard data and putting it back in the newly created chart. ## Related Task: - Task: 3380568 - https://github.com/odoo/o-spreadsheet/pull/3670 Forward-Port-Of: odoo/enterprise#58564
The Colombian e-invoicing module now shows the company’s economic activity field on the company form. It also prepares the settings layout so future DIAN-related configuration can hide older Carvajal options when needed.
Original PR description
Add the `l10n_co_edi_header_actividad_economica` in the company form view. In addition, enclose the Carvajal settings inside a named <t> such that it can easily be manipulated in l10n_co_dian (yet to be merged): if we use DIAN from l10n_co_dian, we will hide Carvajal settings. task-3141517
Expense reports now create draft accounting moves and payments when they are approved, instead of waiting until the report is posted. This gives accounting teams more control to review and manage taxes before entries are finalized.
Original PR description
This moves the creation of account.move at the approval step of an expense report. Allowing better accounting tax management Before this change: The moves & payments were created & posted when posting the expense report After this change: Approving the report creates draft account moves & payments Posting the report post the accounting entries task-id: 3943064
After a subscription renewal is confirmed, the related renewal buttons are now hidden so users no longer see actions that are no longer available. This makes the subscription screen clearer and reduces confusion for sales teams managing renewals.
Original PR description
Before this commit, upon confirming the renewal in a subscription, the subscription would be locked and the button would still remain visible. In this commit, a condition is added to make these buttons invisible once the renewal is confirmed. task-3927499
The Gantt view controls have been reorganized to make date selection, today navigation, scale changes, and action buttons easier to use. Slider tracks are also now visible in dark mode, improving readability for users working with that theme.
Original PR description
**[IMP] web_gantt,planning: gantt controls style** This commit aims to improve the usage of the new gantt renderer's controls, introduced in [1]. Changelog: - the date pickers are now styled as…
**[IMP] web_gantt,planning: gantt controls style** This commit aims to improve the usage of the new gantt renderer's controls, introduced in [1]. Changelog: - the date pickers are now styled as buttons, like it was already the case in small displays - the today button now sits next to the date pickers - the scale selector slider now sits next to the today button and has now a min and max width. - the other buttons now sit next to the scale slider - the planning's customization is fixed to the right and may overlap the other controls. Since it is only visible while dragging a pill (only on medium or large sized displays) it is acceptable. [1]: https://github.com/odoo/enterprise/pull/55618 _Before_   _After_   **[FIX] web_enterprise: slider track in dark mode** Before this commit the input type range slider track is invisible in dark mode. After this commit the color of slider's tracks are now visible. _Before_  _After_ 
Helpdesk SLA policies can now be linked directly to service products, so the right SLA is applied when a related sales order line is selected on a ticket. The change also removes the product workspace setup from Documents Project Sale, simplifying product configuration.
Original PR description
### 1) [IMP] helpdesk_sale_timesheet: improve sla flow Before this commit in order to work with SLA then we either have to set SLA on product and this will set that product related SOL to SLA policy automatically with SO confirms and apply SLA policy to related ticket or find related SOL we need to apply SLA policy and then set it to SLA. This commit add product_ids field in SLA policy where user can set proudct directly on SLA policy And when user select SOL on ticket related to this product then it'll set SLA policy on product. ### 2) [REM] document_project_sale: remove workspace from product This commit remove workspace field from product and related code. task-3938198
Mobile field service screens are streamlined so onsite workers see fewer administrative fields while working at customer locations. This helps technicians focus on essential task information and reduces navigation complexity on mobile devices.
Original PR description
_*= industry_fsm_report, industry_fsm_sale, project_enterprise, project_holidays PURPOSE ---------- Onsite workers have difficulty navigating field service on mobile. In this work, we will hide non-essential fields from onsite workers especially on mobile so that they can focus on what matters. Indeed, some fields are purely administrative and there is no reason to modify them once at the customer's place. task-3784066
Users can now move between reporting periods in accounting reports using simple arrows instead of repeatedly opening the calendar. This makes comparing adjacent periods faster and smoother for finance teams.
Original PR description
Date selection is not particularly user-friendly in account reports. A user may want to quickly navigate between similar periodicity going from one to the next in a smooth way instead of using calendar. This PR add a way to navigate between periods using arrows. task-id: 3482119
Financial reports no longer use the confusing "normal" date scope except where its special behavior is specifically needed. This makes report definitions more consistent across countries and reduces the risk of unexpected balances in standard financial statements.
Original PR description
We remove the `normal` date_scope. The 'normal' date scope is relatively tricky to use: - it treats Balance Sheet and Profit and Loss accounts differently, which means that a separate line is usually…
We remove the `normal` date_scope. The 'normal' date scope is relatively tricky to use: - it treats Balance Sheet and Profit and Loss accounts differently, which means that a separate line is usually needed to collect the residual Profit and Loss account balance into a line, usually `999999 Unaffected Earnings`. - This is only done in two custom reports, the General Ledger and Trial Balance. - We prefer to localize this tricky behaviour to those two custom reports, and remove the `normal` date scope elsewhere. For most uses, the `normal` date scope can be replaced by the `strict_range` (the default for reports): - in aggregation / external formulas (date scope has no effect) - on account_code / domain formulas for P&L accounts, in reports with filter_date_range=True (e.g. P&L or tax reports) - on account_code / domain formulas for Balance Sheet accounts, in reports with filter_date_range=False (e.g. Balance Sheet reports) Community PR: https://github.com/odoo/odoo/pull/155614 Upgrade PR: https://github.com/odoo/upgrade/pull/5754 taskid: 3177283
The return workflow now hides the 'Return for Exchange' button for rental orders, reducing confusion for users handling rental stock returns. Related stock return flows in delivery, helpdesk, subscription, and barcode modules were aligned with this behavior for consistency.
Original PR description
In this commit: =============== Hide button `Return for Exchange` for rental orders. Task - 3543473 Community PR: odoo/odoo#153184
Knowledge now lets users search within article content, not just article titles. This makes it faster to find relevant information across large documentation collections, especially when users do not know which article contains the answer.
Original PR description
Knowledge is a wonderful tool for gathering, organizing and sharing documentation with collegues. With this module, people can easily create rich documents that help them in their day-to-day jobs.…
Knowledge is a wonderful tool for gathering, organizing and sharing documentation with collegues. With this module, people can easily create rich documents that help them in their day-to-day jobs. Currently, Knowledge lacks an effective search feature. The existing search functionality only searches documents based on their titles and cannot search within the document content. This commit will implement a new search feature for Knowledge that will enable people to quickly find the information they need within a large collection of documents. This new feature will save a significant amount of time for users who are unsure which specific document contains the information they need. ## Technical The search feature will work like a small search engine: People will have to type a few words or a sentence and the system will retrieve the documents that match the most with those keywords. To implement that search feature, we will use the build-in "Full Text Search" feature of PostgreSQL. By leveraging this feature, the database will do all the heavy lifting for us: It will be able to automatically encode the documents in a vector space, apply stemming on the words, include statistical measures to evaluate the similarity between a document and a query, strip the html tags, highlight the piece of text containing the search terms, etc. Reference: https://www.postgresql.org/docs/15/textsearch.html task-3071299
This fixes an error that could occur when importing bank transaction data through online synchronization. The update ensures company information is handled correctly, allowing bank statement lines to be created without interruption.
Original PR description
"company_id" has been added to data retrun by "_format_transactions" method in https://github.com/odoo/enterprise/commit/393ca019515757c275df17b9319198f18471af60. This would cause an error when creating a new "account.bank.statement.line.transient". This commit adds company_id as field on account.bank.statement.line.transient.
Manufacturing and product documents are now managed through one shared document system instead of a separate manufacturing-specific model. This makes documents easier to access from engineering change orders and ensures teams can see all product-related files in one place.
Original PR description
In https://github.com/odoo/odoo/pull/132739, the introduction of product documents generalized the previous document approach used in MRP. This commit removes the existing mrp_document model and merge it's data and behaviour with the product document one. In addition, we now allow the eco record to have access to all the documents related to the product instead of only the one related to the eco record. task-id: 3649991 closes: https://github.com/odoo/enterprise/pull/55634 community: https://github.com/odoo/odoo/pull/152286 upgrade: https://github.com/odoo/upgrade/pull/5622
Add a setup allowing you to easily create xmls at today date and switch from external to standard mode. That way, in external mode, the XMLs are really send to the SAT in order to ensure their validity. community PR: https://github.com/odoo/odoo/pull/163938 Forward-Port-Of: odoo/enterprise#63170 Forward-Port-Of: odoo/enterprise#61741
Original PR description
Add a setup allowing you to easily create xmls at today date and switch from external to standard mode. That way, in external mode, the XMLs are really send to the SAT in order to ensure their validity. community PR: https://github.com/odoo/odoo/pull/163938 Forward-Port-Of: odoo/enterprise#63170 Forward-Port-Of: odoo/enterprise#61741
This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. ta
Original PR description
This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. task-3933062 Forward-Port-Of: odoo/enterprise#62649
Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into accoun
Original PR description
Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into account changes of amount, but not changes of length. We don't have a good way to incorporate changes of length in the old computation. To fix this, for linear, we consider the original amount from the beginning/the reevaluation to compute the amount for each period. It does not hold for degressive_then_linear, so we separate the logic. opw-3811165 Forward-Port-Of: odoo/enterprise#62377
l10n_br_edi_services defines l10n_br_property_service_code_origin_id on product.template. It's a property field, so to ensure it's read correctly by ir_cron_account_move_send that runs as OdooBot we explicitly set the company for the entire flow. Although not strictly needed in l10n_br_edi, fixing it here is the cleanest and most complete. The *_services modules will be merged into the main ones anyway. task-3887264 Forward-Port-Of: odoo/enterprise#63110
Original PR description
l10n_br_edi_services defines l10n_br_property_service_code_origin_id on product.template. It's a property field, so to ensure it's read correctly by ir_cron_account_move_send that runs as OdooBot we explicitly set the company for the entire flow. Although not strictly needed in l10n_br_edi, fixing it here is the cleanest and most complete. The *_services modules will be merged into the main ones anyway. task-3887264 Forward-Port-Of: odoo/enterprise#63110
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to Configuration > Operation Types > Delivery Orders - Enable Product in the Barcode App - Go to the barcode app > Operations > Delivery Orders and click on New - Scan 123 - Scan aaa (or bbb it probably depends on order of creation of product) - Scan 123 Issues: bbb has been added even though we
Original PR description
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to…
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to Configuration > Operation Types > Delivery Orders - Enable Product in the Barcode App - Go to the barcode app > Operations > Delivery Orders and click on New - Scan 123 - Scan aaa (or bbb it probably depends on order of creation of product) - Scan 123 Issues: bbb has been added even though we never scanned it. The reason for this bug is that when we scan 123 we don't have it in the cache as such we make an RPC and store 123 in `missCache`. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185 After this when we scan aaa we retrieve the record, and add the line as intended. The problem arise when we scan 123, since it's already in our cache. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130 However that record is not right since this lot is linked to the wrong product bbb. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138 We will try to retrieve again the right record, however we will once again get a hit on the cache. As such no RPC call will be made to retrieve the lot we're looking for. We will go in the function once again, where we will have the same problem this time in the `if (model)` condition. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115 Later in the execution we will get to this line where we call the function without a filters which will allow the wrong record to be added. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943 The root of this problem lies in the way we set the key to the cache, since two product can share the same barcode we need a more precise cache key to differentiate them. The proposed solutions is to cache result based on the provided arguments to the function. This means fewer hit if we retrieve the same record with different filter for example, however it's safer as when we hit we are sure to get the right record. opw-3862263 Forward-Port-Of: odoo/enterprise#63094 Forward-Port-Of: odoo/enterprise#61844
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue. How to reproduce: - Inventory -> Settings -> Enable "Multi-Step Routes
Original PR description
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But…
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue. How to reproduce: - Inventory -> Settings -> Enable "Multi-Step Routes"; - Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments; - Go to the Barcode App > Operations > Internal Transfers > New; - In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT) - :arrow_right: An error message is displayed because you are not allowed to scan this location. The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d. Also, fix a minor unrelated bug where locations on the barcode line are not correctly written when there name include the picking's defaut location's name (eg.: WH/Stock 2 when the default location is WH/Stock.) [OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#63058 Forward-Port-Of: odoo/enterprise#62480
Before this commit: The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app. opw-3891923 Forward-Port-Of: odoo/enterprise#62663
Original PR description
Before this commit:
The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app.
opw-3891923
Forward-Port-Of: odoo/enterprise#62663### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on Delivery Validation" 2) Multi-Step Routes - Go to Inventory > Configuration > Warehouse Management > Locations - Create a new Location SHELF with COMP1/STOCK as parent - Go to Inventory > Configuration > Warehouse Management > Putaway Rules - Create a new putaway r
Original PR description
### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on…
### Steps to reproduce:
With company 1:
- Go to the General Settings and activate:
1) Inter-Company Transactions:
- "Synchronize Sales and Purchase Order"
- "Automatic Validation"
- "Copy Lots on Delivery Validation"
2) Multi-Step Routes
- Go to Inventory > Configuration > Warehouse Management > Locations
- Create a new Location SHELF with COMP1/STOCK as parent
- Go to Inventory > Configuration > Warehouse Management > Putaway Rules
- Create a new putaway rule applicable to all products from COMP2/STOCK to COMP2/STOCK/SHELF
With company 2:
- Create a storable product tracked by a Unique Serial Number
- Click on "On Hand" > Register 1 on hand qty with a new serial Number
- Create and confirm an SO for company 2 with your product
At this point, if you go to company 1:
A purchase order related to the SO was created and confirmed. If you open the related delivery and inspect the related stock move line the destination, it will correctly be set to COMP1/STOCK/SHELF.
With company 2:
- Open the delivery linked to your SO click on the list icon of you stock move line
- Add a stock picking referencing the serial number you created
- Validate the delivery
If you go to company 1, the move line is now attached with a serial number but the destination is set to set to COMP1/STOCK.
#### > The putaway rule is not applied anymore
### Cause of the issue:
When you confirmed the SO with company 2, it will create an PO in company 1:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/sale_order.py#L22 and a related stock move will then be created. During the "_action_confirm" of this stock move the putaway rules will be applied to the stock move lines a few lines after creation: https://github.com/odoo/odoo/blob/58fefc94ca39f7951392063921fe9b5e606178e6/addons/stock/models/stock_move.py#L1720 When you confirm the delivery, this correclty set stock move line will be deleted and a new one will be created:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/stock_picking.py#L30-L33 However, as the "apply_putaway_strategy" method is not called after the creation of this newly created stock move line, the destination of the line will entirly be set by the destination of the stock move: https://github.com/odoo/odoo/blob/42b760c8fa27cfc75fcb2fd5b232defc9002e85f/addons/stock/models/stock_move.py#L1441 so that the put away rules will not be applied anymore.
opw-3744375
Forward-Port-Of: odoo/enterprise#62547
Forward-Port-Of: odoo/enterprise#60161Steps to reproduce: ------------------- - Install `Documents` module - Go to Documents -> Configuration -> Workspaces - Create a workspace with a sub workspace - Go to list view Issue: ------ The display name of the sub workspace is not correct; It should also add the parent workspace name in the display name. Cause: ------ The following commit added a second `_compute_display_name` method that override the flow that add the parent workspace to the sub workspace name. https://
Original PR description
Steps to reproduce: ------------------- - Install `Documents` module - Go to Documents -> Configuration -> Workspaces - Create a workspace with a sub workspace - Go to list view Issue: ------ The display name of the sub workspace is not correct; It should also add the parent workspace name in the display name. Cause: ------ The following commit added a second `_compute_display_name` method that override the flow that add the parent workspace to the sub workspace name. https://github.com/odoo/enterprise/commit/ca7efce8f7bdb497f39a8438b5c266a7861d9a92 Solution: --------- Merge the 2 `_compute_display_name`. opw-3835887 Forward-Port-Of: odoo/enterprise#63082 Forward-Port-Of: odoo/enterprise#62759
This PR will be the targeted PR for all changes relating to the second version of the website generator. Forward-Port-Of: odoo/enterprise#52155
Original PR description
This PR will be the targeted PR for all changes relating to the second version of the website generator. Forward-Port-Of: odoo/enterprise#52155