Daily updates from Odoo
Navigate
Branch
Wednesday, March 13, 2024
68 changes
21 changes
Enhancements to existing features
This update enhances the Odoo accounting system to correctly handle Value Added Tax (VAT) for Kenyan businesses. Specifically, VAT payable and receivable accounts have been created and linked to all tax groups, ensuring accurate tax reporting and compliance with local regulations. This change simplifies VAT management within Odoo.
Original PR description
In this pr I renamed account 220100 to KRA - VAT payable and created the new KRA - VAT receivable accounts. These accounts are now used as the Tax Payable and Tax Receivable accounts on all the tax groups task: 3725559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153646
This update enhances the payment term preview in the accounting module by using colors and borders to make the preview more visually distinct. This helps users quickly understand the results of their changes and clearly identifies the editable fields that control the preview. It’s a small improvement that boosts usability.
Original PR description
Emphasize the preview with colors and field borders to: - visually outline the preview result - clarify to the user that there are editable fields which customize the preview task: 3751514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155367
Resolved issues and error corrections
This update fixes a minor issue where the Google and Outlook calendar sync buttons wouldn't automatically update their status after a sync restart. By introducing new states for reactive values, the buttons now correctly reflect the current sync status, improving user experience.
Original PR description
This PR aims to fix an issue with google/outlook sync buttons: The button state doesn't update automatically after restarting the sync. Changes: Introduced new states for the reactive values of the model, which control how the button is displayed. Task: 3731623 Forward-Port-Of: odoo/odoo#155174
This update fixes a discrepancy in the shipping dates used when creating procurement orders through Point of Sale. Previously, the scheduled delivery date was incorrectly calculated by one day. This change ensures accurate date planning for deliveries, improving order fulfillment and reducing potential delays.
Original PR description
Since `shipping_date` is a field `Date` but `date_planned` is a field `datetime`, before this commit, the `date_planned` in picking was one day less. complementary to https://github.com/odoo/odoo/commit/fe9e230b500af316e6f80af453a4073d9dff24b7 - Enable `Allow Ship Later` into a pos config - Create a new order and set a `Ship Later Date`  - Go to backend and navigate to picking and Scheduled Date is 02/27 instead of 02/28  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#154533
This update resolves a technical error that occurred when a user deleted a company within Odoo. The fix ensures that onboarding progress data is properly removed, preventing errors and maintaining data consistency. This improves the stability of the accounting and sales modules.
Original PR description
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open…
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open Accounting 7. You receive an error: > ValueError: Expected singleton: onboarding.progress(1, 2) ### Explanation: In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all. https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69 This is due to the fact that some onboardings are not related to a company while others are. After that, getting the `onboarding_state` will trigger an `ensure_one` check. In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it. ### Suggested fix: `ondelete` decorator would require the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade. opw-3762382 Forward-Port-Of: odoo/odoo#155407
This update fixes inconsistent alert margins in Odoo forms, ensuring a cleaner and more professional appearance. By standardizing the margin for alerts above form sheets, the design is now more aligned with the status bar and other key UI elements. This change impacts several modules including account, sales, and CRM.
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR introduces a custom property `--alert-margin-bottom` which allows the customization of the alert's margin bottom depending on its context. This ensure that an alert rendered in the form view above the form_sheet will receive the appropriate margin as long as there is no utility class or override on the alert with this property, which is why this PR removes the mb-x classes or inner styling on the impacted alerts. task-3577058 Enterprise PR: https://github.com/odoo/enterprise/pull/52726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156927 Forward-Port-Of: odoo/odoo#146196
This update fixes an issue where holiday accrual calculations were not updating correctly when the end date of an accrual plan was set in the past. Previously, the system didn't reflect changes to the accrual plan's end date when calculating the number of accrued days. Now, the system accurately updates the number of days based on the date_from, accrual_plan_id, and date_to, ensuring accurate holiday accrual tracking.
Original PR description
Description of the issue/feature this PR addresses:
Create an allocation for an accrual plan in the past will prevent number_of_days computation
- Create an accrual plan to give 1 day per month
- Create an allocation with this plan
- Update date_from and/or accrual_plan_id
- number_of_days is updated
- Set date_to in the past (1)
- Update date_from and/or accrual_plan_id (1)
- Set date_to in the future (1)
- Update date_from and/or accrual plan
- number_of_days is updated
Current behavior before PR:
- (1) number_of_days is not updated
- number_of_days is computed from date_from to now
Desired behavior after PR is merged:
- number_of_days updated on date_from/accrual_plan_id/date_to change
opw-3764865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#157030This update corrects a translation error in the German localization of the 'l10n_din5008_sale' module. "Sales Order" now correctly translates to "Auftragsbestätigung" in German, ensuring accurate reporting and user experience. This was a previous fix that was accidentally reverted during a system update.
Original PR description
In the German localization, "Sales Order" MUST be translated as "Auftragsbestätigung". In all other cases it can remain as "Verkaufsauftrag". Term was previously corrected but then overwritten by accident during fw-port that used old translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157424
This update corrects a visual issue where a tax destination field was incorrectly hidden in the partner view when displayed within a list of related items. The fix utilizes the correct 'column_invisible' attribute to ensure the field is properly visible. This resolves a minor cosmetic problem, improving the overall user experience.
Original PR description
In one2many, for the view, the attribute to hide a field should be column_invisible and not invisible --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157356
This update fixes an issue where orderpoints weren't being created correctly for products moving through warehouse sublocations. Previously, only specific outgoing movements triggered orderpoint updates. Now, any movement from a sublocation within the main warehouse location will automatically generate a new orderpoint, ensuring accurate inventory management.
Original PR description
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of…
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of the main warehouse location should be considered as a out move. The inverse condition doesn't make much sense. Current behavior before PR: Let's use a simple example: - create a new product. - create an outgoing movement from shelf 1. - click on "Replenisment" menu. No orderpoint for the new product.  Desired behavior after PR is merged: A new orderpoint should have been created at WH/Stock for that product. See below with the fix:  @ForgeFlow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157287 Forward-Port-Of: odoo/odoo#156903
This update fixes an issue where the price displayed in the shopping cart wasn't correctly reflecting the customer's website tax settings (tax included or excluded). The fix ensures that the cart price accurately calculates the product price, including any applicable taxes, based on the configured website settings. This improves the accuracy and consistency of pricing for customers.
Original PR description
To reproduce: ============= - In the Settings: Product prices displayed on the website set as "Tax Included". - Created a test product (for example price 100$ tax 15%). - Created a price list with fixed price 15$ for all products - Pricelist configured as "Selectable" and set to "Show public price & discount to the customer". - on the product shop page, the price is 17.25$ instead of 115$ (which is the correct). - add product to cart and check the cart price, it's 17.25$ instead of 100$. Problem: ======== on the shop page the prices is calculated through combination. But in the cart, it's retrived directly from `sale.order.line`. Solution: ========= do same calculation in the cart as in the shop page through combination. opw-3771242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157357
This update fixes an issue where the 'Put in Pack' feature within batch picking was incorrectly handling multiple pickings, leading to inaccurate package assignments. The change ensures that only the intended move is placed in a package, resolving a potential for incorrect inventory tracking and shipping charges. This improves the reliability of the delivery process.
Original PR description
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking…
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened). Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product] Flow 1: batch picking + put in pack for single picking - Create 2 pickings of any operation type - Create a new batch picking with these 2 pickings - Open 1 of those pickings directly (i.e. not in the batch) - Click on "Put in Pack" Expected result: Only the move from the open picking is put into a package Result before this commit: Both pickings have their moves put into the same package Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it === Flow 2: batch picking (or multi-record calling of `action_put_in_pack`) - Create 2 receipt pickings (or any picking where picking_type_id.show_reserved != False) - Create a new batch picking with these 2 pickings - Open batch picking + click "Put in Pack" Expected result: All moves in the batch are put into a package Result before this commit: Stack trace because self.immediate_transfer is a boolean and cannot be called for more than 2 records (i.e. breaks singleton check) Additional notes: In theory batch picking creation has checks to avoid batches where there are pickings with more than 1 picking type or have different `show_reserved` values, but because `_package_move_lines` is a method that can be called in different use cases (including multi-record pickings) via customizations/future code changes, we add in checks to prevent put in pack from finishing in those cases to avoid unexpected behavior/stack traces. I.e. remember to respect existing `self.ensure_one` checks since they're probably there for a reason. === Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1) - Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them) - Add both pickings to a batch - Click "Put in Pack" in the batch picking Expected result: None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings) Result before this commit: All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur Additional notes: This is the use case that was intended to be avoided when flow was originally decided to not be handled --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157224 Forward-Port-Of: odoo/odoo#156068
This update corrects a visual issue where text within the searchbar was invisible due to a color mismatch with the background. The fix ensures sufficient contrast for readability, particularly when using dark themes. This improves the user experience for all customers.
Original PR description
Steps to reproduce the bug: - Open the homepage and enter edit mode. - Click on the "Theme" tab. - Select the 4th color from the theme options and choose "black". - Drag and drop a "Search" snippet onto the page. - Save the page to exit edit mode. - Enter text in the searchbar input. - Bug: The text is not visible because its color is the same as the background color of the input. This bug appeared since this commit [1] where the "bg-light" class was added to the searchbar input. This caused the text color of the input, which by default is the same as the body color, to become invisible when the background color of the body is dark. To fix this, we now adjust the text color of the input based on the background color of the input. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3751401 Forward-Port-Of: odoo/odoo#156042
This update resolves an issue where margins were not correctly displayed on the form for fixed-price carriers after switching between fixed and variable pricing. The fix ensures that margins are accurately reflected in the system when using fixed-price carriers, improving the accuracy of shipping cost calculations. This change was made to address a reported bug and improve the user experience.
Original PR description
Steps to reproduce: - Create a shiping method based on rule - Set margins and then swith back to fixed price Bug: since this PR https://github.com/odoo/odoo/pull/108794 margins aren't displayed on the form anymore for fixed price but they are still set on the model if we edit the delivery type opw-3759128 Forward-Port-Of: odoo/odoo#155778
This update fixes a reporting issue where the revaluation of inventory wasn't accurately reflecting the updated value in the general ledger report. The fix ensures that the reported valuation correctly displays the total value (including the added value) after the revaluation process, resolving a discrepancy in the financial reporting.
Original PR description
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office…
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office Furniture** and: - Set the Inventory Valuation as **Automated** - Set the Costing Method as **First In First Out (FIFO)** - Go to **Inventory** > **Reporting** > **Inventory Valuation** - Open the toggle header then Click on the plus button at the header. - In the popup shown -Notice how the current value is 0-, set: - Added Value to **1000** - Counterpart Account to **600000 Expenses** - Click on **REVALUE**, a new report appears. - Open the newly created report > **Other Info**, open the **Journal Entry**. - In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`. ### Investigation: - the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34 - Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids` - When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field - That's why now `current_value_svl` is the _new_ value and not the _old_ one. opw-3715522 Forward-Port-Of: odoo/odoo#154239
This update removes a restriction that prevented users from setting payment terms to negative days. Previously, negative payment terms were blocked, but they functioned correctly. This change allows for flexibility in payment term definitions, particularly for payments due before the end of the month.
Original PR description
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before. There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days. To fix, we remove the constraint _check_positive. To reproduce the issue: - Go to Accounting -> Configuration -> Payment Terms - Edit/Create a Payment Term with a negative value in the 'After' column - When saving, a Validation error appears task-3751491 Forward-Port-Of: odoo/odoo#154617
This update corrects a minor issue where clicking a tag in the website blog sidebar would trigger an unnecessary redirect. The fix ensures the system uses the tag name directly, eliminating the redundant URL and improving user experience. This change enhances the overall stability and performance of the blog section.
Original PR description
In all cases, we will fetch the record since we display the name, so it has no extra cost to slug the record instead of the id, and it will prevent an extra redirect from /tag/1 to /tag/name-1 on click. opw-3752989 Forward-Port-Of: odoo/odoo#157493 Forward-Port-Of: odoo/odoo#157473
This update enhances the data module installation process by displaying clear error messages and automatically rolling back any changes if an installation fails. This prevents incomplete installations and ensures data integrity, providing a more reliable experience.
Original PR description
Before this commit, when an error occurred during the installation of a data module, there was no displayed error nor a rollback to remove data already installed from the module. This commit makes sure that, if an error occurs, it is displayed through a UserError that will do a rollback to remove every record from the module. Task-3794899 Forward-Port-Of: odoo/odoo#148823
This update fixes a bug where the website event URL matching process failed when an event title was removed. Previously, the URL format relied on a hyphen, but removing the title resulted in a mismatch. The fix now correctly extracts the event ID regardless of the title's presence, ensuring consistent URL generation and functionality.
Original PR description
Issue: When editing with the editor an event and removing the title we get an issue since the url that we usually got is formatted like: '/event/title-3/register' where title is our event title and 3 the id, but when leaving the title blank the url will change to be like: '/event/3/register' in this case the match will no longer find anything since we no longer have a '-' on our url. Steps to reproduce: 1. Install website_event and go to the website view of any event. 2. Edit the event, and leave the title blank. 3. Save, and try to edit again the same title. Solution: We can directly get the id without the preciding '-', in this case we will get the id in both cases without having mismatch error. opw-3783998 Forward-Port-Of: odoo/odoo#157130
This update resolves an issue where a group chat test occasionally failed due to inconsistent member ordering. The change ensures the correct thread name is always displayed by explicitly defining the order of members within the chat, improving reliability and user experience.
Original PR description
The `unnamed group chat should display correct name` test checks that the name of a thread is updated after being invited. Sometimes, the test fails because the order of the members is different. We should maintain the desired order, not rely on what the server sends or how the data are handled internally by the javascript code. This PR adds the `sort` option to the `channelMember` field to ensure the order will always be the same. fixes runbot-58955
This update fixes an issue where the subcontracting Bill of Materials (BoM) overview sometimes displayed incorrect negative values. This change ensures that the overview accurately reflects component availability, leading to more reliable reporting and decision-making for subcontracting operations. The fix addresses a technical detail related to how subcontractor locations are handled.
Original PR description
Task: 3607854 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#144702
20 changes
New functionality added to Odoo
Adds Cyprus-specific Balance Sheet and Profit and Loss reports so businesses can prepare local financial statements more easily. This improves reporting coverage for companies operating in Cyprus and supports localized accounting needs.
Original PR description
This commit will add the Balance sheet and Profit and Loss reports for Cyprus. task: 3640438
The Maltese localization now includes standard Balance Sheet and Profit & Loss reports. This helps businesses in Malta prepare and review key financial statements directly in Odoo using localized reporting structures.
Original PR description
Add the Balance Sheet and Profit & Loss to the Maltese localization. Community PR: odoo/odoo#147902 Task link: https://www.odoo.com/web#id=3627705&model=project.task task-3627705
Enhancements to existing features
Material resources such as tools and machines will no longer automatically receive a standard working calendar when created in Planning. This better reflects that equipment does not usually follow employee working-hour restrictions and keeps list views focused by hiding irrelevant scheduling data.
Original PR description
Currently, a working calendar is set by default on material resources which doesn't make a lot of sense as tools and machines don't have the same capacity limitations and hours restrictions as human resources do. Remove the default value for the working time. It need to be done at 2 places for the folowing reasons: - `default_get`: When creating a shift on the planning, when we create a new resource, it need to be set without the default working time. - `_onchange_company_id`: When creating a resource from the planning material list view, the `_onchange_company_id` function from the resource module is called and don't take into account that the `default_get` already changed the value, so we need to override it to ensure it won't reset the `calendar_id`. task-3692156
This update corrects spelling mistakes in internal comments and documentation within the Knowledge app code. It does not change how users interact with Knowledge, but it helps developers maintain the feature more easily and avoid repeated misspellings in tools.
Original PR description
Currently, there are a lot of typos in the comments and docstrings of the Knowledge codebase. This commit aims to fix those typos. The auto-completion algorithms implemented on most code editors should then stop suggesting misspelled words. task-3725136
Users can now drag and reorder child items within expanded Knowledge favorites without accidentally moving the parent favorite. This makes organizing Knowledge content smoother and keeps the ordering in sync across the related section.
Original PR description
In the favorite section of knowledge, it was possible to unfold a favorite and see its children, but it was not possible to resequence them, and dragging them would start a `drag` operation on their ancestor (which is set as a favorite). Now it is possible to resequence them at the same level, and it will actually resequence them in their respective section synchronously. task-3555651
Checkout now retrieves UPS delivery options together with their prices, reducing the need for extra steps or delayed price updates. This should make shipping selection clearer for customers and help improve the checkout experience.
Original PR description
todo
Australian businesses registered for Deferred GST can now account for import GST in their Activity Statement instead of treating it as payable at the border. This helps keep tax reporting aligned with the Deferred GST scheme and prepares the workflow for amounts received through online services and SBR.
Original PR description
In Australia, when you import goods, you have to pay a tax for import as soon as it arrives at the border and as the tax is computed by the border security. However, if the business registered for Deferred GST, the computed tax has to paid at the next Activity Statement (their form of tax report) submission. The computed tax amount is then received through online services and SBR (implemented in another task). task-3681250
Resolved issues and error corrections
Fixed an issue where buttons in the Planning calendar could send users to a page not found error. The calendar now loads in a way that preserves the information needed for correct redirects, so users can navigate from the front-end planning view as expected.
Original PR description
Behaviour prior to fix: Whenever we used any of the buttons in the planning front-end we would get a page no found error when being redirected. Cause: The planning and employee tokens could not be fetched from the DOM as we did before because the calendar view was not properly rendered with the update to FC v6. This lead to the tokens being undefined when clicking the buttons and thus the redirect leading to the page-not- found errors. Fix: Changed the element that we mount to the FC to more specifically be the calendar widget. That way DOM of the calendar post render more closely resembles what it looked like before the update to v6 and thus the buttons work again. task-3791067
Code cleanup and technical improvements
This update cleans up how automated test tours interact with embedded page content, making those tests simpler and more consistent. It helps reduce maintenance work and improves confidence in test coverage without changing the user-facing product.
Original PR description
In this commit, we change rest of triggers in tours where an iframe is selected (suite of #156653). To do this, we use the :iframe HOOT pseudo-selector. With this changes, we can now remove the getNodesFromSelector function in odoo/addons/web_tour/static/src/tour_service/tour_utils.js Note that in this previous function, a ([is-ready]="true") check was made for iframe elements but was only necessary for few of them (7). So, a stepUtils.waitIframeIsReady() has been added to check this state. task~3600484 https://github.com/odoo/odoo/pull/157217
Miscellaneous changes
The test for `sw` fails every time because we don't have identifiers. We don't have any, so we just get rid of the test. Also added the message to the error, so we can know why it failed. (Other tests failed some time, but we can't reproduce and know why it failed). Linked to runbot error 25908 Forward-Port-Of: odoo/enterprise#58443
Original PR description
The test for `sw` fails every time because we don't have identifiers. We don't have any, so we just get rid of the test. Also added the message to the error, so we can know why it failed. (Other tests failed some time, but we can't reproduce and know why it failed). Linked to runbot error 25908 Forward-Port-Of: odoo/enterprise#58443
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 Forward-Port-Of: odoo/enterprise#58467 Forward-Port-Of: odoo/enterprise#56520
Original PR description
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 Forward-Port-Of: odoo/enterprise#58467 Forward-Port-Of: odoo/enterprise#56520
Before this commit: Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. After this commit: Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task-3624012 Forward-Port-Of: odoo/enterprise#58364 Forward-Port-Of: odoo/enterprise#58251
Original PR description
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
Forward-Port-Of: odoo/enterprise#58364
Forward-Port-Of: odoo/enterprise#58251when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True. but as this xmlids has been created from python file using load samples it's noupdate='f' . so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f' so during upgrade as there was no demo f
Original PR description
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually…
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True.
but as this xmlids has been created from python file using load samples it's noupdate='f' .
so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f'
so during upgrade as there was no demo file loaded, and this entry are with noupdate='f'
ORM try to remove those record quants record
in `_process_end` during upgrade from 17.0 to
saas-17.1, and which was create issues as
that quant contain some qty for storable product
so after upgrade as this qunts removed we have mismatched qty compare to before upgrade ( original database) so to fix that we need to pass noupdate='t'
and also need to fix in upgrade script with force_noupdate TRue.
```
Traceback (most recent call last):
File "/tmp/tmpf_o_71pk/migrations/testing.py", line 207, in test_check
self.check(value)
File "/tmp/tmpf_o_71pk/migrations/stock/tests/test_on_hand_quantity.py", line 58, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[3, '1'], [4, '4'], [6, '2'], [7, '5'], [8[541 chars]36']] != [[6, '2'], [7, '5'], [8, '2'], [9, '1'], [1[521 chars]36']]
First differing element 0:
[3, '1']
[6, '2']
```
Forward-Port-Of: odoo/enterprise#58007-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Soluti
Original PR description
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Solution: - Changing the Xpath(Field as an Xpath) as SLA DeadLine allows the Properties filter to be added and SLA Deadline to be under Create Date Filter task-3707563 Forward-Port-Of: odoo/enterprise#55595
It makes it very difficult to translate Forward-Port-Of: odoo/enterprise#58254 Forward-Port-Of: odoo/enterprise#53297
Original PR description
It makes it very difficult to translate Forward-Port-Of: odoo/enterprise#58254 Forward-Port-Of: odoo/enterprise#53297
Current behavior: When trying to refund a pos order you had an error saying you can't refund the order. Steps to reproduce: - Create a pos order - Validate the order - Go in the backend without closing the session - Try to refund the order This was happening because here (https://github.com/odoo/odoo/blob/c1b86a946d74ea6fbd1d1932da5221ec770ed3a8/addons/point_of_sale/models/pos_order.py#L1050) we trigger this constrains (https://github.com/odoo/enterprise/blob/cc86cdefb375c60b0d1f26e74
Original PR description
Current behavior: When trying to refund a pos order you had an error saying you can't refund the order. Steps to reproduce: - Create a pos order - Validate the order - Go in the backend without closing the session - Try to refund the order This was happening because here (https://github.com/odoo/odoo/blob/c1b86a946d74ea6fbd1d1932da5221ec770ed3a8/addons/point_of_sale/models/pos_order.py#L1050) we trigger this constrains (https://github.com/odoo/enterprise/blob/cc86cdefb375c60b0d1f26e747bb5c2bc3b7f9e3/l10n_mx_edi_pos/models/pos_order.py#L269) but at this point in the code the lines aren't copied in the refund order and so it is triggering the error. To fix it we make sure to check that the order contains atleast one order line. opw-3750165 Forward-Port-Of: odoo/enterprise#58419 Forward-Port-Of: odoo/enterprise#58291
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
Original PR description
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
* Account 2104 'Prelevamenti extra gestione' was not referenced in the Balance Sheet. This account tracks withdrawals made by an individual entrepreneur during the fiscal year, before determination of profits, and therefore decreases capital. ([source1](https://www.wincoge2.it/Manuale%20Con%20Esempi/Manuale_Contabilita8.html#:~:text=I%20%E2%80%9CPrelevamenti%20extra%20gestione%E2%80%9D%20sono,nell'arco%20dell'anno.&text=Al%2031%2F12%20la%20voce,la%20destinazione%20dell'utile%20stesso.)) ([source
Original PR description
* Account 2104 'Prelevamenti extra gestione' was not referenced in the Balance Sheet. This account tracks withdrawals made by an individual entrepreneur during the fiscal year, before determination of profits, and therefore decreases capital. ([source1](https://www.wincoge2.it/Manuale%20Con%20Esempi/Manuale_Contabilita8.html#:~:text=I%20%E2%80%9CPrelevamenti%20extra%20gestione%E2%80%9D%20sono,nell'arco%20dell'anno.&text=Al%2031%2F12%20la%20voce,la%20destinazione%20dell'utile%20stesso.)) ([source2](https://www.economiaziendale.net/scritture/spese_extragestione.htm)) * The Current Year Earnings line was not showing just the result from the Profit and Loss for the current fiscal year. This has been fixed. Any non-closed results from previous fiscal years now automatically appear under the Previous Years' Earnings line. taskid: 3060790 Forward-Port-Of: odoo/enterprise#58393 Forward-Port-Of: odoo/enterprise#57219
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
Original PR description
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
Before this commit: Portal users could access template buttons even though they did not possess any templates, leading to undesired visibility. After this commit: Following this commit, template buttons will no longer be visible to portal users, ensuring appropriate access restrictions. Task-3758669 Forward-Port-Of: odoo/enterprise#58140 Forward-Port-Of: odoo/enterprise#57772
Original PR description
Before this commit: Portal users could access template buttons even though they did not possess any templates, leading to undesired visibility. After this commit: Following this commit, template buttons will no longer be visible to portal users, ensuring appropriate access restrictions. Task-3758669 Forward-Port-Of: odoo/enterprise#58140 Forward-Port-Of: odoo/enterprise#57772
27 changes
Enhancements to existing features
When users try to restore a knowledge article item whose parent article is in the trash, they now receive a clear, helpful error message explaining that the parent article must be restored first. Previously, users saw a confusing technical validation error that didn't explain the actual problem or how to fix it.
Original PR description
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that…
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view of article items with /kanban or /list 4. Create an article item (-> The "New" button from the embedded view) 5. Delete the parent article using the "more options" panel 6. Click on the "Open the Trash" button 7. From the list view, click on the article item you created at step 4 8. Click on the "Restore" button from the banner => The user receives a validation error indicating that the article item should have a parent. This error occurs because the parent article is in the trash, and the article item cannot be detached from its parent. TO BE: The user should receive an error message indicating that the article item cannot be restored and that the user needs to restore the parent article first in order to restore the article item.
The barcode scanning application now responds much faster when handling large orders with many line items, especially on mobile devices. This update optimizes how the system checks which line is selected, reducing processing time from 7.5 seconds to 600 milliseconds when working with 2,000 lines, making the app more responsive and user-friendly for warehouse staff.
Original PR description
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selected or not. This reduces the complexity from O(n^2) to O(n). Benchmark: On a laptop and with 2000 lines, selecting the last line took 7.5s before, and 600ms with this commit. opw-3754849 Forward-Port-Of: odoo/enterprise#58182
This update improves Kenya's tax accounting setup by renaming and organizing VAT accounts. The changes establish dedicated KRA (Kenya Revenue Authority) accounts for tracking VAT that the company owes (payable) and VAT that customers owe the company (receivable). These accounts are now properly linked to all tax groups, ensuring accurate tax reporting and compliance with Kenyan tax requirements.
Original PR description
In this pr I renamed account 220100 to KRA - VAT payable and created the new KRA - VAT receivable accounts. These accounts are now used as the Tax Payable and Tax Receivable accounts on all the tax groups task: 3725559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The payment term preview interface has been enhanced with better visual design using colors and field borders. This makes it clearer to users which fields they can edit to customize the preview results, improving the overall user experience when setting up payment terms.
Original PR description
Emphasize the preview with colors and field borders to: - visually outline the preview result - clarify to the user that there are editable fields which customize the preview task: 3751514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed an issue where invoices created from Field Service tasks were incorrectly including line items with zero unit prices. Now, when a product added to a Field Service task has a zero price, it will not appear on the generated invoice, aligning with the intended Field Service billing behavior.
Original PR description
Steps to reproduce: - - Go to Field Service app and create a new task. - Use the smart button to access the catalog and add a product. - Go back to the task and use the smart button to access the SO.…
Steps to reproduce: - - Go to Field Service app and create a new task. - Use the smart button to access the catalog and add a product. - Go back to the task and use the smart button to access the SO. - Set the unit price of the added product to zero. - Create the associated invoice. **You are allowed to create the invoice and aline will be displayed for the SOL corresponding to the products with a unit price of zero.** Notes: This is the expected behavior for invoices generated from regular SO. However, AJU the PO of the Field Service application decided to change this behavior for invoices generated from SO coming from field services see task 3266856 and commit 849241e (the SOL invoice status should be 'no'). Cause of the Issue: - When you create an invoice from a sale order, the `invoiceable_lines` are computed at this point: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1251-L1258 by the `_get_invoiceable_lines` method. As one can see in this method: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1220 if the `qty_to_invoice` of SOL is positive, the SOL will therefore appear in the `invoiceable_lines` and the associated invoice line will be created a few lines below to appear on the invoice: https://github.com/odoo/odoo/blob/96a06df867fcef1fd24a1798bd5d6decc423933b/addons/sale/models/sale_order.py#L1276-L1279 Fix: - In order for the SOL to not generate an`invoiceable_line` we set the `qty_to_invoice` to zero when the SOL comes from a field service task and display a product with a unit price of zero. Notes: To keep the flow coherent between the `qty_to_invoice` and the `invoice_status` of SOL for field services SO and since `price_unit` is a float that should not be compared using an `==` we also changed the float comparaison of the `_compute_invoice_status` method introduced in the commit 849241e. opw-3776475 ---
The Reconciliation page was crashing when users removed the grouping filter and saved it as a default filter. This fix prevents the crash by properly handling cases where no grouping is applied, allowing users to customize their reconciliation view without encountering errors.
Original PR description
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244
This fix resolves an issue where signer email addresses would disappear when toggling the Signing Order option in document templates with multiple signers. Now when you enable signing order, the email addresses remain visible alongside signer names, ensuring all contact information is preserved during template configuration.
Original PR description
Before this commit, when toggling the Signing Order option in a template with more than one sign role, the signer emails would disappear (only their names would be kept). After this commit, by adding the context variable show_email as true in the Send action, the signers emails no longer disappear. This will make the emails labels persist after performing onchange calls in the user interface. task-3659895
This fix enables cash basis financial reports to be grouped and analyzed by analytic accounts, providing better visibility into cash-based accounting by analytic dimension. The system now correctly proportions cash basis amounts across analytic lines, allowing users to see their financial data organized by cost centers or business units.
Original PR description
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58335 Forward-Port-Of: odoo/enterprise#33384
A recent change caused important context information to be lost when updating existing subscriptions. This fix ensures that new context values are added to the existing context rather than replacing it entirely, preserving all necessary information during subscription updates.
Original PR description
Since fixed introduced in https://github.com/odoo/enterprise/pull/57590, the context is lost when we call 'update_existing_subscriptions'. As we put a dictionnary returned by '_upsell_context' in the 'with_context' to call write on the subscription, it replace the current context by the new one. As we just want to add values to the context and not replace it, we get the key/values as named arguments to update the current context and not replace it Forward-Port-Of: odoo/enterprise#58530
The UPS REST shipping module has been updated to replace real shipping credentials with dummy values in test environments. This prevents accidental creation of actual shipping labels during development and testing, ensuring that only production environments can generate real shipments.
Original PR description
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
This fix resolves an error that occurred when creating new work locations in the Swiss Payroll module. The required BUR-REE-Number field was missing from the form, preventing users from saving new work addresses. The field has now been added to the form so users can complete the process without errors.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244
This fix corrects how work entry hours are calculated when employees have custom work schedules and time off requests. Previously, the system was incorrectly calculating total hours for work periods, especially when employees worked non-standard schedules (like 56 hours per week). The fix ensures the correct employee schedule is used when recalculating work entries after time off is approved.
Original PR description
## Steps to reproduce - Install **Payroll**, **Planning** and **Time Off** apps - Create a new working time of 56 hours per week: - Go to **Payroll** app - Go to **Configuration** > **Working Times**…
## Steps to reproduce - Install **Payroll**, **Planning** and **Time Off** apps - Create a new working time of 56 hours per week: - Go to **Payroll** app - Go to **Configuration** > **Working Times** - Create a **NEW** working time -named 56 hours/week- that has 7 days (Monday to Sunday), each from **8:00** to **16:00** - Set a time zone of your choice, in my case it Africa/Cairo - Go to **Employees** app and create a **NEW** Employee -named 56 hours/week employee- with the same time zone as the new working time - Create a new Contract for the newly created employee: - Click on the Contract smart button - Click on **CREATE** - Set the **Contact Start Date** -ex. 1 Feb 2024- - Set the **Working Schedule** to the newly created working time (56 hours/week) - Set the **Work Entry Source** as **Planning** - Set the state of the contract to be **RUNNING** - Create a 10 day planning: - Go to the newly created 56 hours/week employee - Click on the Planning smart button - Click on **NEW** to add a new Shift (example values): - from 20 Feb 2024 - to 29 Feb 2024 - from 8:00 to 16:00 - Click on **PUBLISH** - Go to the newly created 56 hours/week employee. Click on the Work Entries smart button. Set the view as _list_. We now have a planning of 10 days totaling 80 hours. - Create a time off: - Go to the newly created 56 hours/week employee - Click on the Time Off smart button - Click on a day to request a time off -for our example set as 23 Feb 2024- - Go to the **Time Off** app > **Approvals** > **Time Off** - Remove **My Team** filter - Approve the newly created time off - Go back to the Work Entries of our employee - Click on **REGENERATE WORK ENTRIES** - Set the Work Entries in _list_ view - Notice how the duration of the last work entry is **_incorrectly_** calculated: - The 1st entry has 24 hours for 3 days of work (20 Feb, 21 Feb, 22 Feb) which is CORRECT - The 2nd entry is for the time off having 8 hours for 1 day (23 Feb) which is CORRECT - The 3rd entry has **24** hours! although it's for 8 days (24, 25, 26, 27, 28, 29 Feb) totaling **48** hours. There are **24** hours difference (3 days), which actually (3 holidays in my case) ## Investigation #### First, let's see how we reach to recalculating the duration (allocated hours) of the planning slots: - When the work entries are regenerated, the slots durations are recalculated via `_get_duration_batch()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L43 more precisely `_get_planning_duration` which recompute the durations by creating new temporary planning slots -notice how we didn't pass the `resource_id` of the slot-https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/hr_work_entry_contract_planning/models/hr_work_entry.py#L29-L36 passing the values from the original slot but the new start and end date. - That triggers `_compute_allocated_hours()` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L239 #### Second we'll examine three cases: 1. What if the slot has no resource_id ? (This is actually the issue specific to the ticket, the `resource_id` is not passed) - the `planning_slots` will be empty, while the `slots_with_calendar` will have our respective slot which triggers the `if slots_with_calendar:` block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248 - As we have no resource, we fall back to the `company_id.resource_calendar_id` which is the standard 40 hours/week https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L269-L271 - We then go into `_get_working_hours_over_period()` which will use the `company_id.resource_calendar_id` as it has no `resource_id` https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1677-L1679 2. What if the slot has a resource with `flexible_hours = False`? Same as 1 3. What if the slot has a resource with `flexible_hours = True`? - the `planning_slots` will will have our respective slot https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L242-L248 - which will trigger this block https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L249-L252 - going into the `_calculate_slot_duration()` function that has a drawback: - The period is a timedelta object https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1106 that has days (`period.days`) which is the number of full days in that period and seconds (`period.seconds`) - if the `period.seconds` is not ZERO that means we have a non-full day. - when `max_duration` is calculated we always round up the days by adding 1 https://github.com/odoo/enterprise/blob/2afcea7c129148e9be158adb7728888525547cd4/planning/models/planning.py#L1108 even though `period.seconds` can be 0. in that case we should only take `period.days` into consideration ## The Fix: - By passing the `resource_id` when creating the new temporary slots, we make sure we are dealing with the correct `resource_calendar_id` - The `_calculate_slot_duration()` modification addresses the issue when `resource_id` has `flexible_hours = True` basically if the employee work with flexible hours opw-3662389 Forward-Port-Of: odoo/enterprise#58409 Forward-Port-Of: odoo/enterprise#57205
Fixed an issue where the "More" dropdown button was incorrectly displayed when there was only one button in the button box. The fix also ensures that toggling the "Show Invisible" option now properly refreshes the form editor view, which wasn't working before due to a reactivity issue.
Original PR description
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382
This fix improves the module installation process by ensuring that when an error occurs during data module installation, users are notified with a clear error message and any partially installed data is automatically removed. Previously, errors would occur silently without cleanup, potentially leaving the system in an inconsistent state.
Original PR description
Before this commit, when an error occurred during the installation of a data module, there was no displayed error nor a rollback to remove data already installed from the module. This commit makes sure that, if an error occurs, it is displayed through a UserError that will do a rollback to remove every record from the module. Task-3794899
This update corrects how cost of sales accounts are classified in the UK accounting module, ensuring the Gross Profit calculation on the Profit and Loss report displays accurate figures. The fix adjusts the account type configuration to properly categorize direct costs, which is essential for accurate financial reporting.
Original PR description
The cost of sales accounts need to have the type expense_direct_cost for the Gross Profit calculation in the Profit and Loss report to be correct task: 3764767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a display issue in the web interface where a "More" dropdown menu would appear even when it only contained a single button. Now, when there's just one button, it displays directly instead of hiding behind a dropdown, providing a cleaner and more intuitive user experience.
Original PR description
Before this commit, it could happen that the More dropdown was displayed, but it only contained a single stat button. This isn't what we want, as that single button could simply be displayed instead of the More dropdown toggler. Task 3778382 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
Fixed an issue where approved time off request details were hidden when viewing attached documents. Employees and managers can now see the complete time off information even when an attachment preview is displayed, improving visibility and reducing confusion when reviewing time off requests with supporting documents.
Original PR description
Steps ----- 1. Create a time off request, approve it and add a document. Issue ----- The details of the time off request are not visible when the attachment preview is displayed. **opw-3792894**
This fix corrects the email sent count in event communications to include emails sent to unconfirmed attendees. Previously, the system was sending emails to unconfirmed attendees but not counting them in the total sent count displayed in the event's Communication tab, creating a discrepancy between actual emails sent and the reported count.
Original PR description
### [FIX] event: Include unregistered attendee emails in total sent count Before this commit the Email Sent Count (located in the Communication tab of the event view) wasn't including emails sent to…
### [FIX] event: Include unregistered attendee emails in total sent count
Before this commit the Email Sent Count (located in the Communication
tab of the event view) wasn't including emails sent to the attendees who
weren't confirmed.
### [This commit changes]
Event mail scheduler will include seats_uncofirmed into calculation of
the mail_count_done which is the count of emails sent. This is
reflecting the actual number of emails sent.
### [Reproduce]
- Create event E starting in time T (Events/Events)
- Add an "Unconfirmed" attendee
- Add an E-Mail in the Communication tab of the event E
- Set Interval time > T,
- Template: "Email Reminder"
- Trigger "Before the event"
- Run scheduled Action sending email (Scheduled Actions / Event: Mail Scheduler)
- BUG: email sent, but not included in the sent count in the communication tab of the event E
opw-3693626
# Merge plan
in 16.3 We are adding whatsapp to fix bundle. Since whatsapp is present in the enterprise repo, fix was put in there. Unfortunetally since `event_test_full` is not depending on the `whatsapp_event` I need to create additional test just for the
whatsapp module. Enterprise PR: https://github.com/odoo/enterprise/pull/58428
Forward-Port-Of: odoo/odoo#156907
Forward-Port-Of: odoo/odoo#153795This update removes an outdated field from the accrual plan list view that was previously removed from the form view. During a redesign of the accrual plan feature, the ability to set a time off type directly on the accrual plan was removed, but the field remained visible in the list view, causing confusion. This fix ensures the user interface is consistent and clean.
Original PR description
In rework of accruals plan, we removed the possibility to set a time off type on the accrual plan directly. The field has been removed from the form view, but not from the list 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
This update corrects the German translation of "Sales Order" in the German localization module to use the proper term "Auftragsbestätigung" instead of "Verkaufsauftrag". The correct translation was accidentally overwritten during a recent system update and has now been restored to ensure compliance with German localization standards.
Original PR description
In the German localization, "Sales Order" MUST be translated as "Auftragsbestätigung". In all other cases it can remain as "Verkaufsauftrag". Term was previously corrected but then overwritten by accident during fw-port that used old translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157424
This fix corrects how the system identifies which inventory movements should trigger automatic reorder point creation. Previously, movements from warehouse sublocations (like shelf areas) were incorrectly ignored. Now the system properly recognizes these movements and creates reorder points as intended, ensuring products are automatically replenished when stock is moved from storage areas.
Original PR description
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of…
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of the main warehouse location should be considered as a out move. The inverse condition doesn't make much sense. Current behavior before PR: Let's use a simple example: - create a new product. - create an outgoing movement from shelf 1. - click on "Replenisment" menu. No orderpoint for the new product.  Desired behavior after PR is merged: A new orderpoint should have been created at WH/Stock for that product. See below with the fix:  @ForgeFlow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157287 Forward-Port-Of: odoo/odoo#156903
This fix corrects an issue where inventory revaluation reports were displaying incorrect "before" values in the general ledger. When revaluing inventory, the system was showing the new value instead of the original value in the journal entry description. This update ensures accurate financial reporting by capturing the correct starting inventory value before any revaluation adjustments are applied.
Original PR description
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office…
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office Furniture** and: - Set the Inventory Valuation as **Automated** - Set the Costing Method as **First In First Out (FIFO)** - Go to **Inventory** > **Reporting** > **Inventory Valuation** - Open the toggle header then Click on the plus button at the header. - In the popup shown -Notice how the current value is 0-, set: - Added Value to **1000** - Counterpart Account to **600000 Expenses** - Click on **REVALUE**, a new report appears. - Open the newly created report > **Other Info**, open the **Journal Entry**. - In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`. ### Investigation: - the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34 - Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids` - When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field - That's why now `current_value_svl` is the _new_ value and not the _old_ one. opw-3715522 Forward-Port-Of: odoo/odoo#154239
This fix addresses a bug where margin settings were incorrectly persisted on shipping methods even after switching from rule-based pricing to fixed price. Previously, margins would be hidden from the form but still stored in the system, causing unexpected behavior. The fix ensures margins are properly ignored and cleared when using fixed price carriers.
Original PR description
Steps to reproduce: - Create a shiping method based on rule - Set margins and then swith back to fixed price Bug: since this PR https://github.com/odoo/odoo/pull/108794 margins aren't displayed on the form anymore for fixed price but they are still set on the model if we edit the delivery type opw-3759128 Forward-Port-Of: odoo/odoo#155778
This update restores the ability to use negative days in payment terms, which was unexpectedly blocked in a previous version. Negative days are useful for scenarios like setting payment terms relative to the end of the month. The fix removes an unnecessary validation restriction that was preventing users from entering negative values in the 'After' field when configuring payment terms.
Original PR description
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before. There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days. To fix, we remove the constraint _check_positive. To reproduce the issue: - Go to Accounting -> Configuration -> Payment Terms - Edit/Create a Payment Term with a negative value in the 'After' column - When saving, a Validation error appears task-3751491 Forward-Port-Of: odoo/odoo#154617
This update improves the blog tag sidebar experience by removing an unnecessary redirect that occurred when users clicked on tags. Previously, clicking a tag would redirect from the tag ID to the tag name, creating an extra step. Now the system uses the tag name directly, making the experience faster and smoother for readers.
Original PR description
In all cases, we will fetch the record since we display the name, so it has no extra cost to slug the record instead of the id, and it will prevent an extra redirect from /tag/1 to /tag/name-1 on click. opw-3752989 Forward-Port-Of: odoo/odoo#157493 Forward-Port-Of: odoo/odoo#157473
This update corrects how the POS online payment system identifies the customer for a transaction. Previously, it would always use the logged-in user, but now it properly checks if the POS order has an associated customer first before falling back to the logged-in user. This ensures payments are correctly attributed to the right customer.
Original PR description
Before this commit: POS online payment used logged in user when there is a chance that POS order also might have POS order partner After this commit: We ensure that the partner is either from POS order_id or the user logged in task-3786679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the website event editor where removing an event's title caused the system to fail when trying to edit the event again. The issue occurred because the event URL format changed from '/event/title-id/register' to '/event/id/register' when the title was blank, breaking the URL pattern matching. The fix now correctly extracts the event ID regardless of whether a title is present.
Original PR description
Issue: When editing with the editor an event and removing the title we get an issue since the url that we usually got is formatted like: '/event/title-3/register' where title is our event title and 3 the id, but when leaving the title blank the url will change to be like: '/event/3/register' in this case the match will no longer find anything since we no longer have a '-' on our url. Steps to reproduce: 1. Install website_event and go to the website view of any event. 2. Edit the event, and leave the title blank. 3. Save, and try to edit again the same title. Solution: We can directly get the id without the preciding '-', in this case we will get the id in both cases without having mismatch error. opw-3783998 Forward-Port-Of: odoo/odoo#157130