Daily updates from Odoo
Wednesday, March 13, 2024
43 changes
19 changes
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
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
23 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
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