Tuesday, November 12, 2024
38 changes · 18.0
Enhancements to existing features
Recruitment users can now see and manage activities directly from the applicants list. This makes it easier to create or track activities for multiple applicants at once, improving follow-up efficiency.
Original PR description
It is not possible at the moment to create activity for more than one applicant. This commit adds the activities column to the list view of `hr.applicant` so that it can be possible. task-4316528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the Muk Web Theme package for Odoo 18.0. The available information does not describe specific functional changes, so the business impact appears limited to maintaining or refreshing the theme package.
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
Appointment durations now use a shorter display format when longer labels would not fit neatly, such as durations over a day or with extra minutes. This improves readability and makes scheduling screens cleaner and easier to scan for users.
Original PR description
When the appointment duration is not a multiple of hours, ex: 2 hour 30 minutes it is not able to fit in one line. Thus change appointment duration format to short when duration exceeds a day or is not a multiple of an hour. And some other UI/UX changes. Task-4209912
The appointment calendar now limits its display to dates within the month currently being viewed. This makes scheduling clearer by avoiding extra days from adjacent months that could distract users or cause confusion.
Original PR description
Limit calendar view to show only dates within the currently selected month. Task-4294202
Resolved issues and error corrections
A small typo was corrected in the Live Chat chatbot setup logic. This helps ensure chatbot step information is stored consistently and avoids issues caused by the earlier typo.
Original PR description
This PR fixes a typo introduced by this commit ce0f8d9e608acdcc6fd8495e7b9cd8f7d2757349. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change simplifies the automated tour system that Odoo uses to test user journeys across apps and websites. It makes test flows more predictable by ensuring each step advances in one consistent way, reducing flaky test results and improving release confidence.
Original PR description
Miscellaneous changes
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and m
Original PR description
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like…
Currently, the relationship between stock.picking and purchase.order is done via a `related` non-store field that requires iterating all moves. This becomes problematic in a case like `_get_related_invoices` in the purchase_stock module because we need to get the purchase_id of a move, but to do that, we will have to go through the picking_id which will need to iterate all moves related to the same picking. When you have `_prefetch_ids` set on that move, this process becomes extremely slow and memory-expensive because the `purchase_id` field is not stored so it needs to compute the relationship for all moves in the expanded ids due to prefetching. Since there exists a Many2many relationship between stock pickings and purchase orders, it's possible to rely on a search query instead of the `mapped` call. Although this might miss some cache optimizations, it's still much more efficient in terms of memory. This is because this approach is not susceptible to prefetch_ids explosion. It's also worth noting that this function is only called on individual stock moves instead of batches as part of the anglo_saxon_accounting logic. That being said, we don't have to worry this much about cache optimization since the method is not batched to begin with. Using this optimization, we get the following benchmarks. Benchmark: | num stock.move (_prefetch_ids) | time before | no. queries before | time after | no. queries after| |----|------|-----| ----- | ----- | | 1000 | timeout | N/A | ~ 85 seconds | 47897 | opw-4096108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181822
Muted mail notifications will now correctly hide the unread indicator. This prevents users from seeing misleading unread markers on conversations they have chosen to mute.
Original PR description
There was `opacity-0` on muted item, but due to `opacity-50` being mistakenly present at all time, it had precedence over the `opacity-0` thus the unread indicator was always visible. 
This fixes an internal automated test so it checks the intended shared behavior rather than only one specific implementation. It helps prevent false test failures when country-specific electronic invoicing extensions add their own data.
Original PR description
Fix a failing test that was incorrectly patching a class method, instead of patching the base object. Indeed, before this fix the test was only patching `account_edi_ubl_cii._get_ubl_cii_formats_info()` and not extensions such as `l10n_ro_edi._get_ubl_cii_formats_info()`). Therefore extensions could add data to the returned value of the method, and could make the test fail. Related runbot error id: 104916 task-no
Invoice document previews now show only the intended sample QR code when SEPA payment QR codes are enabled. This avoids confusing users during the print and send setup by replacing the real generated QR code in the preview instead of adding a second one.
Original PR description
Version: 18.0 Issue: With a valid SEPA bank account enabled, 2 QR codes are generated on the report invoice preview document. This is because we are xpathing to the `qr_code` element and adding a dummy qr code after for the preview. Purpose of this PR: To replace the generated QR code with the preview, dummy QR code for the preview wizard. Steps to Reproduce on Runbot: install a new company enable QR code in the settings set up a valid SEPA bank account for the bank journal create an invoice and click 'print & send' to trigger the Configure Document Layout wizard view 2 QR codes in the preview opw-4267407 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a test helper in the HTML editor so moving the text selection no longer rebuilds the page content when nothing has changed. It reduces unnecessary background updates during tests, helping keep editor testing more stable and efficient without changing user-facing behavior.
Original PR description
Before this commit, in the tests, when the setContent utils is used to move the selection, the entire html is recreated. This implies a set of unnecessary mutations in the dom. This commit will therefore prevent the creation of all these mutations by checking if the ‘content’ is different from that in ‘el’. 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
Odoo now shows a server-side warning when older Kanban view templates are used, helping teams identify views that need updating. This complements the existing browser warning and helps prevent deprecated configurations from being introduced unnoticed.
Original PR description
A new API for kanban templates has been introduced in [1], which deprecates the former API (the one defining a "kanban-box" template). A client side warning has been added when a legacy kanban view was met. However, there was a lack of server side warning, especially when a legacy kanban arch was introduced. This commit adds this warning. More information about the new Kanban API can be found in the documentation [2]. [1] https://github.com/odoo/odoo/pull/167751 [2] https://www.odoo.com/documentation/master/developer/reference/user_interface/view_architectures.html#kanban Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures website notification popups appear in the visible browser window even when visitors are scrolled down the page. It prevents important confirmations, such as newsletter signup messages, from being hidden at the top of the page.
Original PR description
Since [1], the notifications were not positioned properly anymore. Indeed, if the page was scrolled, the notifications were scrolled with it, meaning that they would not be visible at the top of the viewport as intended, but at the top of the scrolled body. Steps to reproduce: - Install website_mass_mailing - Go to your website homepage in edit mode - Add enough content to make the page scrollable - Add a "Newsletter" inner block inside the footer - Save - Scroll to your footer and register to the newsletter => A popup is shown but you can't see it (scroll to the top to see it). The solution is simple: the previous notification manager was positioned based on the fact the body is never scrolled (position: absolute), we now position it based on the viewport (position: fixed) as it could have already been. [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e Closes https://github.com/odoo/odoo/issues/186432 Related to task-4190506
The point of sale food delivery setup no longer pre-selects Glovo as the default provider, giving businesses a neutral starting point when configuring platforms. Order notes have been cleaned up by removing an extra bullet point, and the related settings label is clearer for users managing food delivery platforms.
Original PR description
Before this commit : - Glovo was selected as default delivery provider. - Extra Dot(Bullet Point) is visible in the Order notes - Label to be changed under Food delivery connector field. Following this commit : - Default delivery provider is removed. - Extra dot is been removed in order notes. - Label is been updated to Food Delivery Platforms. task - 4315841
This update fixes an internal automated test for document folder deletion that could fail when the expected test folder was not selected. It helps keep quality checks stable without changing how users delete folders in Documents.
Original PR description
The tour is failing because the test folder ("Folder1") is not always selected when starting the test with its access token. As the test is checking the folder deletion, we select the test folder manually by clicking on it.
Task-4247011This fix removes an incorrect warning shown around Web Studio kanban views after a naming change from "kanban-card" to "card". It helps avoid confusing users or administrators with a warning about something that no longer exists, with no expected change to business workflows.
Original PR description
The warning was erroneous as "kanban-card" doesn't exist, we renamed it into "card" [1]. [1] odoo/odoo#180999
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reorganizes how the HTML editor coordinates commands, toolbar actions, and plugin communication. It should make future editor changes easier to build, test, and debug while keeping the visible editing experience largely unchanged.
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/72830
The HTML editor integrations were reorganized to use clearer internal APIs across appointment scheduling, Knowledge, and Studio report editing. This should make future editor-related improvements easier to maintain while causing little direct change for end users.
Original PR description
Community: https://github.com/odoo/odoo/pull/185356
At the moment cancelling assets is impossible when audit trail is enabled because it tries to unlink the move. It should be possible, in which case the move should be reversed instead. By adding a check in _can_be_unlinked to return False in such case, the _unlink_or_reverse method will then properly reverse asset moves as expected. Back port of https://github.com/odoo/odoo/pull/181193 task-4251586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
At the moment cancelling assets is impossible when audit trail is enabled because it tries to unlink the move. It should be possible, in which case the move should be reversed instead. By adding a check in _can_be_unlinked to return False in such case, the _unlink_or_reverse method will then properly reverse asset moves as expected. Back port of https://github.com/odoo/odoo/pull/181193 task-4251586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186974 Forward-Port-Of: odoo/odoo#184535
Steps to reproduce: - Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id - In journal items, try to "cut-off" Issue: You won't be able to do so because of the tax lock date Cause: We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/
Original PR description
Steps to reproduce: - Create and confirm an invoice at 2024/10/01 with a line containeing a tax_id - In journal items, try to "cut-off" Issue: You won't be able to do so because of the tax lock date Cause: We need the correct accounting date to find back the reference move but before the fix, a side effect was to check for tax lock date which does not make sense in this flow. We create move line without tax_ids/tag_grid and so it does not impact the tax report: https://github.com/odoo/odoo/blob/16.0/addons/account/wizard/account_automatic_entry_wizard.py#L242-L271 Solution: we set the `has_tax` to False to byapss the check. The user, if he wishes, could excatly the same flow by creating an entry "a la mano" <-> We don't need to block this flow opw-4191527 Forward-Port-Of: odoo/odoo#185078
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
Original PR description
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#185266
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#186718
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 Forward-Port-Of: odoo/odoo#186718
This pull request updates the muk_web_theme package to version 18.0.1.2.3. The available information does not describe specific functional changes, so business impact appears limited to maintaining the theme package version.
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
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_auto
Original PR description
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation…
### Analysis Before this commit, the `date_automation_last` was updated before checking the `trigger_field_ids`. This means that the `date_automation_last` field was updated even if the automation rule wasn't supposed to run - which, on the functional side, is a behavior we can argue on. Moreover, this triggers a write on the records which is not necessary if the automation rule is not run and can increase the delay of the operation. ### Solution In this commit, we update the `date_automation_last` after filtering the records by checking the `trigger_field_ids`. ## Benchmarks Measuring `web_save` when updating the stage of a lead in the Kanban view of CRM: | # `crm.lead ` | # `automation.rule` on crm.lead | Before | After | % | -------------------- | -----| -- | ---------- | -------- | 970 records| 6 | 1.5s | 0.3 s | - ~80% ### References opw-4263443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186487
Versions -------- - saas-17.4+ Enterprise PR: https://github.com/odoo/enterprise/pull/73318 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combi
Original PR description
Versions -------- - saas-17.4+ Enterprise PR: https://github.com/odoo/enterprise/pull/73318 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combines it with the `year` of the date, which is 2024. Solution -------- ### Community: Like the `weeknumber` function added in 9c47e911d0ca7 to `odoo.tools.date_utils`, have a function in `web` that returns both year and week number. ### Enterprise: Define a `formatLocalWeekYear` function in `web_gantt` using the new `getLocalYearAndWeek` function from `web`. opw-4280192 Forward-Port-Of: odoo/odoo#186284
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
Original PR description
This commit adds the capture parameter to events listeners in useDropzone utility function to make it work correctly in Documents App where the events weren't intercepted because of `stopPropagation()` call in others listeners. Task-4314619 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186651
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186510 Forward-Port-Of: odoo/odo
Original PR description
**Steps to reproduce:** - Go to events > Configuration > settings > Enable "Use Event Barcode" - Then go to events > Select any event - Click on the gear icon > Print > Badge example **The issue originates from the "sample id" used for printing the badge example. Since it lacks single quotes, the system interprets it as an integer rather than a string, resulting in a traceback error during the printing process.** opw-4253212 Forward-Port-Of: odoo/odoo#186510 Forward-Port-Of: odoo/odoo#186243
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected behavior:** AMLs generated for this move have 0 quantity. **Steps to reproduce:** *Having accounting, purchase_stock* 1. Create a storable product with `average` costing 2. Create a purchase order for some of the product with some arbitrary price unit, receive the product 3. In
Original PR description
**Current behavior:** Manually adjusting a FIFO/AVCO product's cost creates a journal items with non-zero quantity, despite there not being a logical quantity associated with this entry. **Expected…
**Current behavior:**
Manually adjusting a FIFO/AVCO product's cost creates a journal
items with non-zero quantity, despite there not being a logical
quantity associated with this entry.
**Expected behavior:**
AMLs generated for this move have 0 quantity.
**Steps to reproduce:**
*Having accounting, purchase_stock*
1. Create a storable product with `average` costing
2. Create a purchase order for some of the product with some
arbitrary price unit, receive the product
3. In the product form, change the cost to a smaller value
4. In the journal items pivot view, select the `quantity` field
from the 'Measures' dropdown in the top left, expand the
stock valuation journal on the left axis, observe that the
change in cost has created 2 balancing AMLs, each with
quantity == 1
**Cause of the issue:**
This case was not handled and quantity is always set to 1 if
falsy.
**Fix:**
Create the AMLs created in the cost change handle with
quantity=0. While it does risk being overwritten to 1 if the
`display_type` of the line changes, the diff is minimal and
use-case is non-critical- which makes it the best solution here.
opw-4090620
Forward-Port-Of: odoo/odoo#186514
Forward-Port-Of: odoo/odoo#180998## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we select that pricelist on pos, and put it on default. ## Steps to reproduce: - Go to pos settings and enable flexible pricelists - under the Available Field pick some pricelist and also set it as default - create a loyalty program with a promo code and set the pricelist you picked before as it
Original PR description
## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we…
## Issue: When we create a loyalty program with promo code on a specific pricelist and try using the code in pos it gives the error "That promo code program requires a specific pricelist." even if we select that pricelist on pos, and put it on default. ## Steps to reproduce: - Go to pos settings and enable flexible pricelists - under the Available Field pick some pricelist and also set it as default - create a loyalty program with a promo code and set the pricelist you picked before as it's pricelist - open a pos session, add some products and try applying the promo code - a popup will show saying "That promo code program requires a specific pricelist." ## Solution: - While debugging the `activateCode` method, I found that the issue occurred because the code was using `.includes()` to check if `order.pricelist_id.id` was in `program_pricelists`, a list of objects. Since `.includes()` compares values directly, it couldn’t match an ID with objects, leading to it always returning False. - The fix uses the `.some()` method, which checks whether any object in the `program_pricelists` array has an id matching `order.pricelist_id.id`. This ensures that the comparison is made correctly on the id property of the objects. If a match is found, it returns true, and the validation proceeds as expected. OPW-4149335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182124
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Re
Original PR description
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Reload one tab several times: you can sometimes see a flicker from online to offline. task-4236550 Forward-Port-Of: odoo/odoo#186596 Forward-Port-Of: odoo/odoo#184825
Versions -------- - saas-17.4+ Steps ----- 1. Have PDF file with checkbox form fields; 2. upload it as footer for a Quotation Template; 3. set up a quotation using the template; 4. print the PDF Quote. Issue ----- > Odoo Server Error > IndexError: string index out of range Thrown from the PyPDF2 package. Cause ----- Commit e1b05e95e73c expanded the form fields available in the quote builder. It introduced the `_get_form_fields_values_mapping` method. It ignores fields
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Have PDF file with checkbox form fields; 2. upload it as footer for a Quotation Template; 3. set up a quotation using the template; 4. print the PDF Quote. Issue ----- > Odoo Server Error > IndexError: string index out of range Thrown from the PyPDF2 package. Cause ----- Commit e1b05e95e73c expanded the form fields available in the quote builder. It introduced the `_get_form_fields_values_mapping` method. It ignores fields not in the `param_field_map` by associating them with an empty string. This causes issues with non-text form fields, e.g. checkbox, which uses `/Off` to represent the emptiness. Solution -------- Instead of retrieving all fields with `getFields`, use `getFormTextFields`. This way, an empty string should always be a valid value. opw-4290594 Forward-Port-Of: odoo/odoo#185893
`uom_po_id` is invisible in the product view in 2 scenarios. the uom group is not activated or the product cannot be bought. As we are setting the default value anyway in those tests, it's better to not give a particular value to avoid error about writing into invisible field runbot error : 65999 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
Original PR description
`uom_po_id` is invisible in the product view in 2 scenarios. the uom group is not activated or the product cannot be bought. As we are setting the default value anyway in those tests, it's better to not give a particular value to avoid error about writing into invisible field runbot error : 65999 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#186737
This commit makes cancelled depreciation entries appear in grey in the depreciation board. It also turns the the depreciation entry's name into a link towards the move's form view. Forward-Port-Of: odoo/enterprise#73684 Forward-Port-Of: odoo/enterprise#72819
Original PR description
This commit makes cancelled depreciation entries appear in grey in the depreciation board. It also turns the the depreciation entry's name into a link towards the move's form view. Forward-Port-Of: odoo/enterprise#73684 Forward-Port-Of: odoo/enterprise#72819
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Original PR description
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619 Forward-Port-Of: odoo/enterprise#73506
Versions -------- - saas-17.4+ Community PR: https://github.com/odoo/odoo/pull/186284 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combines it
Original PR description
Versions -------- - saas-17.4+ Community PR: https://github.com/odoo/odoo/pull/186284 Steps ----- 1. Have Planning installed; 2. change localisation to 'en_GB' (or any whose weeks start on Monday); 3. open in Gantt view in weekly granularity; 4. go to the week of 2024-12-30. Issue ----- Label on top right displays "W1 2024"; Cause ----- It uses the `getLocalWeekNumber` function to get the week number of 2024-12-30, which falls in the first week of 2025. It then combines it with the `year` of the date, which is 2024. Solution -------- ### Community: Like the `weeknumber` function added in 9c47e911d0ca7 to `odoo.tools.date_utils`, have a function in `web` that returns both year and week number. ### Enterprise: Define a `formatLocalWeekYear` function in `web_gantt` using the new `getLocalYearAndWeek` function from `web`. opw-4280192 Forward-Port-Of: odoo/enterprise#73318
We wait for the next tick to leave the dialog enough time to load properly before changing the mode to draw, this way we avoid to have the canva with the auto result after changing to draw mode. Forward-Port-Of: odoo/enterprise#73248 Forward-Port-Of: odoo/enterprise#69785
Original PR description
We wait for the next tick to leave the dialog enough time to load properly before changing the mode to draw, this way we avoid to have the canva with the auto result after changing to draw mode. Forward-Port-Of: odoo/enterprise#73248 Forward-Port-Of: odoo/enterprise#69785
**Steps to reproduce:** (production credentials required) - Install l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) - Create an invoice for a Chilean customer - Confirm the invoice and process the electronic invoice - Create a credit note and process the electronic credit note - Create a debit note from the credit note (Do not set "SII Reference Code") - Process the electronic debit note **Issue:** The debit note will be rejected because "SII Reference Code" is not set.
Original PR description
**Steps to reproduce:** (production credentials required) - Install l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) - Create an invoice for a Chilean customer - Confirm the invoice and process the electronic invoice - Create a credit note and process the electronic credit note - Create a debit note from the credit note (Do not set "SII Reference Code") - Process the electronic debit note **Issue:** The debit note will be rejected because "SII Reference Code" is not set. **Solution:** Set "SII Reference Code" field as required. opw-4182451 Forward-Port-Of: odoo/enterprise#73551 Forward-Port-Of: odoo/enterprise#72679
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In the settings enable sbcontracting - Create 2 storable products tracked by SN: Final Product (FP) and COMP - Create a subcontracting BOM for FP with COMP as component - On COMP set the route Resupply Subcontractor on Order - Register 3 SN of COMP in stock: SN01, SN02, SN03 - Create and conf
Original PR description
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In…
We revert Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb as it allows to perform button actions on records with invalid datas. Notably because of unset required fields. ### Steps to reproduce: - In the settings enable sbcontracting - Create 2 storable products tracked by SN: Final Product (FP) and COMP - Create a subcontracting BOM for FP with COMP as component - On COMP set the route Resupply Subcontractor on Order - Register 3 SN of COMP in stock: SN01, SN02, SN03 - Create and confirm a PO for your subcontractor for 3 units of FP - Validate the Resupply picking - Go to the reciept and click "Record components" - Record your first Final product SN: FP01 (required) - Continue - Dont register any SN on the second and third recording #### > Since you will not be able to edit this required field later on, the registration of such a SN should be required on FP. #### > This leads to a softlock as the field is readonly afterwards. ### Cause of the Issue: Since Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb, the `_checkValidity` of the `_save` call do not happen if we are not at record creation or if no change has been applied on the record. However, in our case, we are not at creation of the record and we did not perfom any change on the record form so that the `_save` call will return `true` rather than the `false` he would return if he performed a `_checkValidity` of the record. This is a drastic difference since the returned value of this `_save` is used by the `formController` when you click a button in order to determine if he should proceed with the action or cancel the call: https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/form/form_controller.js#L497-L510 https://github.com/odoo/odoo/blob/9b5eed7e215b2601c25b9d81c42dfa1bc1d06fee/addons/web/static/src/views/view_button/view_button_hook.js#L49-L60 In particular, in our case, the action will be called even thought the "required onchange" (and associated "websave") was never called. What I mean by "required onchange" is that the "lot_producing_id" is a required field of our form: https://github.com/odoo/odoo/blob/4d5d270e72fdec49ffc31269642683b68984adca/addons/mrp_subcontracting/views/mrp_production_views.xml#L24-L27 Hence it needs to be set and provoke an onchange that will it self provoke a `web_save` of the new record value in the `_save` before it proceeds with the button action. ### Additional note on Commit fe4208c1ed7f9f59736d36930ba77541c19ffaeb: This commit was initially added to avoid displaying Invalid Field notifications when you open a record with invalid data as a `_save` is also called in the `openRecord` of the `ListController` for instance. To me even in that case, it is usefull even if unnecessary to know that some record data's are currently invalid. opw-4267852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185351 Forward-Port-Of: odoo/odoo#185134