Daily updates from Odoo
Wednesday, March 13, 2024
26 changes
7 changes
Resolved issues and error corrections
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 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 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 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 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
1 change
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
18 changes
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
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
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 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 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