Wednesday, September 20, 2023
38 changes · master
Enhancements to existing features
Warehouse and manufacturing users can now edit detailed stock operations directly within the main record instead of opening separate pop-up workflows, reducing waiting time and unnecessary server calls. The update also improves immediate transfer handling, serial number generation, availability checks, and reservation behavior so stock quantities are clearer and more reliable before validation.
Original PR description
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
Event managers can now access revenue reports that show how much income each event and ticket type generates. This makes it easier to identify the most profitable events and tickets when sales features are installed.
Original PR description
As an event manager, it can be difficult to estimate how much of the revenue was generated by the events. To give clear insights, we will add new reports to the 'event' module. With those new reports, the user can group the revenues by event and/or by ticket. The user will then be able to quickly see which tickets and events are the most profitable ones. The reports will be accessible only if the user installed the 'sale' module. task-2679881 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Colombian tax labels have been updated to be easier to understand in both English and Spanish. This helps users identify the correct tax more quickly and reduces confusion when working with localized accounting records.
Original PR description
Before the change - Tax Names were not intuitive or easily understandable for the users, it was hard to relate which tax was referenced with each name. - The Name didn't include the Spanish translation, regardless the name is encoded now, it should be encoded based on the Spanish description. After the change: - Tax names(codes) both in English and Spanish are more intuitive and easier to understand for the users. - Tax names have better matching with the description. task-3475793 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The CRM lead and opportunity form now uses screen space more effectively by expanding the internal notes editor and grouping key fields more compactly. This makes it easier for sales users to focus on qualification notes while still seeing priority, salesperson, and team information clearly.
Original PR description
When the user opens the CRM form view, there will be unusable space below the internal notes. To improve the UX, we will automatically resize the editor to fill the gap between the form view and the outer window. We will also reorder some fields: - The priority will be put next to the title. - The salesperson and the team will be put next to each other on the same line. By reordering the fields, the fields will take less vertical space and there will be more emphasis on the internal notes which is the most important field of the view as it helps the user qualifying the lead or the opportunity. task-2677144 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website previews now show the livechat button, matching what visitors see on the published site. This makes previews more accurate and removes an unstable automated check that was no longer needed.
Original PR description
The livechat button was disabled in website preview because its implementation could not properly handle being in an iframe inside the backend [1]. With the public livechat code being refactored to use discuss code, this is no longer a problem, so the livechat button can be present again. This also makes previewing the website more correct: the livechat button is actual present on the website, so hiding it was a lie. By re-enabling the livechat button, this also allow to remove the test coverage by a tour, which was sometimes failing on runbot due to tour being small and doing `im_livechat/init` rpc after the end of the tour. [1]: https://github.com/odoo/odoo/commit/e86c1ce94a148745d58ac38e408e1bc947978670 runbot-24631
This update helps Danish companies comply with new regulations by preventing changes to posted sales and purchase journal entries. Once entries are posted, they are protected with a forced locking mechanism to preserve accounting integrity.
Original PR description
Following new regulations in Denmark, we need to prevent users from modifying posted entries in sales and purchase journals. By using a forced hash on the journals we do just that. [task-3497062](https://www.odoo.com/web#id=3497062&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project stages can now be configured separately for each company, instead of being shared across all companies. This helps multi-company organizations keep project workflows aligned with each company's processes and improves data separation.
Original PR description
Adding a company_id field in project.project.stage will allow companies to have their own individual stages, which was not possible before since all the stages were shared between all companies. task-3330285
Mexican tax records now include a dedicated tax type used when generating and importing CFDI e-invoice attachments. This reduces reliance on tax label names, making electronic invoicing data handling more consistent and less error-prone.
Original PR description
Add a selection field `l10n_mx_tax_type` on account.tax. This field is used in the CFDI attachment. This allows to avoid relying on the name of the repartition line tags to export and import a CFDI. enterprise: https://github.com/odoo/enterprise/pull/47321 upgrade: https://github.com/odoo/upgrade/pull/5136 task-3388347
This update removes outdated browser checks that caused unnecessary startup errors in developer tools. It makes debugging Odoo web pages smoother without affecting supported browsers, since the removed checks only targeted very old browser versions.
Original PR description
To test which browser is currently running, jquery performs some checks when it starts, by doing invalid queryselectors. Depending on which selectors crashes, it can determinate if it is running in…
To test which browser is currently running, jquery performs some checks when it starts, by doing invalid queryselectors. Depending on which selectors crashes, it can determinate if it is running in an old browser and need to activate some part of the code to support them. This would not be a big deal, except that it makes the life of some developers much more difficult: we can no longer easily reload a page with a "Pause on exception" setting to debug odoo. Doing so works, but the workflow is polluted by 3 errors initially. It is so common that I propose to simply remove the checks. This should be acceptable, since Odoo does not work on old browser versions anyway We are talking about firefox 5, opera 11 or "Gecko", for a commit that is at least 11 years old 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
Businesses in Mexico can now import CFDI XML files directly from accounting dashboards or invoice-related views to create the matching accounting documents. The change also improves tax classification reliability and cancellation handling, reducing manual entry and supporting standard CFDI workflows.
Original PR description
community: https://github.com/odoo/odoo/pull/135215 upgrade: https://github.com/odoo/upgrade/pull/5136 task-3388347
Salary package pages now display currency symbols in the correct position for each currency, instead of always showing them on the right. This makes compensation information clearer and more familiar for users in different countries.
Original PR description
Currently the currency symbol is visible on the right side. in this commit, We show based on the currency position. task-3382081
Resolved issues and error corrections
This fixes a display issue in Marketing Automation where the dropdown in the launch test modal could appear with no usable width. Users can now see and use the selector as intended when preparing a test launch.
Original PR description
Description of the issue/feature this PR addresses: In the marketing automation module, the dropdown of the 'launch test' modal is not fully visible because a css rule forces the field of having a width of 0 (see: `width: 0!important`). Current behavior before PR: The dropdown has a width of 0 which makes the field unusable. Desired behavior after PR is merged: The dropdown is fully visible. Task id: 2572330 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The Point of Sale ticket screen now uses the standard double-click behavior to reopen orders for editing. This reduces custom handling behind the scenes, making the feature easier to maintain and less prone to errors without changing the user workflow.
Original PR description
In the ticket screen the user has the option to double click on an
order in order to continue editing it. This functionality is implemented
using custom code for handling the double click. This is cumbersome and
error prone.
In this PR we replace the custom double click logic with the default
`t-on-dblclick` from `owl`.
Task: 3512282
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMiscellaneous changes
This commit gathers the different parts of the content from the many2one confirmation dialog into a single _t in order to facilitate the foreign translations of the content Forward-Port-Of: odoo/odoo#135294
Original PR description
This commit gathers the different parts of the content from the many2one confirmation dialog into a single _t in order to facilitate the foreign translations of the content Forward-Port-Of: odoo/odoo#135294
Dropdown menus in the website editor now automatically scroll into view when opened near the bottom of the side panel. This removes the need for users to manually scroll to find menu options, making page editing smoother.
Original PR description
Whenever an option is at the bottom of the right panel and displays a dropdown to select an option, it's kind of opening off screen, you then actually need to scroll down to see the dropdown. After this commit, it will automatically scroll down to ensure the dropdown menu is fully visible, so the user won't have to scroll manually. task-3500768
The payment provider setup forms once again allow users to duplicate existing providers. This restores a useful option that had been removed unintentionally, helping teams create similar payment configurations more efficiently.
Original PR description
This reverts commit 5fd345e. The duplicate option was removed but it should be available.
When Social has no connected accounts and users group posts by stream, the page now shows the expected 'No Stream Added yet!' guidance instead of a blank screen. This makes the empty state clearer and helps users understand what action is needed next.
Original PR description
Before this commit: Open Social with no account connected. Select the 'By Stream' filter from Group By. We see an empty screen. We have to make this change following the changes introduced in the file `kanban_controller.js` in the PR --> https://github.com/odoo/odoo/pull/114024 Technical reason: https://github.com/odoo/enterprise/blob/master/social/static/src/js/stream_post_kanban_renderer.js#L50-L52 The method `get showNoContentHelper()` in the code above, returns `!model.hasData()` which has the model value as `KanbanSampleModel`. The `hasData()` returns `true` when the group by is applied even with empty data. And hence the issue. We now use the method `useModelWithSampleData` to pass the model value as `StreamPostKanbanModel`. After this commit: We can see the 'No Stream Added yet!' helper. task-3468029
Spreadsheet dialogs were simplified by using standard confirmation prompts where possible and removing unused dialog behavior. This also fixes an issue where cancelling a list reinsertion could cause an error, improving reliability for spreadsheet users.
Intent of checking `group_no_one` was always to query the advanced info / debug mode, however when the semantics of group_no_one got changed in 31518bc09b1ae2be37c3555799e2c122f0a4dbcd this site was missed, and now always displays "advanced" errors for internal users. Which was not the intent. Also since we're printing `display_name` and some of them annoyingly hook onto context variables to show extended information, reset the context to the user's default in order to avoid such extended-for
Original PR description
Intent of checking `group_no_one` was always to query the advanced info / debug mode, however when the semantics of group_no_one got changed in 31518bc09b1ae2be37c3555799e2c122f0a4dbcd this site was missed, and now always displays "advanced" errors for internal users. Which was not the intent. Also since we're printing `display_name` and some of them annoyingly hook onto context variables to show extended information, reset the context to the user's default in order to avoid such extended-formatting `display_name`. Forward-Port-Of: odoo/odoo#135855 Forward-Port-Of: odoo/odoo#135028
Prior to this commit when various tabs of self order were opened in the same navigator, tabs were not synchronised. If an order from one of them was sent, this will add a draft order to the localStorage, but the second tab is not informed of this change, as it doesn't reload its localStorage. In this commit we make sure that when new self order tab is opened, if others tabs are opened with self order, they will be redirected to the menu without the access tokens. No order could be made on the
Original PR description
Prior to this commit when various tabs of self order were opened in the same navigator, tabs were not synchronised. If an order from one of them was sent, this will add a draft order to the localStorage, but the second tab is not informed of this change, as it doesn't reload its localStorage. In this commit we make sure that when new self order tab is opened, if others tabs are opened with self order, they will be redirected to the menu without the access tokens. No order could be made on the other tabs. In this commit we also add the "order" prefix to order acces_tokens so that there is no confusion with the acces_tokens of the self_order. task-3444796 Forward-Port-Of: odoo/odoo#133626
[FIX] repair: clean default keys from the context before creating stock.move Steps to reproduce the bug: - Create a storable product “P1” - Create a Transfer: - Operation type: delivery order - Product: “P1” - Validate the delivery - Create a return of the delivery: - Confirm and validate the return - Create a repair order from the delivery - Set the product “P1” - Confirm, start and end the repair Problem: A stock move is created when the repair is
Original PR description
[FIX] repair: clean default keys from the context before creating stock.move Steps to reproduce the bug: - Create a storable product “P1” - Create a Transfer: - Operation type: delivery order -…
[FIX] repair: clean default keys from the context before creating stock.move
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a Transfer:
- Operation type: delivery order
- Product: “P1”
- Validate the delivery
- Create a return of the delivery:
- Confirm and validate the return
- Create a repair order from the delivery
- Set the product “P1”
- Confirm, start and end the repair
Problem:
A stock move is created when the repair is completed, but it's linked to the return picking what is wrong.
When a 'repair' order is created, the 'default_picking_id' is passed into the context to be set in the 'repair.order'. Consequently, when the repair is completed and the stock move is created, the context isn't cleared, leading to the utilization of the 'default_picking_id':
https://github.com/odoo/odoo/blob/5d25900cd88ebc1fd16b0bd6ebba4602a13e9d76/addons/stock/models/stock_move.py#L317
In the button, no context is passed as a parameter:
https://github.com/odoo/odoo/blob/86aa7b78aadee5747c93b4bd27046cfaed1e438d/addons/repair/views/repair_views.xml#L36
opw-3269813
Forward-Port-Of: odoo/odoo#131798
Forward-Port-Of: odoo/odoo#131681How to reproduce: - open CRM > Forecast - group by Expected Closing > Week Current behavior: - some week numbers appear multiple times Expected behavior: - each week should only appear once Technical explanation: Since [1], week groups are dependent on the locale, but the `_read_group_fill_temporal` method was not updated to also produce groups dependent on the locale. [1]: https://github.com/odoo/odoo/pull/93053 task-3478451 Forward-Port-Of: odoo/odoo#135344 Forward-Port-
Original PR description
How to reproduce: - open CRM > Forecast - group by Expected Closing > Week Current behavior: - some week numbers appear multiple times Expected behavior: - each week should only appear once Technical explanation: Since [1], week groups are dependent on the locale, but the `_read_group_fill_temporal` method was not updated to also produce groups dependent on the locale. [1]: https://github.com/odoo/odoo/pull/93053 task-3478451 Forward-Port-Of: odoo/odoo#135344 Forward-Port-Of: odoo/odoo#133062
Before this commit, both the "Edit" (in main lang) and "Translate" (in alternate lang) button in the website navbar had a vertical alignment issue. This was because, despite having the same font style and font size, they had a different line-height making it glitch 1-2px vertically. It's a bit less visible for the Edit button as there is a pencil icon between this text and the text next to it. For the translate button, it's quite visible directly. For testing purpose, you can simpl
Original PR description
Before this commit, both the "Edit" (in main lang) and "Translate" (in alternate lang) button in the website navbar had a vertical alignment issue. This was because, despite having the same font…
Before this commit, both the "Edit" (in main lang) and "Translate" (in alternate lang) button in the website navbar had a vertical alignment issue. This was because, despite having the same font style and font size, they had a different line-height making it glitch 1-2px vertically. It's a bit less visible for the Edit button as there is a pencil icon between this text and the text next to it. For the translate button, it's quite visible directly. For testing purpose, you can simply remove the icons and the left-right margins of those systray items so the text are glued to each other and you clearly see the misindentation. For tracking purpose, there is multiple cases to be tested regarding those buttons: - Community vs Enterprise (where those are colored) - Regular mode vs translate mode | Use Case | Issue + Screenshot | | -- | -- | | **Regular Mode CE** | Not enough horizontal spacing between items + **"Edit" text is not vertically align**| | Before |  | | After |  | | **Regular Mode EE** | Not enough horizontal spacing between items | | Before |  | | After |  | | **Translate Mode CE** | Not enough horizontal spacing between items + **"Translate" text is not vertically align** | | Before |  | | After | | | **Translate Mode EE** | Not enough horizontal spacing between items | | Before | | | After | | Forward-Port-Of: odoo/odoo#131228
The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary. A check has been added on the company's country to be 'IT'. Task link: https://www.odoo.com/web#id=3420752&model=project.task task-3420752 Forward-Port-Of: odoo/odoo#130042
Original PR description
The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary. A check has been added on the company's country to be 'IT'. Task link: https://www.odoo.com/web#id=3420752&model=project.task task-3420752 Forward-Port-Of: odoo/odoo#130042
The `_computeUnclaimedFreeProductQty` method was not properly computing reward quantities for order type rules. This commit fixes the computation to handle order type rules separately, allowing free product rewards to be granted as expected. The computation now also takes into account which rules were actually used when calculating points. It will ignore any rules that were not used in the points calculation when determining free product rewards. This ensures the rewards match the rules that
Original PR description
The `_computeUnclaimedFreeProductQty` method was not properly computing reward quantities for order type rules. This commit fixes the computation to handle order type rules separately, allowing free product rewards to be granted as expected. The computation now also takes into account which rules were actually used when calculating points. It will ignore any rules that were not used in the points calculation when determining free product rewards. This ensures the rewards match the rules that contributed to points for the order. opw-3492083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135800 Forward-Port-Of: odoo/odoo#134557
## Issue After https://github.com/odoo-dev/odoo/commit/213b6885312f3da3bf5bff995861758a1afcde76, some custom filters on tags can throw a stacktrace. ## Steps to reproduce - Install Project - Project > Custom Filter > Tags contains 'Internal' - Stacktrace ## Cause When `limit=None`, which is explicitly set when creating custom filters, the `name_search` crashes when comparing an `int` (the len (ids)) with the limit which is `None`. ## Fix Elaborate the condition to handle the case
Original PR description
## Issue After https://github.com/odoo-dev/odoo/commit/213b6885312f3da3bf5bff995861758a1afcde76, some custom filters on tags can throw a stacktrace. ## Steps to reproduce - Install Project - Project > Custom Filter > Tags contains 'Internal' - Stacktrace ## Cause When `limit=None`, which is explicitly set when creating custom filters, the `name_search` crashes when comparing an `int` (the len (ids)) with the limit which is `None`. ## Fix Elaborate the condition to handle the case when `limit=None`. ## Affected versions 16.0 up to master ## Reference opw-3510309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135871 Forward-Port-Of: odoo/odoo#135761
Previously, when a view contained an x2m field that had a few thousand records, the view would take ages to load. This was caused by a few things in the basic model where we would linearly scan lists of records in a tight loop, and doing so for every single other record, causing quadratic increase runtime with regards to the number of records. For example, creating a new batch picking in stock with 4000 existing pickings would take up to ~20 seconds to load the view. This commit creates a few
Original PR description
Previously, when a view contained an x2m field that had a few thousand records, the view would take ages to load. This was caused by a few things in the basic model where we would linearly scan lists of records in a tight loop, and doing so for every single other record, causing quadratic increase runtime with regards to the number of records. For example, creating a new batch picking in stock with 4000 existing pickings would take up to ~20 seconds to load the view. This commit creates a few objects to use as lookup tables in such places, which speeds up the loading of the view to less than a second. It also makes the context of the DataPoint into a property that's initialized lazily on first read, as creating a context and the corresponding evalContext can be expensive, which becomes a problem when creating thousands of DataPoints whose context will never be read. opw-3465073 Forward-Port-Of: odoo/odoo#135953 Forward-Port-Of: odoo/odoo#135860
There were 2 errors fixed by this commit: 1. The form registry fields added in [1] and [2] in Odoo 13 had a `string` attribute translated with `_t()` while now it should be translated with `_lt()`. It was surely working in Odoo 13 but not anymore. It's not worth investigating to be sure. 2. The IMP done at [3] added a lot of fields but all of those forgot the `_t()`/`_lt()` translation. Note that: 1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done a
Original PR description
There were 2 errors fixed by this commit: 1. The form registry fields added in [1] and [2] in Odoo 13 had a `string` attribute translated with `_t()` while now it should be translated with `_lt()`. It was surely working in Odoo 13 but not anymore. It's not worth investigating to be sure. 2. The IMP done at [3] added a lot of fields but all of those forgot the `_t()`/`_lt()` translation. Note that: 1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done as it was not targetting the correct version... and only fixed one of many occurences. [1]: https://github.com/odoo/odoo/pull/32565 [2]: https://github.com/odoo/enterprise/pull/4063 [3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee [4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687 opw-3471873 Forward-Port-Of: odoo/odoo#134213 Forward-Port-Of: odoo/odoo#132975
Before this commit ================== Negative discounts could be applied to products, which is not allowed in Indian EDI. After this commit ================== Applied conditions to check for negative discounts and raise an error in case of such discounts. task_id: 3293247 Forward-Port-Of: odoo/odoo#120218
Original PR description
Before this commit ================== Negative discounts could be applied to products, which is not allowed in Indian EDI. After this commit ================== Applied conditions to check for negative discounts and raise an error in case of such discounts. task_id: 3293247 Forward-Port-Of: odoo/odoo#120218
Steps to reproduce: - Go to `/blog`. - Enable "Show Sidebar" in the "Customize" menu. - Edit the page. - Click on an icon of the "Follow Us" section of the sidebar. - Click on the "Link" icon of the editor toolbar. => An error popup appears. In further versions, the link parameters can be edited - but they are lost upon save. The social media links sections of the blog and blog post pages is generated and is not supposed to be editable. This commits makes these social media link
Original PR description
Steps to reproduce: - Go to `/blog`. - Enable "Show Sidebar" in the "Customize" menu. - Edit the page. - Click on an icon of the "Follow Us" section of the sidebar. - Click on the "Link" icon of the…
Steps to reproduce: - Go to `/blog`. - Enable "Show Sidebar" in the "Customize" menu. - Edit the page. - Click on an icon of the "Follow Us" section of the sidebar. - Click on the "Link" icon of the editor toolbar. => An error popup appears. In further versions, the link parameters can be edited - but they are lost upon save. The social media links sections of the blog and blog post pages is generated and is not supposed to be editable. This commits makes these social media links sections non editable. If a user needs to configure such a content specifically, it can be done inside the "About Us" section of the sidebar above. E.g.: - Deactivate the "Follow Us" section from the "Customize" menu. - You can use copy/paste to duplicate the existing style of the "About Us" section if you want. - Click on the "File / Image" icon of the editor toolbar (or type "/image" to use the Power Box as of 15.0). - Select a pictogram. - Click on the "Shape: Circle" icon of the editor toolbar. - Select the "Font Color" from the editor toolbar. - Click on the "Link" icon of the editor toolbar to specify an URL. opw-3450880 Forward-Port-Of: odoo/odoo#133052 Forward-Port-Of: odoo/odoo#131058
Previous fix https://github.com/odoo/odoo/pull/121602 did not correctly handle the case when not all of the qty to manufacture is manufactured (the qtys to change to were miscalculated in this case). Additionally, it missed fixing a few more use cases when setting the qtys to match the wizard's lines/qtys: - if the UoM of a MO's component line is changed => the correct qty was not correctly converted into the move.product_uom's qty (now it is) - if a component's move is deleted before
Original PR description
Previous fix https://github.com/odoo/odoo/pull/121602 did not correctly handle the case when not all of the qty to manufacture is manufactured (the qtys to change to were miscalculated in this case).…
Previous fix https://github.com/odoo/odoo/pull/121602 did not correctly handle the case when not all of the qty to manufacture is manufactured (the qtys to change to were miscalculated in this case). Additionally, it missed fixing a few more use cases when setting the qtys to match the wizard's lines/qtys: - if the UoM of a MO's component line is changed => the correct qty was not correctly converted into the move.product_uom's qty (now it is) - if a component's move is deleted before the MO is confirmed => the move (i.e. the missing component) was not correctly added back into the MO (now it is) - if there are 2 MO component moves with the same product => both were set to the same "correct qty" value (now we only set the first move to that qty, others are set to 0 since we have no way of knowing how to distribute the qtys otherwise) Also, since an UserError needed to be added in case of a missing comp move for a tracked product, existing error logic has been updated to list all applicable products and the message has been improved to be more helpful. Note that the fix for saas-16.4 and earlier is slightly different from this fix due to the change in how stock move original demand qtys no longer change like they used to (see: https://github.com/odoo/odoo/pull/130342) and because a backorder bug was also exposed by this change. Task: 3456604 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135715 Forward-Port-Of: odoo/odoo#131279
### Allows to export OIOUBL invoice and refund from Odoo [[IMP] {l10n_}account_edi_ubl_cii{_tests}: OIOUBL export](https://github.com/odoo/odoo/pull/128049/commits/c45d68cfa4a626c2a49c746a787b19a43a62e252) The aim of this commit is to support OIOUBL format export in order to comply with the Danish accountancy act. Before this commit: OIOUBL isn't a supported format in Odoo After this commit: It is possible to generate oioubl document for invoice and credit-note Current limitat
Original PR description
### Allows to export OIOUBL invoice and refund from Odoo [[IMP] {l10n_}account_edi_ubl_cii{_tests}: OIOUBL…
### Allows to export OIOUBL invoice and refund from Odoo
[[IMP] {l10n_}account_edi_ubl_cii{_tests}: OIOUBL export](https://github.com/odoo/odoo/pull/128049/commits/c45d68cfa4a626c2a49c746a787b19a43a62e252)
The aim of this commit is to support OIOUBL format export in order to comply
with the Danish accountancy act.
Before this commit:
OIOUBL isn't a supported format in Odoo
After this commit:
It is possible to generate oioubl document for invoice and credit-note
Current limitation:
- Payment Terms: will be left empty
- Payment Means: will always be 'unknown'
Documentation:
oioubl official website: https://oioubl.info/classes/en/index.html
List of documentation: https://oioubl.info/documents/en/documentoverview.html
OIOUBL Schematron validator: https://rep.erst.dk/git/openebusiness/common/-/tree/master/resources/Schematrons/OIOUBL
Downloadable ressources: https://rep.erst.dk/git/openebusiness/common/-/tree/master/resources
Validation:
https://www.oioubl.info/validator/default.aspx
https://ecosio.com/en/peppol-and-xml-document-validator/
task-id: 3326977
Forward-Port-Of: odoo/odoo#128049# Issue Search on website has a big performance issue because the database has too many product_template. # Analyze The website search mechanism has hardcoded sql query. And the generic query don't have any filtering. Which lead to make a expensive search (similarity) on the whole product_template even if the products are not published and then displayed to the user. # Fix Filter the is_published field in the generic website method when the model has a 'is_published' field and th
Original PR description
# Issue Search on website has a big performance issue because the database has too many product_template. # Analyze The website search mechanism has hardcoded sql query. And the generic query don't…
# Issue Search on website has a big performance issue because the database has too many product_template. # Analyze The website search mechanism has hardcoded sql query. And the generic query don't have any filtering. Which lead to make a expensive search (similarity) on the whole product_template even if the products are not published and then displayed to the user. # Fix Filter the is_published field in the generic website method when the model has a 'is_published' field and the request is not done by a user (thus for customers or portal users). # Note The internal user is still able to search on unpublished product.Thus have no performance improvement. # Benchmark | SQL Query | # Input data | Before PR | After PR | |:---------:|:------------:|:---------:|:--------:| |General best_similarity |700000 products (161 published) | 12.65 s | 0.12 s | |FROM ir_translation|2,796,000 ir_translation | 6.338 s (586k hit) | 0.091 s (185 hit) | # Related task task-3473786 Forward-Port-Of: odoo/odoo#135814 Forward-Port-Of: odoo/odoo#130734
task-3487561 Forward-Port-Of: odoo/enterprise#46647
Original PR description
task-3487561 Forward-Port-Of: odoo/enterprise#46647
Steps: 1. Install the WhatsApp, Sales module. 2. Create a WhatsApp template to Generate Sales Payment Link. 3. Create a Sale order. confirm it. 4. Now got o action > Generate a Payment Link. 5. Click on whatsapp it will open whatsapp composer and then send whatsapp message It will raise traceback Forward-Port-Of: odoo/enterprise#47534
Original PR description
Steps: 1. Install the WhatsApp, Sales module. 2. Create a WhatsApp template to Generate Sales Payment Link. 3. Create a Sale order. confirm it. 4. Now got o action > Generate a Payment Link. 5. Click on whatsapp it will open whatsapp composer and then send whatsapp message It will raise traceback Forward-Port-Of: odoo/enterprise#47534
Before this commit, creating an appraisal or an appraisal goal while being connected in multiple companies would only display the available employees for the main company. It would also lead to no results if the user had no employee in the companies selected. This commit fixes both issues. task-3374635 Forward-Port-Of: odoo/enterprise#46840 Forward-Port-Of: odoo/enterprise#43138
Original PR description
Before this commit, creating an appraisal or an appraisal goal while being connected in multiple companies would only display the available employees for the main company. It would also lead to no results if the user had no employee in the companies selected. This commit fixes both issues. task-3374635 Forward-Port-Of: odoo/enterprise#46840 Forward-Port-Of: odoo/enterprise#43138
*: account_reports, l10n_no_reports, l10n_syscohada_reports This PR contains three commits each of which fixes a different unwanted behavior. 1. The account_reports module's commit fixes a bug happening in the Finnish Profit and Loss report. When trying to unfold some lines, the user would get a traceback telling him it is not possible. This traceback is not something the user should see and happens because some lines don't have a children or an expand function. This behavior is f
Original PR description
*: account_reports, l10n_no_reports, l10n_syscohada_reports This PR contains three commits each of which fixes a different unwanted behavior. 1. The account_reports module's commit fixes a bug…
*: account_reports, l10n_no_reports, l10n_syscohada_reports
This PR contains three commits each of which fixes a different unwanted behavior.
1. The account_reports module's commit fixes a bug happening in the Finnish Profit and Loss report. When trying to unfold some lines, the user would get a traceback telling him it is not possible. This traceback is not something the user should see and happens because some lines don't have a children or an expand function.
This behavior is fixed by allowing the user to unfold these lines but without doing anything.
More informations about this feature can be found in the first commit's message.
2. The l10n_no_reports module's commit fixes a behavior happening in the Norwegian Profit and Loss report. When inside the Profit and Loss report using a Norwegian company, both the general report and the Norwegian one would appear under the name "Profit and Loss". This can make the user confused about which is which.
This behavior is fixed by adding a country_id to the report so it is now named "Profit and Loss (NO)" in the list.
More informations about this feature can be found in the second commit's message.
3. The l10n_syscohada_reports module's commit fixes a behavior happening in the Senegalese Balance Sheet and Profit and Loss reports. When inside each of these reports using a Senegalese company, both the general and the localized reports would appear with the same name. This can make the user confused about which is which.
This behavior is fixed by adding "(SYSCOHADA)" to the report's name.
More informations about this feature can be found in the third commit's message.
task-3462024
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#47564
Forward-Port-Of: odoo/enterprise#46417This commit fixes a bug that impacted the invite links sent via mail to portal users. The links sent redirected the user to the home page instead of the article on which he/she was invited. This bug was caused by a call to a server action that didn't use the correct context key to reference the article. Now the server action's context uses the correct keys and redirects to the correct article. task-3505408 Forward-Port-Of: odoo/enterprise#47505
Original PR description
This commit fixes a bug that impacted the invite links sent via mail to portal users. The links sent redirected the user to the home page instead of the article on which he/she was invited. This bug was caused by a call to a server action that didn't use the correct context key to reference the article. Now the server action's context uses the correct keys and redirects to the correct article. task-3505408 Forward-Port-Of: odoo/enterprise#47505