Monday, September 20, 2021
43 changes · master
Enhancements to existing features
The employee organization chart now uses a clearer “See All” button when there are too many employees to display at once. This makes the chart easier to understand and gives the opened team view a proper name instead of showing an undefined label.
Original PR description
The display when too many employees where present wasn't very clear, 3 dots that were close to hidden because of the line right next to it, it has been replaced by a `See All` button instead, and the action executed upon clicking that button now has a name `Team` instead of `undefined`. TaskId-2648133
This change improves how Odoo reserves stock for deliveries and other inventory operations by processing reservations in batches. Businesses with larger inventories or many stock moves should see faster assignment of available products and reduced waiting time during warehouse workflows.
Original PR description
To increase the performance of action assign make it in batch the _gather of quants and filtered the domain efficiently. WIP add performance measurement. Co-authored-by: Tiffany Chang (tic) <tic@odoo.com> 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
The Time Off dashboard now shows an information tag beside leave types that require allocation. Hovering over it explains how the remaining balance is calculated, helping employees and managers understand allocated, approved, planned, and left days at a glance.
Original PR description
Purpose: From the dashboard, the user sees the number of left time offs, but does not have an information regarding how it is calculated. In this task, we add an information tag on the Time Off dashboard next to each Time Off type that requires allocation. When we hover over the tag, we see how is the number calculated. For example, it could look the following way: Allocated : 20 days Approved: 5 days Planned: 3 days Left: 12 days task - 2643115
This change improves the speed of calculating product and component availability, especially when viewing transfers with many stock moves. It helps reduce wait times for users working with inventory, purchasing, and manufacturing records, although the feature is still noted as work in progress.
Original PR description
Try to reactivate the "Product Availabilty" (Transfer ) and "Component Availability" (MO) in the tree view. These fields was slow to compute because of the slow computation of `_compute_forecast_information`. With "Product Availabilty" fields in the tree, to read 10 tranfers with 200 moves in each tranfers: Before patch: 0.29 +-0.05 (SQL) and 3.8 +- 0.68 (Python) = +-4.09 sec After patch: 0.22 +- 0.01 (SQL) and 0.57 +- 0.04 (Python) = +- 0.69 sec The patch working better for bigger sample, and less with smaller sample. WIP, it's still not enought to reactive the "Product Availability" in the tree.
The website mobile navigation no longer displays a burger menu when there are no menu items to show. This avoids confusing visitors with an empty menu and creates a cleaner mobile browsing experience.
Original PR description
Task ID: 2345001
Odoo now lets selected internal text fields skip accent-insensitive search processing when it slows down indexing. This improves performance for important navigation and hierarchy fields while keeping safer database query handling for website-related searches.
Original PR description
Covers tasks 2627454 (allow opting out of unaccent for indexing / performance reasons) and 2634851 (natively support `psycopg2.sql` in the unaccent wrapper). Task 2551518 (unaccent indexes) is ignored, as it's not clear whether that should be handled in the ORM (with workarounds for `unaccent` not being `IMMUTABLE`) or just documented as a danger (generally speaking behaviour with respect to `unaccent` seems completely undocumented currently so...).
The Time Off dashboard now shows when available days are valid until when the related allocation has an end date. If there are multiple allocations, it displays the closest upcoming validity period, helping employees plan time off before days expire.
Original PR description
After this commit, in the Time Off dashboard, the user can see the validity period of the available days in case if the related allocation has a validity end. If the time off has more than one allocation, we display the validity of the closest one. task - 2636403
The mobile menu is no longer shown when it has no options to display. This avoids confusing users with an empty menu and makes the mobile interface feel cleaner.
Original PR description
Task ID: 2345001
Resolved issues and error corrections
This fix prevents saved contact display names from being affected by temporary screen or language context settings. It reduces the risk of inconsistent or incorrect partner names appearing across Odoo, improving data reliability for users.
Original PR description
Because the field is stored it doesn't make much sense to have a context dependency and that can cause significant issues. However `name_get` looks pretty innocent and it's not necessarily insane to have a context dependency *there* (or even in the average `display_name` as they're normally non-stored computed fields). `_compute_display_name` previously blanked (blacklisted) just a few context values, but doing the opposite is probably the better idea. See also: odoo/odoo#68946 OPW-2453956 Task 2500978
Code cleanup and technical improvements
This update reorganizes how barcode check digits are calculated, preparing Odoo for broader GS1-128 barcode support. It helps make barcode handling more consistent across inventory and point-of-sale workflows, with little immediate change for end users.
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
Documentation and clarification updates
This pull request adds Layline Tech's corporate Contributor License Agreement signature to Odoo's records. It supports legal compliance for accepting contributions from the company and has no direct impact on product functionality.
Original PR description
[CLA] corporate signature for Layline Tech -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Since d1e227b07 and 242b1caa, the Pivot and Graph don't have the viewType attribute set anymore. Moreover, their filters don't have an "a" tag anymore. Forward-Port-Of: odoo/odoo#76584
Original PR description
Since d1e227b07 and 242b1caa, the Pivot and Graph don't have the viewType attribute set anymore. Moreover, their filters don't have an "a" tag anymore. Forward-Port-Of: odoo/odoo#76584
This fix updates the Belgian group insurance salary configurator so it works with a recent underlying change in salary benefit calculations. Users configuring Belgian employee salary packages with group insurance should no longer encounter the reported error.
Original PR description
throwing error The module was made in 14.4 but due to a function change in 14.5 (`_get_advantages_values` now returns 5 values instead of 4) the module was not updated properly during the fw-port as the test that loads the salary configurator apparently did not have the group insurance module loaded during the test. TaskId-2648429
This fix prevents certain internal hierarchy fields from being processed in a way that could make financial and consolidation reporting lookups less reliable. It helps keep account consolidation and financial report structures accurate without changing day-to-day user workflows.
Original PR description
Enterprise version of odoo/odoo#76436: enterprise has a pair of `parent_path` fields and they should be opted out of unaccent.
Issue: When creating a scrap (Inventory > Operations > Scrap) for a product tracked by lots, introducing a new lot number requires a company which is hidden when the user is in single-company mode, but not filled. And it is required by the model Steps to reproduce: Multi-Company environment, Lots&Serial enabled 1) Install Inventory 2) Create a product [Lot Product] Product Type: Storable Product Tracking (Inventory tab) : tracked by lot 3) Create a new user with access rights U
Original PR description
Issue: When creating a scrap (Inventory > Operations > Scrap) for a product tracked by lots, introducing a new lot number requires a company which is hidden when the user is in single-company mode,…
Issue: When creating a scrap (Inventory > Operations > Scrap) for a product tracked by lots, introducing a new lot number requires a company which is hidden when the user is in single-company mode, but not filled. And it is required by the model Steps to reproduce: Multi-Company environment, Lots&Serial enabled 1) Install Inventory 2) Create a product [Lot Product] Product Type: Storable Product Tracking (Inventory tab) : tracked by lot 3) Create a new user with access rights User to inventory module 4) Log in with new user 5) Inventory > Scrap Orders > Create Product : Lot Product Lot/serial: Create a new one This will open a window, refill the product information and hit save -> Bug field company_id not set but is required `Error message The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Lot/Serial (stock.production.lot), Field: Company (company_id)` Why is that a bug: Since we cannot see the company id to set it, and that we are in single company mode, by default the field should be filled by the env company opw-2593476 Forward-Port-Of: odoo/odoo#75855
Issue: When changing the bill date (invoice_date) of a vendor bill, the due date (invoice_payment_term_id) is not updated correctly Steps to reproduce : 1) Install Accounting, Purchase 2) Create a vendor bill 3) (debug) Edit the view, remove the invisible attr for the div with label invoice_payment_term_id 4) For the vendor bill, in that order, set the Vendor, then the due date to 30 days, then bill date, then add a product 5) Due date is now set to 30 days after the bill date 6) Cha
Original PR description
Issue: When changing the bill date (invoice_date) of a vendor bill, the due date (invoice_payment_term_id) is not updated correctly Steps to reproduce : 1) Install Accounting, Purchase 2) Create a vendor bill 3) (debug) Edit the view, remove the invisible attr for the div with label invoice_payment_term_id 4) For the vendor bill, in that order, set the Vendor, then the due date to 30 days, then bill date, then add a product 5) Due date is now set to 30 days after the bill date 6) Change the Bill Date -> Due Date stays unchanged opw-2627686 Forward-Port-Of: odoo/odoo#76671 Forward-Port-Of: odoo/odoo#76068
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#76632
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#76632
Problem 1 steps to reproduce the bug: - Install `l10n_cl` - Create a new company - Choose for example Algeria in country. - Enter this VAT number: CL220604497 - Save - edit - Change the country to Chile problem: VAT number is not formatted according to the Chilean VAT formatting, Because in the write function we do not trigger the VAT formatting when the country changes Bug introduced in this commit: https://github.com/odoo/odoo/commit/11ec94df926db98265d26af1072a0c8bf1843
Original PR description
Problem 1 steps to reproduce the bug: - Install `l10n_cl` - Create a new company - Choose for example Algeria in country. - Enter this VAT number: CL220604497 - Save - edit - Change the country to…
Problem 1 steps to reproduce the bug:
- Install `l10n_cl`
- Create a new company
- Choose for example Algeria in country.
- Enter this VAT number: CL220604497
- Save
- edit
- Change the country to Chile
problem:
VAT number is not formatted according to the Chilean VAT formatting,
Because in the write function we do not trigger the VAT formatting when the country changes
Bug introduced in this commit: https://github.com/odoo/odoo/commit/11ec94df926db98265d26af1072a0c8bf1843083
Problem 2, steps to reproduce the bug:
When you install `l10n_cl`, a Chilean company is created with these demo data: https://github.com/odoo/odoo/blob/7cc252908b33b7d77d45d0630464e203b25b09dc/addons/l10n_cl/demo/demo_company.x15ml#L
- The VAT is formatted according to the standard formatting instead of the Chilean vat formatting,
Because the field `" l10n_latam_identification_type_id "` is not defined: https://github.com/odoo/odoo/blob/f3a66dd65d041ffc7367d85d5603e9627efb9f2b/addons/l10n_cl/models/res_partner.py#L33-L34
so we will have this result: CL220604497 instead of 22060449-7
- create a vendor bill with this company
- try to print it
- a traceback is triggered, because we call the `_format_dotted_vat_cl` function which divides the vat in two parts
based on the dash and then processes the result without checking that there are two elements in the result.
As in our case here. The vat has no dash in the middle, so we will only have one part
an error is triggered when the function tries to access the 2nd element
https://github.com/odoo/odoo/blob/2b500c12c2540e593f3a243bf80de28bd335b7be/addons/l10n_cl/views/report_invoice.xml#L53
FYI: https://www.fonoa.com/countries/chile#:~:text=Chilean%20VAT%20number%20contains%207,567%2D8).
opw-2630877
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#75581Forward-Port-Of: odoo/odoo#76548
Original PR description
Forward-Port-Of: odoo/odoo#76548
commit bc1a6faa51fef60bb64ea09f4e43f1120f9855bd add a rule to fix tracability report but on a global level. However we won't this behavior everywhere in odoo or at least if it's the case it shouldn't be specify there Forward-Port-Of: odoo/odoo#76589
Original PR description
commit bc1a6faa51fef60bb64ea09f4e43f1120f9855bd add a rule to fix tracability report but on a global level. However we won't this behavior everywhere in odoo or at least if it's the case it shouldn't be specify there Forward-Port-Of: odoo/odoo#76589
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#76451
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#76451
When the user search for an industry in the industry autocomplete input, an information message is now displayed if no industry match the user's search. 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#74873
Original PR description
When the user search for an industry in the industry autocomplete input, an information message is now displayed if no industry match the user's search. 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#74873
Menu and footer background colors are retrieved from scss and added to the palettes. The chosen palette is sent to iap-service for the theme preview svg generation. From now on iap-service will be able to use specific menu and footer color for the svg preview generation. task-2602521 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
Original PR description
Menu and footer background colors are retrieved from scss and added to the palettes. The chosen palette is sent to iap-service for the theme preview svg generation. From now on iap-service will be able to use specific menu and footer color for the svg preview generation. task-2602521 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#75836
Monday is commonly accepted as the first day of the week in the UK. Listed as first option on https://www.unicode.org/cldr/cldr-aux/charts/29/supplemental/territory_information.html#GB with Sunday as an alternative. All mayor OS (Windows, Mac, iOS) use Monday as the first day of the week when the locale en_GB is used. Description of the issue/feature this PR addresses: uncommon first day of the week for en_GB Current behavior before PR: Sunday is selected as first day of the week De
Original PR description
Monday is commonly accepted as the first day of the week in the UK. Listed as first option on https://www.unicode.org/cldr/cldr-aux/charts/29/supplemental/territory_information.html#GB with Sunday as an alternative. All mayor OS (Windows, Mac, iOS) use Monday as the first day of the week when the locale en_GB is used. Description of the issue/feature this PR addresses: uncommon first day of the week for en_GB Current behavior before PR: Sunday is selected as first day of the week Desired behavior after PR is merged: Monday becomes first day of the week for en_GB Forward-Port-Of: odoo/odoo#76539
Remove hardcoded value and extra space. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76781
Original PR description
Remove hardcoded value and extra space. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76781
After the conversion of the graph and pivot views done in #73311, it was no more possible to open the forecast_graph and forecast_pivot views. This is due to the fact that the new View component cannot manage a legacy view: every extension of a converted view must be converted. We thus convert forecast_graph and forecast_pivot. Forward-Port-Of: odoo/odoo#76588
Original PR description
After the conversion of the graph and pivot views done in #73311, it was no more possible to open the forecast_graph and forecast_pivot views. This is due to the fact that the new View component cannot manage a legacy view: every extension of a converted view must be converted. We thus convert forecast_graph and forecast_pivot. Forward-Port-Of: odoo/odoo#76588
This is a start for integrating the llevanza de libros registro (reduced e-invoice) system in Odoo. - For that, we use account_edi as every invoice needs to keep the status of having been sent correctly or not. The idea is just to effectively only send once a day instead of every hour or so. - Right now, it is just generating an incorrect json, but the goal is to use the certificates to connect through zeep to the government. - Fields were added on the taxes and the invoice, but this m
Original PR description
This is a start for integrating the llevanza de libros registro (reduced e-invoice) system in Odoo. - For that, we use account_edi as every invoice needs to keep the status of having been sent correctly or not. The idea is just to effectively only send once a day instead of every hour or so. - Right now, it is just generating an incorrect json, but the goal is to use the certificates to connect through zeep to the government. - Fields were added on the taxes and the invoice, but this means that for master, we should already configure those in the l10n_es module and check if these fields are really necessary, if there is another way to configure them, ... 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#76514 Forward-Port-Of: odoo/odoo#70302
Issue: The button # To Process in mrp/views/stock_picking_views.xml at line 33 uses the domain state confirmed, draft, planned, or progress But the default filter, which is called "to do", show those 4 states + to_close (in mrp/views/mrp_production_views.xml line 309) Side-Note: Issue also present in 14.0, so starting the bug fix from here. 12.0 doesn't seem to have a to_close state but the count and filter domain also do not match Steps to reproduce in 14.0 On Runbot, go to Inve
Original PR description
Issue: The button # To Process in mrp/views/stock_picking_views.xml at line 33 uses the domain state confirmed, draft, planned, or progress But the default filter, which is called "to do", show those…
Issue: The button # To Process in mrp/views/stock_picking_views.xml at line 33 uses the domain state confirmed, draft, planned, or progress But the default filter, which is called "to do", show those 4 states + to_close (in mrp/views/mrp_production_views.xml line 309) Side-Note: Issue also present in 14.0, so starting the bug fix from here. 12.0 doesn't seem to have a to_close state but the count and filter domain also do not match Steps to reproduce in 14.0 On Runbot, go to Inventory click on the "# to process" button on a Manufacturing card. - Choose any MO and create a work order. On this work order, click "Start", then "Done". - The MO is now in the "To Close" stage. - Go back to Inventory Overview. The number to process has gone down by one. - Click on the "# to process" button, you will see that the "To Close" MO appears in the list but is not counted by the button. (written by dido) For 13.0 I haven't been able to find steps to reproduce but the button has not changed between the two versions opw-2636447 Forward-Port-Of: odoo/odoo#76804 Forward-Port-Of: odoo/odoo#76007
A bug currently prevents opening the editor from a translated version of the homepage, for example `/nl_BE` (it works for other paths though). It is caused because the method `_goToMasterPage` can't find a trailing forward slash after the language code in the url path. When clicking on the "Edit in master" button, the page now correctly redirects to the master version, solving the problem. task-2622270 Forward-Port-Of: odoo/odoo#76770 Forward-Port-Of: odoo/odoo#76059
Original PR description
A bug currently prevents opening the editor from a translated version of the homepage, for example `/nl_BE` (it works for other paths though). It is caused because the method `_goToMasterPage` can't find a trailing forward slash after the language code in the url path. When clicking on the "Edit in master" button, the page now correctly redirects to the master version, solving the problem. task-2622270 Forward-Port-Of: odoo/odoo#76770 Forward-Port-Of: odoo/odoo#76059
This will close the RTC session when a user leave a channel with a RTC session open. task-2646095 Forward-Port-Of: odoo/odoo#76721
Original PR description
This will close the RTC session when a user leave a channel with a RTC session open. task-2646095 Forward-Port-Of: odoo/odoo#76721
[CLA] corporate signature for Layline Tech -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76817
Original PR description
[CLA] corporate signature for Layline Tech -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76817
Update header message to match changes in the following commit: https://github.com/odoo/odoo/commit/8ba6e3b0c3bf856308b4d58158392d0e99d2b58e opw-2631125 Forward-Port-Of: odoo/odoo#76766 Forward-Port-Of: odoo/odoo#76748
Original PR description
Update header message to match changes in the following commit: https://github.com/odoo/odoo/commit/8ba6e3b0c3bf856308b4d58158392d0e99d2b58e opw-2631125 Forward-Port-Of: odoo/odoo#76766 Forward-Port-Of: odoo/odoo#76748
In response to https://github.com/odoo/odoo/pull/60632#issuecomment-917924686 Forward-Port-Of: odoo/odoo#76387
Original PR description
In response to https://github.com/odoo/odoo/pull/60632#issuecomment-917924686 Forward-Port-Of: odoo/odoo#76387
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#76694
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#76694
The debug item "Edit ControlPanelView" is only available if there is a control panel in the current view. 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#76813
Original PR description
The debug item "Edit ControlPanelView" is only available if there is a control panel in the current view. 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#76813
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#76695
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#76695
Before this commit, the grid lost the focus after a dialog (notifyUser, ...) has been closed Task-id 2631877 Forward-Port-Of: odoo/enterprise#20941 Forward-Port-Of: odoo/enterprise#20526
Original PR description
Before this commit, the grid lost the focus after a dialog (notifyUser, ...) has been closed Task-id 2631877 Forward-Port-Of: odoo/enterprise#20941 Forward-Port-Of: odoo/enterprise#20526
It seems that with the recent owl changes, do_action pops the dialog twice when an error occurs. By changing `do_action` into a `trigger_up('do_action')` that problem does not occur anymore. TaskId-2618694 Forward-Port-Of: odoo/enterprise#20859
Original PR description
It seems that with the recent owl changes, do_action pops the dialog
twice when an error occurs. By changing `do_action` into a
`trigger_up('do_action')` that problem does not occur anymore.
TaskId-2618694
Forward-Port-Of: odoo/enterprise#20859move the popover of a sign item into o_sign_template Before this commit When we edit a sign template 1. click a sign item and open its options 2. click "template" button in the navigation without clicking "validate" or "x" button 3. you will find a trackback taskid: 2645074 Forward-Port-Of: odoo/enterprise#20923 Forward-Port-Of: odoo/enterprise#20828
Original PR description
move the popover of a sign item into o_sign_template Before this commit When we edit a sign template 1. click a sign item and open its options 2. click "template" button in the navigation without clicking "validate" or "x" button 3. you will find a trackback taskid: 2645074 Forward-Port-Of: odoo/enterprise#20923 Forward-Port-Of: odoo/enterprise#20828
- Create a subscription S with an end date 31.12.2020 (with recurring_rule_boundary == fixed) - Let's consider we are the 01.01.2021 (the cron Sale Subscription: generate recurring invoices and payments is applied) Bug: The end date of S was changed into 01.01.2021 instead of keeping 31.12.2020 So the year end invoicing was 2021 instead of 2020. PS: When the subscription is fixed, we only change the date end if we close it before the expected end. Fine tuning of https://github.com/
Original PR description
- Create a subscription S with an end date 31.12.2020 (with recurring_rule_boundary == fixed) - Let's consider we are the 01.01.2021 (the cron Sale Subscription: generate recurring invoices and payments is applied) Bug: The end date of S was changed into 01.01.2021 instead of keeping 31.12.2020 So the year end invoicing was 2021 instead of 2020. PS: When the subscription is fixed, we only change the date end if we close it before the expected end. Fine tuning of https://github.com/odoo/enterprise/commit/e06a2a14c67d5a7c04a8d6716d2c4e8ee7297146 opw:2449986 Forward-Port-Of: odoo/enterprise#20930
* show the field in mobile and median sized window * show correct style when the window size is extra small, medium and large before this task: the signer selection region of sign.send.request is hidden when the window size is medium or smaller as a result, the user cannot send sign.requests taskid: 2628872 Forward-Port-Of: odoo/enterprise#20851
Original PR description
* show the field in mobile and median sized window * show correct style when the window size is extra small, medium and large before this task: the signer selection region of sign.send.request is hidden when the window size is medium or smaller as a result, the user cannot send sign.requests taskid: 2628872 Forward-Port-Of: odoo/enterprise#20851
_analyze_sii_result interprets the response from the SII and does this by checking a bunch of conditions and known response codes. If a code occurs that it doesn't recognize (like 107 instead of 106) or if the XML contents are different than expected, it will implicitly return None as the function reaches its end without explicitly returning anything. This causes problems because it will result in the SII status getting cleared and the invoice getting stuck in that state. This fix pre
Original PR description
_analyze_sii_result interprets the response from the SII and does this by checking a bunch of conditions and known response codes. If a code occurs that it doesn't recognize (like 107 instead of 106)…
_analyze_sii_result interprets the response from the SII and does this by checking a bunch of conditions and known response codes. If a code occurs that it doesn't recognize (like 107 instead of 106) or if the XML contents are different than expected, it will implicitly return None as the function reaches its end without explicitly returning anything. This causes problems because it will result in the SII status getting cleared and the invoice getting stuck in that state. This fix prevents that from happening by aborting the operation if we don't recognize the response. This means the SII status will remain the same as it was before. This also assumes that the unexpected response is temporary and only happens intermittently. Another attempt will occur the next time the related cron job is scheduled to run. If the unexpected response turns out to be more regular, handling it should be implemented properly in _analyze_sii_result. Ticket: 2524452 Forward-Port-Of: odoo/enterprise#20868 Forward-Port-Of: odoo/enterprise#20429
Forward-Port-Of: odoo/enterprise#20919
Original PR description
Forward-Port-Of: odoo/enterprise#20919