Tuesday, April 9, 2024
61 changes
Enhancements to existing features
This update aligns the naming of message formats used in Knowledge and WhatsApp features with related community changes. It is a minor consistency improvement that helps keep messaging behavior easier to maintain without changing business workflows.
Original PR description
@see https://github.com/odoo/odoo/pull/160355
Barcode batch transfers now show the description field in the kanban view. This gives warehouse users more context at a glance when reviewing batches or waves, helping them identify the right transfer faster.
Original PR description
The description field added in https://github.com/odoo/odoo/pull/157869 is added to the barcode batch transfers kanban view. Task-3724421
Updates naming around message formatting in Knowledge and WhatsApp-related messaging to keep the system more consistent. This is an internal cleanup that should help maintainability without changing day-to-day user workflows.
Resolved issues and error corrections
This update fixes an issue where some payroll, planning, timesheet forecasting, and sales calculations could handle empty filter conditions incorrectly. It helps prevent incorrect results or unexpected behavior in affected business workflows.
Original PR description
Companion of https://github.com/odoo/odoo/pull/160979.
Code cleanup and technical improvements
This update renames an internal model property from `_store` to `store` across related Odoo Enterprise modules. It makes the code easier for developers to understand and maintain, with no expected change to everyday user workflows.
Original PR description
It gave the wrong impression that using `this._store` in model was not ok... And another argument was that probably someone would like to name a custom field `store` thus reserving the name with prefix... But these arguments are weak and this name just scares the devs from accessing the store in models. This commit removes the prefix `_` to be more welcome. https://github.com/odoo/odoo/pull/161128
Miscellaneous changes
- Set up tax support configuration for new VAT purchase taxes of 5% and 15%. - Add rate and tax group codes for electronic documents - Add unit test for VAT 5% and 15% - Fix ATS report to declare VAT taxes inactive - Add tax support configuration migration for new VAT taxes in 2024 - Cover base and tax amounts scenario for the ATS, including new tax percentages - Fix missing tax support configuration for taxes with xml_ids: tax_vat_545_sup_08_vat0, tax_vat_545_sup_08_vat_exempt, tax_vat_54
Original PR description
- Set up tax support configuration for new VAT purchase taxes of 5% and 15%. - Add rate and tax group codes for electronic documents - Add unit test for VAT 5% and 15% - Fix ATS report to declare VAT taxes inactive - Add tax support configuration migration for new VAT taxes in 2024 - Cover base and tax amounts scenario for the ATS, including new tax percentages - Fix missing tax support configuration for taxes with xml_ids: tax_vat_545_sup_08_vat0, tax_vat_545_sup_08_vat_exempt, tax_vat_545_sup_08_vat_not_charged Forward-Port-Of: odoo/enterprise#60049
Steps to reproduce: - create a new spreadsheet - edit a few cells to create a few history revisions - click on menu File > Add to dashboard - close the dialog (you don't even need to actually create the dashboard) - open the history: File > See version history => all the history is gone Task: 3850102 Forward-Port-Of: odoo/enterprise#60289 Forward-Port-Of: odoo/enterprise#60063
Original PR description
Steps to reproduce: - create a new spreadsheet - edit a few cells to create a few history revisions - click on menu File > Add to dashboard - close the dialog (you don't even need to actually create the dashboard) - open the history: File > See version history => all the history is gone Task: 3850102 Forward-Port-Of: odoo/enterprise#60289 Forward-Port-Of: odoo/enterprise#60063
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new
Original PR description
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new storable product > - Update onhand qty: 20 package: PKG1, location: WH/Stock/Shelf 1 > - in Barcode app create a new transfer and scan PKG1 > > Bug: > the current package location is different from the default source location therefore package is ignored and an error is thrown (you are expected to scan one or more products ....) > > Fix: > check if the package is in a child location aswell > > opw-3595643 Forward-Port-Of: odoo/enterprise#60070 Forward-Port-Of: odoo/enterprise#58896
For info FullCalendar V6 use Preact internally. Preact is similar to OWL/React/Vue as when some props change it apply the change on the element linked to the props. In our case for the events, when an event has a duration of 15 minutes FullCalendar changes the `isShort` to `true` so Preact can add the `fc-timegrid-event-short` class to the event. In Odoo we add also other classes to these events for our needs (e.g.: `o_event_striked`). In FullCalendar V4 it was done in `eventRender` us
Original PR description
For info FullCalendar V6 use Preact internally. Preact is similar to OWL/React/Vue as when some props change it apply the change on the element linked to the props. In our case for the events, when…
For info FullCalendar V6 use Preact internally. Preact is similar to OWL/React/Vue as when some props change it apply the change on the element linked to the props. In our case for the events, when an event has a duration of 15 minutes FullCalendar changes the `isShort` to `true` so Preact can add the `fc-timegrid-event-short` class to the event. In Odoo we add also other classes to these events for our needs (e.g.: `o_event_striked`). In FullCalendar V4 it was done in `eventRender` using `el.classList.add()`. During the migration to FullCalendar V6 [1] the `eventRender` was changed into `eventDidMount` (a Preact HOOK). In most cases, `eventDidMount` is fine but not for short event, as in FullCalendar V6 there is another HOOK especially for the classes `eventClassNames` [2]. Before this fix, the render flow of the event was: 1) pre-render event 2) add the event to the DOM 3) call `eventDidMount` (here we add our classes) 4) FullCalendar set `true` to `isShort` props 5) Preact sets the classes on the event to add `fc-timegrid-event-short` (here FullCalendar removes our classes added in `eventDidMount`) After the fix, the render flow is the same as before, but as we add the classes using the `eventClassNames` HOOK, FullCalendar knows all additional classes per event so when Preact (in steps 5) sets the classes its adds `fc-timegrid-event-short` and all other classes added by our code in `eventClassNames`. Steps to reproduce: * Open Calendar App * Make an event with a duration of 15 minutes * Refresh the page (F5) => Bug the style of new event (15 min) is wrong [1]: odoo/odoo@90f85a19deaea33cd747c969762ff20f1d59ef4c [2]: https://fullcalendar.io/docs/event-render-hooks Forward-Port-Of: odoo/enterprise#60244
Before this commit, when the user clicks on a gantt cell of the planning gantt view to create a shift for a specific date. By doing that, the planned dates set by default to the form view is the whole period of the gantt view instead of the date set on the gantt cell clicked. This commit removes the override erasing the default planned dates by the period of the gantt to keep the standard behavior as before. Forward-Port-Of: odoo/enterprise#59307 Forward-Port-Of: odoo/enterprise#59247
Original PR description
Before this commit, when the user clicks on a gantt cell of the planning gantt view to create a shift for a specific date. By doing that, the planned dates set by default to the form view is the whole period of the gantt view instead of the date set on the gantt cell clicked. This commit removes the override erasing the default planned dates by the period of the gantt to keep the standard behavior as before. Forward-Port-Of: odoo/enterprise#59307 Forward-Port-Of: odoo/enterprise#59247
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59921 Forward-Port-Of: odoo/enterprise#59527
Original PR description
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59921 Forward-Port-Of: odoo/enterprise#59527
Adds a check to avoid calling `_get_l10n_au_hourly_rate` on an empty `hr.payslip.worked_days` record Issues: test_reports failed when the payslip with no worked_days was used. The method _get_l10n_au_hourly_rate requires one record but none were passed. https://runbot.odoo.com/web#id=60794&view_type=form&model=runbot.build.error&menu_id=405&cids=1 Forward-Port-Of: odoo/enterprise#60235
Original PR description
Adds a check to avoid calling `_get_l10n_au_hourly_rate` on an empty `hr.payslip.worked_days` record Issues: test_reports failed when the payslip with no worked_days was used. The method _get_l10n_au_hourly_rate requires one record but none were passed. https://runbot.odoo.com/web#id=60794&view_type=form&model=runbot.build.error&menu_id=405&cids=1 Forward-Port-Of: odoo/enterprise#60235
With an EC company setup Create a vendor bill Add 2+ withholding via the 'Add Withhold' Go to Accounting > Reports > Tax Report Set the month to this month, make sure report 103 is selected, then click the drop down menu for the PDF to select ATS Issue: Traceback It occurs because the user should not be able to add multiple posted withholds to the same invoice opw-3793714 Forward-Port-Of: odoo/enterprise#59679
Original PR description
With an EC company setup Create a vendor bill Add 2+ withholding via the 'Add Withhold' Go to Accounting > Reports > Tax Report Set the month to this month, make sure report 103 is selected, then click the drop down menu for the PDF to select ATS Issue: Traceback It occurs because the user should not be able to add multiple posted withholds to the same invoice opw-3793714 Forward-Port-Of: odoo/enterprise#59679
Bug === When we send a UBL file by email, it is not detected as a UBL file. Technical ========= Since odoo/odoo@8214247 the XML files are imported as plain text. But the check for the UBL file check only the mimetype XML. Task-3792364 Forward-Port-Of: odoo/enterprise#58577
Original PR description
Bug === When we send a UBL file by email, it is not detected as a UBL file. Technical ========= Since odoo/odoo@8214247 the XML files are imported as plain text. But the check for the UBL file check only the mimetype XML. Task-3792364 Forward-Port-Of: odoo/enterprise#58577
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dro
Original PR description
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving…
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dropdown, select share to open the share popup. 4. Inside here just select the allow to download and upload documents and we click on share again. 5. Open the link in a new tab and we will see only the document already opened, without any posibility of see the entire folder or uploading a new document. Solution: Inside the `share_portal` of `SpreadsheetShareRoute` when checking for a single document, we also need to check if we are working with a selection, or if it's the folder what we want to share. opw-3688409 Forward-Port-Of: odoo/enterprise#60113 Forward-Port-Of: odoo/enterprise#57394
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not allowed in Colombia. ### Steps to reproduce * install `l10n_co_edi` * switch to a Colombian company and set up the EDI * create, confirm, and send an invoice * once the invoice has been successfully sent, attempt to cancel it using the 'Request EDI Cancellation' button. The invoice will be
Original PR description
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not…
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not allowed in Colombia. ### Steps to reproduce * install `l10n_co_edi` * switch to a Colombian company and set up the EDI * create, confirm, and send an invoice * once the invoice has been successfully sent, attempt to cancel it using the 'Request EDI Cancellation' button. The invoice will be marked as `to cancel`. Odoo will then periodically try to cancel it, but it will never succeed because Colombian invoices that have been sent to the government cannot be reset to draft. If the cancellation process is initiated by the user (either by manually running the EDI services cron, or using the 'Process Now' button on the form view) the following error message appears: > You can't edit the following journal entry [journal name] because an electronic document has already been sent to Carvajal. To edit this entry, you need to create a Credit Note for the invoice and create a new invoice. opw-3754395 Forward-Port-Of: odoo/enterprise#59975 Forward-Port-Of: odoo/enterprise#59749
Steps: In the default worksheet template, add the field "ID" and change its label as "Proute". Go to a helpdesk ticket, and create a worksheet. See that the label is "Proute". Now share it with a portal user. Log in as that user, and go on the ticket. Issue: The label of the worksheet's field is "ID". Cause: The back-end template uses `<field name="id" string="Proute">`. It is then translated to a qweb as `<div string="Proute">ID</div>` because it sets the name of the field as the d
Original PR description
Steps: In the default worksheet template, add the field "ID" and change its label as "Proute". Go to a helpdesk ticket, and create a worksheet. See that the label is "Proute". Now share it with a portal user. Log in as that user, and go on the ticket. Issue: The label of the worksheet's field is "ID". Cause: The back-end template uses `<field name="id" string="Proute">`. It is then translated to a qweb as `<div string="Proute">ID</div>` because it sets the name of the field as the description. Fix: Set the string of the tag if any, or else the name of the field. task-3479545 Forward-Port-Of: odoo/enterprise#47803
Steps ----- 1. Have field services and sales installed 2. Create a new company 3. Create a new product belonging to the new company 4. Log in under new company 5. Field service > click the "Product" smart button in a task with no sales order ** Read access error when accessing a page with a product from new company ** Issue ----- In a multi-company environment, accessing the catalog of products in field service is only possible if there are no products belonging to a different compan
Original PR description
Steps ----- 1. Have field services and sales installed 2. Create a new company 3. Create a new product belonging to the new company 4. Log in under new company 5. Field service > click the "Product" smart button in a task with no sales order ** Read access error when accessing a page with a product from new company ** Issue ----- In a multi-company environment, accessing the catalog of products in field service is only possible if there are no products belonging to a different company than the user's main company. Note: this issue only arises if there's no sales order linked to the task. If an order already exists (for example by creating a sales order item in the task form), its associated company will be used. Fix --- We use the tasks's company to have the correct allowed_company_ids in the context. **opw-3752311** Forward-Port-Of: odoo/enterprise#58483
Before this commit, the timesheets created inside `test_timesheet_check_warning_when_helpdesk_team_change` test could be unvalidated even after calling `action_timesheet_validate`. The reason is because the timesheets are created by the current user (OdooBot) is our case and his timezone could be different than the user who validates the timesheets and so the timesheets date could be tomorrow for the timesheet approver used inside that test becaue of the timezone is not the same for the bo
Original PR description
Before this commit, the timesheets created inside `test_timesheet_check_warning_when_helpdesk_team_change` test could be unvalidated even after calling `action_timesheet_validate`. The reason is because the timesheets are created by the current user (OdooBot) is our case and his timezone could be different than the user who validates the timesheets and so the timesheets date could be tomorrow for the timesheet approver used inside that test becaue of the timezone is not the same for the both users. To avoid timezone issue, this commit makes sure the same user creates and validates those timesheets since the goal of that test is to check the `project_id` field is unchanged for validated timesheets even if the ticket changed. runbot-61011 Forward-Port-Of: odoo/enterprise#60146
Since [1], when an action is loaded, if the action is a server action, the server will execute the action directly and return the resulting action. Before the commit [1], only a part of the context was need, now that the server execute the action, the complete user context is need. Before this commit, a performance improvement was to call the action load at the beginning of the action service. The issue with calling the action load in such an early step, is that all the user context is not c
Original PR description
Since [1], when an action is loaded, if the action is a server action, the server will execute the action directly and return the resulting action. Before the commit [1], only a part of the context was need, now that the server execute the action, the complete user context is need. Before this commit, a performance improvement was to call the action load at the beginning of the action service. The issue with calling the action load in such an early step, is that all the user context is not complete yet (For instance, the allowed_company_id is not yet there, it's added later by the company service). Now, the call to the action load is made on the mount of the WebClient, in which moment it should have the complete user context. [1] : https://github.com/odoo/odoo/commit/f49e97e9ad41c1c5e7123bad9c429a9af2732b73 Forward-Port-Of: odoo/enterprise#60167
The rates of the nssf have been updated to 7000Ksh and 36000Ksh to reflect the changes the changes that start to be active from 1st February 2024. The computation of the nssf doesn't change. task-3827016 Forward-Port-Of: odoo/enterprise#59515
Original PR description
The rates of the nssf have been updated to 7000Ksh and 36000Ksh to reflect the changes the changes that start to be active from 1st February 2024. The computation of the nssf doesn't change. task-3827016 Forward-Port-Of: odoo/enterprise#59515
Issue: If a customer was using `round globally` and at some point wanted to export its date, he could not do it because of this rounding parameter. The reason of the fix in the first place is not strong enough (occasional 1 cent rounding issue) to justify blocking such an important flow original pr: https://github.com/odoo/enterprise/pull/34560 opw-3848827 Forward-Port-Of: odoo/enterprise#60112 Forward-Port-Of: odoo/enterprise#60026
Original PR description
Issue: If a customer was using `round globally` and at some point wanted to export its date, he could not do it because of this rounding parameter. The reason of the fix in the first place is not strong enough (occasional 1 cent rounding issue) to justify blocking such an important flow original pr: https://github.com/odoo/enterprise/pull/34560 opw-3848827 Forward-Port-Of: odoo/enterprise#60112 Forward-Port-Of: odoo/enterprise#60026
## Issue: - When trying to select any new email template on follow up reports, it will only display the current template (the one configured in the followup level that the customer is currently in), and if you delete it, it's impossible to select one again. ## Steps To Reproduce: - accounting > Follow-up reports. - On a report click on FOLLOW UP. - Notice missing templates in Content Template. ## Solution: - The template_id field's domain is defined as `domain="[('model', '=',
Original PR description
## Issue:
- When trying to select any new email template on follow up reports, it will only display the current template (the one configured in the followup level that the customer is currently in), and if you delete it, it's impossible to select one again.
## Steps To Reproduce:
- accounting > Follow-up reports.
- On a report click on FOLLOW UP.
- Notice missing templates in Content Template.
## Solution:
- The template_id field's domain is defined as `domain="[('model', '=', render_model)]"`, which filters based on render_model. However, it was not functioning correctly because the computation for `render_model` was not being triggered.
- To resolve this issue, I set 'res.partner' as the default render_model in the `default_get`.
opw-3776312
Forward-Port-Of: odoo/enterprise#58400Previously, testing HMRC features with dummy credentials required manually changing variables within the code. This commit introduces a more user-friendly approach by adding a new configuration parameter. The new configuration parameter defaults to "production" to maintain existing behavior. However, users can switch to a "demo" or other values to transition the APIs to a sandbox environment for testing with mock credentials. task-3820114 Forward-Port-Of: odoo/enterprise#59152
Original PR description
Previously, testing HMRC features with dummy credentials required manually changing variables within the code. This commit introduces a more user-friendly approach by adding a new configuration parameter. The new configuration parameter defaults to "production" to maintain existing behavior. However, users can switch to a "demo" or other values to transition the APIs to a sandbox environment for testing with mock credentials. task-3820114 Forward-Port-Of: odoo/enterprise#59152
Some MUA allow users to group messages 'by thread', so that all emails that share some specific headers are bundled together in a 'conversation' view. In general, using the 'References' header to point to the original message in the thread is enough for most MUAs to properly group emails together. This is not the case for Outlook, which also wants the title to somewhat match the original title - some changes are accepted (typically at the start of the subject header) but others aren't.
Original PR description
Some MUA allow users to group messages 'by thread', so that all emails that share some specific headers are bundled together in a 'conversation' view. In general, using the 'References' header to…
Some MUA allow users to group messages 'by thread', so that all emails that share some specific headers are bundled together in a 'conversation' view. In general, using the 'References' header to point to the original message in the thread is enough for most MUAs to properly group emails together. This is not the case for Outlook, which also wants the title to somewhat match the original title - some changes are accepted (typically at the start of the subject header) but others aren't. For example, if a ticket is submitted by email alias with the title 'Important issue', then replies with titles like 'Re: Important issue' or '(#123) Important issue' are recognized as being from the same thread, but others like 'Important issue (#123)' are not. Since the helpdesk override of the display name is mostly there for the backend and not for email communications, this commit forces the helpdesk app to send emails with the exact same title as the initial ticket instead of including the ticket reference in the reply's title. The ticket reference is still included in the mail body for the customer so no information is lost. opw-3748509 Forward-Port-Of: odoo/enterprise#60150