Wednesday, October 23, 2024
34 changes · saas-17.2
Resolved issues and error corrections
This fixes an issue where the mass edit option could be hidden in Studio list views even when users were allowed to edit records. Users can now access mass editing based on their edit permissions, without needing to change record creation settings first.
Original PR description
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archInfo.activeActions.edit === true` opw-4272416
The onboarding tours for Documents and document accounting flows have been corrected so they work as expected. This helps new users follow guided setup steps more reliably and reduces confusion during onboarding.
Original PR description
Fixed onboarding document tours which was not working properly. Task-4210376
This update prevents tests from depending on website-specific data when Appointment is used on its own. It helps keep automated checks reliable for customers or deployments that do not install the Website app.
Original PR description
When running Appointment as single app, we have to make sure that test does not use any external models like 'website.menu'. fixes runbot build error [73105](https://runbot.odoo.com/web#id=73105&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72522 Forward-Port-Of: odoo/enterprise#72468
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
Original PR description
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#69948
Original PR description
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#69948
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#70405
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules. Forward-Port-Of: odoo/enterprise#71691
Original PR description
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules. Forward-Port-Of: odoo/enterprise#71691
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#71851
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of th
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of the Billing Time Target to 100. - Again open the leaderboard in the timesheet. ### Issue 'x/' is displayed without the new target value. ### Cause Due to the wrong regular expression for the value. ### Solution Correct the regular expression. task-3970348 Forward-Port-Of: odoo/enterprise#66825
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling
Original PR description
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications. Forward-Port-Of: odoo/enterprise#70697
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = T
Original PR description
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component -…
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = True` see: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L188-L191 However, when a product is added via the `action_add_component` > `add_product`, the `manual_consumption` of the move is computed as if it was added to the MO without being linked to a `bom_line_id`: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/wizard/additional_product.py#L36-L46 https://github.com/odoo/odoo/blob/2d652f42f63c2501b1a9feb7a4830ea3d7d05f51/addons/mrp/models/mrp_production.py#L1198 As a result the move_raw is added as a manual_consumption = False. ### Note: Thank to Commit eb751b5f861b25205dbb0b0fb90ddcdbbcd10f55 , the issue is not reproducible in 18.0 anymore. This was soved in the same manner: https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L36-L38 https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L107-L114 opw-4199156 Forward-Port-Of: odoo/enterprise#71803
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Cu
Original PR description
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration. i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount. opw-4081350 Forward-Port-Of: odoo/enterprise#72406 Forward-Port-Of: odoo/enterprise#72192
Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72260
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
Original PR description
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`.
Original PR description
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the…
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`. __Description of the fix:__ The `t-nocache` is put directly inside the header templates in order for all subsequent `t-set` to be accessible from its scope. __Example of steps to reproduce the issue on runbot:__ 1. On the website, click on the search button inside the header 2. Type "desk" for example No results are shown below the search box although when hitting ENTER, there are some results. This is due to the fact that the searchbox input lacks the `search_type="all"` attribute. opw-4246129 [1]: https://github.com/odoo/odoo/pull/180548 Forward-Port-Of: odoo/odoo#183465
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetche
Original PR description
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical"…
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetched (no fetching of unnecessary emails) * Email are marked as read after processing and NOT deleted Drawbacks of POP protocol that most end users are not necessarily aware of: * After fetching emails are deleted on the fetched mail server, i.e. no hard copy of the original mail is kept which might be an issue if a bug in Odoo fetches the mail "correctly" (routing succeeded), but a downstream bug creates side effects (attachments deleted, wrong record creted) * Since POP will try to fetch ALL mails in the inbox, if the customer (un)purposely hoards Odoo unrelated emails, these will be always fetched but never routed -> time spend for nothing routing, logs are spammed and percieved delay for fetching new emails (since older ones are processed for nothing over and over again) Proposed solution: Change `default` parameter to `imap` argument. Will not change old records ad-hoc, but preset new incoming email servers. User is free to still change the server type if they feel the need to use the POP protocol. Recent support tickets with related issues: OPW-4206157 OPW-4229682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183712
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when us
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be…
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Outlook, it will be correctly synchronized in Outlook as well. This approach will also reduce the possibility of duplicated events in Odoo side (and by transitivity, in Outlook side). task-4261237 Forward-Port-Of: odoo/odoo#183926
Some payment request are failing when sent to viva wallet. Steps to reproduce: ------------------- * Configure viva wallet payment for shop session * Configure one product to have a price unit of 5.1 and na taxes * Open shop session * Add that product to order (only once) * Select **Payment** * Select viva wallet payment method that you configured * Select **Send** > Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'lo
Original PR description
Some payment request are failing when sent to viva wallet.
Steps to reproduce:
-------------------
* Configure viva wallet payment for shop session
* Configure one product to have a price unit of 5.1 and na taxes
* Open shop session
* Add that product to order (only once)
* Select **Payment**
* Select viva wallet payment method that you configured
* Select **Send**
> Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'loc': ['body', 'amount'], 'msg': 'Input should be a valid integer, got a number with fractional part', 'input': 510.00000000000006, 'url': '...'}]
Why the fix:
------------
Just a floating point precision issue. `3.1 * 100 = 310` but `5.1 * 100 = 510.00000000000006`, explaining why the issue does not always happen.
opw-4076168
Forward-Port-Of: odoo/odoo#184048A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-Port-Of: odoo/odoo#183968
Have a parent company [PARENT] Create an invoice [INV1] Create a branch company [BRANCH] Create an invoice [INV2] for [BRANCH] company Go to invoice list view Select both companies Select both invoices Click 'Register Payment' Traceback ``` File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches return self.browse(self.__accessible_branches()) File "<decorator-gen-107>", line 2, in __accessible_branches File "[...]/odoo/tools/cache.py", lin
Original PR description
Have a parent company [PARENT]
Create an invoice [INV1]
Create a branch company [BRANCH]
Create an invoice [INV2] for [BRANCH] company
Go to invoice list view
Select both companies
Select both invoices
Click 'Register Payment'
Traceback
```
File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches
return self.browse(self.__accessible_branches())
File "<decorator-gen-107>", line 2, in __accessible_branches
File "[...]/odoo/tools/cache.py", line 97, in lookup
key = key0 + self.key(*args, **kwargs)
File "<string>", line 1, in <lambda>
File "[...]/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.company(2, 1)
```
opw-4027692
Forward-Port-Of: odoo/odoo#172792In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Original PR description
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Steps to reproduce: ------------------- * Make sure you have atleast 2 companies created * Create atleast one PoS in each company * Go in one of the company settings and look for Trusted Point of sale > Observation: You are able to select the PoS from the other company Why the fix: ------------ Adapt the domain to filter out PoS that are not part of the current company opw-4161351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
Steps to reproduce: ------------------- * Make sure you have atleast 2 companies created * Create atleast one PoS in each company * Go in one of the company settings and look for Trusted Point of sale > Observation: You are able to select the PoS from the other company Why the fix: ------------ Adapt the domain to filter out PoS that are not part of the current company opw-4161351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184466
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba">
Original PR description
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba"> Desired behavior after PR is merged: <img width="450" alt="Screenshot 2024-10-10 at 11 04 51 PM" src="https://github.com/user-attachments/assets/40f531a8-0d79-4eb6-a3d6-cd80abcb145c"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183280
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected.
Original PR description
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected. - While creating a PO, products from the branches appear in the product list. opw-4116680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180623
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-410782
Original PR description
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-4107823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180163
From saas-17.2, the module `l10n_fr_fec` was merged into the module `l10n_fr_account`, but the translations were not moved. This change fixes that by reapplying the French translations for FEC related terms. [opw-4150020](https://www.odoo.com/odoo/all-tasks/4150020)
Original PR description
From saas-17.2, the module `l10n_fr_fec` was merged into the module `l10n_fr_account`, but the translations were not moved. This change fixes that by reapplying the French translations for FEC related terms. [opw-4150020](https://www.odoo.com/odoo/all-tasks/4150020)
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field s
Original PR description
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field selector popover whether it closed because a final value was selected or not. task-4066184 Forward-Port-Of: odoo/odoo#184838
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have sig
Original PR description
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184785 Forward-Port-Of: odoo/odoo#184342
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product
Original PR description
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost…
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product Type Route = Manufacturing Category = AVCO or FIFO 2.) Create Product B: Storable Product Type Routes = Buy Category = AVCO or FIFO 3.) Make a BOM Product A Quantity = 1 Kit Components: 12 units of Product B 4.) Create a Purchase Order: Buy 1 unit of Product A at $100 5.) Confirm PO -> this will generate a receipt 6.) Validate receipt 7.) Note the valuation is 12 units @ a value of 99.96 where it should be 100 Current behavior before PR: svl.value = 99.96 Desired behavior after PR is merged: svl.value = 100 opw-4208554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184737 Forward-Port-Of: odoo/odoo#183267
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in
Original PR description
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes #94390 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184793 Forward-Port-Of: odoo/odoo#94395
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
Original PR description
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of:
Original PR description
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of: odoo/odoo#184845
This reverts commit dbf441123383982df14aa752b55719286c9d0391. This commit introduced an unexpected behaviour where the field seems to select by default the first choice but has no value. Forward-Port-Of: odoo/odoo#184886
Original PR description
This reverts commit dbf441123383982df14aa752b55719286c9d0391. This commit introduced an unexpected behaviour where the field seems to select by default the first choice but has no value. Forward-Port-Of: odoo/odoo#184886