Friday, March 7, 2025
17 changes · 18.0
Resolved issues and error corrections
This fixes the mobile call screen so the full call interface, including participant visibility, fits properly on smaller displays. Users joining calls from mobile devices should have a clearer, more usable experience without hidden or cramped controls.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/175858, the call view in mobile was too small to fit all of the call UI, this commit fixes this issue. | Before | After | |--------|--------| |  |  |
This fix ensures that intercompany replenishment creates the purchase order in the company that owns the buying rule, rather than the company requesting the stock. It prevents purchase orders from being created in the wrong company or failing because the expected vendor is only configured in the supplying company.
Original PR description
### Issue: Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1…
### Issue: Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1 rather than COMP2. ### Steps to reproduce: - In the settings enable Multi-steps routes - Have two companies: COMP1 and COMP2 - Create a routes without set companies with 3 rules: - rule 1 (comp1): - Pull from Virtual Locations/Inter-company transit to WH1/Stock supply method: Trigger an other rule. - rule 2 (comp2): - Pull from WH2/Stock to Virtual Locations/Inter-company transit, supply method: Trigger an other rule. - rule 3 (comp2): - Buy from Partner/vendors to WH2/Stock using a custom operation type towards Virtual Locations/Inter-company transit. - Create a storable product with both routes set. - With COMP2: set a vendor on that product. - In COMP1, your product > Reordering rules create a new rule using the COMP1 route to replenish WH1/Stock. - With both COMP1 and COMP2 as active order once. > The PO could not find a vendor as it looked for suppliers in COMP1 and if such a supplier was set in COMP1, the PO would be created in COMP1. ### Cause of the issue: While the rule of COMP2 is found and used to run the procurment here: https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_rule.py#L484 the procurement was created and is linked to the company owning the move creating the demand (that is COMP1): https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_move.py#L1494-L1498 However, the `company_id` used in the `_run_buy` notably for the data's of the PO will be the company linked to the procurement rather than the company linked to the buy rule. Since the buy rule should generate a purchase order in company it uses, this is incorrect. opw-4578965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how eCommerce handles free combo products and combo items when zero-price sales are blocked. Businesses can now enforce the zero-price restriction on the overall combo product while still allowing free items inside a paid combo, preventing checkout issues and unintended free sales.
Original PR description
Previously: - Zero-priced combo products could always be sold on eCommerce. However, this shouldn't be allowed if `prevent_zero_price_sale` is enabled. - Zero-priced combo items couldn't be sold on eCommerce if `prevent_zero_price_sale` was enabled. However, this should always be allowed since only the price of the combo product matters (not its items).
This fix prevents Czech bank reconciliation from incorrectly replacing a manually chosen bank transaction date with today’s date. It keeps taxable supply date rules for Czech accounting where appropriate while avoiding wrong dates on bank transactions.
Original PR description
- Install l10n_cz and switch to a cz company. - In bank reconciliation, create a new bank transaction and set its date to a past or future date (not today) The date of the newly created bank transaction is automatically set to today. In the Czech Republic, it is required to use the taxable supply date as the accounting date. This functionality was introduced by 184c1e65a9992e890af81bb60eeeb7b8b825ab54. However, it also sets the taxable supply date for bank transactions, which is incorrect. opw-4544305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kiosk orders paid through a payment terminal now appear on the preparation display only after payment is completed. This prevents staff from preparing orders that may not be successfully paid, while still supporting counter payment flows.
Original PR description
to reproduce: ============= - Setup kiosk on POS shop using Stripe or other payment terminal - Open the Preparation display for the shop and start the kiosk - When an order is sent to the terminal on the kiosk, the order appears on the prep display immediately before payment is completed Problem: ======== the issue is introduced when we allowed for he customer to pay on the counter, the order is sent to the preparation display before the payment is completed Solution: ========= add a flag in context to tell if payment should be done in kiosk or on the counter opw-4556029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents two devices from recording the same point-of-sale session opening at the same time. It keeps cash opening records and session numbering accurate, improving reliability for stores using multiple devices.
Original PR description
Before this commit, if a session was opened on two devices concurrently, both devices could set the opening control. This resulted in duplicate opening cash setting and a gap in the session ID sequence. This fix ensures that opening control is set only once, maintaining correct session tracking. opw-4627585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product search now returns all relevant matching products instead of limiting results to exact matches. This aligns search behavior with the removal of fuzzy search and helps staff find products more reliably during checkout.
Original PR description
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents inventory reservation cleanup from trying to process kit products in a way the system does not support. It helps users avoid blocking errors when opening or updating inventory quantities after a product has been changed into a kit.
Original PR description
Since this commit: https://github.com/odoo/odoo/pull/188201/commits/766ec99dbc2701a237f082f3fb124793d9dfe596 We try to clean reservations because, for some reason, there could be a discrepancy…
Since this commit: https://github.com/odoo/odoo/pull/188201/commits/766ec99dbc2701a237f082f3fb124793d9dfe596 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”. However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant. Solution: For kits, we can skip cleaning their quant to avoid unnecessary errors. opw-4625002 opw-4624008 opw-4621175 opw-4625465 opw-4621504 opw-4623523 opw-4621508 opw-4623329 opw-4629386
The Point of Sale screen now displays extra charges for combo product choices when staff select a combo item. This helps cashiers and customers see the correct pricing upfront, reducing confusion and checkout errors.
Original PR description
Extra prices are not displayed in the POS when selecting a combo product with defined combo choices. When a combo product is created with combo choices that have extra prices, those extra prices should be visible in the POS interface. Steps to Reproduce: 1. Create a new combo product with multiple combo choices. 2. Set an extra price for one or more of the combo choices. 3. In the POS, select the combo product. 4. Notice that the extra price is not shown. opw-4485134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes how the editor identifies reusable website content blocks so only the intended main snippet is selected and checked. This prevents confusing empty option panels and false outdated-snippet warnings when using masonry and accordion-style snippets.
Original PR description
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing…
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing because of this multiple level snippet. (e.g: s_masonry_block > s_masonry_block_default_template > Block) Yet this middle level has no options on its own. so it was unnecessary to have an options section for the 'sub-snippets'. This commit just prevent to be able to select the 'sub-snippets'. Furthermore, due to those 'sub-snippets' being contained inside the s_masonry_block snippet, they would not get registered in the list of all the snippets, and then the website would failed to determine their version which raised the 'outdated_snippet' alert. Preventing the selection of those 'sub-snippet' thus also prevent the website checking their version. As of now none of these sub-snippets have different version than the basic s_masonry_block so I guess we can just ignore that since they are not designed to change from the basic s_masonry_block options. And if so should happen in the future they would probably become completely independant snippets. Steps to reproduce : - Enter edit mode - Drag and drop a s_masonry_block snippet - Select one of the blocks of the snippets - On the options panel an errored 'Block' option section appeared. - Click on 'access options anyway', the section is then empty. [1] : https://github.com/odoo/odoo/pull/183755 task-4508767
Document uploads now use the company currently selected by the user instead of defaulting to the user's main company. This ensures company-specific default values are applied correctly in multi-company setups, reducing errors in document ownership and configuration.
Original PR description
### Issue: - When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company. ### Steps to reproduce: - In a…
### Issue: - When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company. ### Steps to reproduce: - In a multi-company environment say we have companies A(id: 1) and B(id: 2), and the user default company is A. (he has access to both). - Create 2 user-defined defaults for the field : `documents.document.company_id`, setting value to 1 for company A and 2 for company B. - Create a document using company B, the document's `company_id` will be set to company B which is wrong. ### Solution: - in controllers `request.env.company` always returns the user's default company, so whenever we upload a document (call the `documents_upload` controller), `documents.document` create assumes that the current company is the user's default company. - To fix this, we add the `allowed_company_ids` to the upload request params in the JS `DocumentService` and we intercept in the python controller and set the `allowed_company_ids` context on the request to make sure create will use the current company instead. OPW-4507424
Cash payments in German POS are now reported to Fiskaly based on the payment method type, not the payment method name. This prevents renamed cash methods from being incorrectly shown as non-cash in certification records and dashboards.
Original PR description
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------------ We should base the payment type on the payment method type and not on the payment method name. opw-4606731
This fixes issues in Documents where some embedded actions, such as creating a vendor bill from the Finance folder, could not be removed. It also ensures those actions remain available when documents are accessed through shortcut folders, improving consistency for users.
Original PR description
First commit: Fix a bug which prevents un-embedding actions: Reproduce: 1. Install documents_account 2. Go to the finance folder 3. Try to un-embedd the action "Create a Vendor Bill" 4. You can't This occurs because we created the embedded actions by passing a group in the data, but we can't do that in the UI, so we cannot un-embed the existing action. This also means that groups cannot be enforced at the embedded actions level using their groups_id field, but rather the groups_id field of the related server action, and it was actually redundant. Thankfully these records are correct. Second commit: Fix using embedded actions when viewing documents from a container shortcut. Task-4525850
Kiosk orders paid through a terminal are no longer sent to the preparation display before payment is completed. This prevents staff from preparing unpaid orders while still supporting orders that will be paid at the counter.
Original PR description
to reproduce: ============= - Setup kiosk on POS shop using Stripe or other payment terminal - Open the Preparation display for the shop and start the kiosk - When an order is sent to the terminal on the kiosk, the order appears on the prep display immediately before payment is completed Problem: ======== the issue is introduced when we allowed for he customer to pay on the counter, the order is sent to the preparation display before the payment is completed Solution: ========= add a flag in context to tell if payment should be done in kiosk or on the counter opw-4556029
This update improves how Ecuadorian delivery guides are generated, especially for companies operating in multiple-company setups. It helps ensure the correct company-specific issuing details, customer receiver information, product codes, sequences, and authorization dates are used in electronic and PDF documents.
Original PR description
- For a multicompany environment it is useful to be able to restrict the unique emission point and entity point per company. - The support of the commercial partner is needed for electronic and pdf documents. We use the commercial_partner_id for the receiver. - We place the main code and auxiliary code as in the other documents. The main code is the result of the barcode or default_code or N/A (is required field in xml) - We improve the creation of the sequence in a warehouse when the record is not yet committed. - To generate the authorization number we use the start date of the delivery guide
This fix changes how DIAN demo mode is stored so existing databases are not broken when the module has not been updated. It helps keep Colombian electronic invoicing configurations stable during regular updates.
Original PR description
Issue ----- This commit[^1] added a field in stable version which breaks the database if the module is not updated. Fix --- Instead of using a column in stable, use a config param. [^1]: a6d593a406be75995454eb0666d1d
Resetting invoices to draft now correctly removes deferred entries that were never posted, instead of creating unnecessary reversals. This prevents leftover scheduled accounting entries and keeps deferred revenue or expense records cleaner when audit trail is enabled.
Original PR description
Steps to reproduce: - 1. Activate audit trail. 2. Make a customer invoice with start and end date [end date should be in future months], and post. 3. Reset the invoice to draft - Result: All deferred entries are reversed with new entries at the date of the reset to draft. The unposted deferred entries are still there with auto post At Date. Cause: - Audit trail alone doesn't prevent the moves from being deleted if they were not posted before, so the check shouldn't be only on the company_id.check_account_audit_trail, but also we should consider move.posted_before and if not, it should be deleted not reversed. Fix: - Replace the company_id.check_account_audit_trail check with _is_protected_by_audit_trail() which includes checking if the move is posted before or not. opw - 4562732