Thursday, February 20, 2025
21 changes · 17.0
Enhancements to existing features
Jordanian e-invoicing now labels partner identifiers based on where the partner is located. Partners in Jordan use the tax number label, while partners outside Jordan use the passport/personal number label, helping ensure compliant electronic documents.
Original PR description
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting reports menu now shows the Deferred Revenue report before the Deferred Expense report. This matches the existing customer-before-vendor navigation order, making the menu feel more consistent and easier to follow.
Original PR description
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none
Resolved issues and error corrections
Confirmed manufacturing orders now show component availability with the correct color instead of incorrectly warning about overconsumption. This helps manufacturing users quickly see whether required materials are properly reserved before production starts.
Original PR description
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. Instead, while the MO isn't started yet, we can simply compare to the demand to see if there's enough reservation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross com
Original PR description
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross compare opw-4481596 Forward-Port-Of: odoo/odoo#198480
When creating a new project, Odoo now keeps the project stage chosen by the user instead of resetting it to the default stage. This prevents confusion and ensures new projects start in the intended workflow position.
Original PR description
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Project Stage feature 4. Go to Project > Configuration > Projects 5. Click on new button to create a new project 6. Set the project name and click on the second project stage Current Behavior: ---------------- The project goes back to the default stage instead of staying in the stage selected by the user. Expected Behavior: ----------------- The project should be in the stage selected.
The package transfer screen now hides a confusing Done checkbox when product-level validation is not shown. This makes internal transfer workflows more consistent and reduces uncertainty for warehouse users handling entire packages.
Original PR description
## Versions: 17.0+ ## Steps to reproduce: *In `Settings` app, check packages* *In `Operation Types`, in `Internal Transfers`, check the `Move Entire Packages` box* Create an internal transfer with 2 units of `Product A`: - Click `Mark as Todo`; - Click `Put in Pack`; - Validate; Create an new internal transfer with 1 unit of `Product B`; - Add the newly created package; - Click `Mark as Todo`. ## Issue: It is currently unclear for the customer why there is a checkbox to validate packages picking as the box for product picking is hidden. Both should either be displayed or hidden ## Fix: *Discussed with CRL and LASE* Hide the packages' `Done` checkbox as it is the most confusing flow. opw-4380897
This fixes an issue where popover dialog windows could be positioned partly off-screen on very small viewports. Users should now be able to see and interact with these windows reliably, such as when using reception report details from a sales order line.
Original PR description
Depending of viewport size and popover content, the dialog window may get cut off. For example, an extremely small viewport size clicking on the reception report icon while adding a product to a sale order line. Having 0 as the minimum for position values prevents the cutoff. opw-4018341
This change restores the ability to manually edit duration days on working schedule attendance lines. It reverses a prior change that unintentionally blocked edits because of an internal dependency cycle, helping administrators keep schedules accurate.
Original PR description
Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable.
Payroll managers and billing users can now see and use the option to refund an expense directly through a payslip. This removes an access mismatch and helps authorized staff complete payroll-related expense refunds without workarounds.
Original PR description
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an e
Original PR description
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196106
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This com
Original PR description
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the…
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This commit adds a condition to determine to know if a timesheet is not billed. The timesheet should now be: - not linked to an invoice - or the invoice linked should be cancelled and payment status should not be "Invoicing App Legacy". Steps to reproduce the issue: ---------------------------- 1. install Accounting, Sales and Timesheets app 2. Create a SO with a service product and confirm the SO 3. Create a timesheet for the SOL contained the service product 4. Create a invoice to partially invoice the service made for the SO. 5. Go to "Accounting app > Settings" 6. Enable the "Invoicing Switch Threshold" feature and make sure the date set on that feature is most recent than the one set on the invoice created in step 4. By doing that, the invoice created in step 4 should now be cancelled but with payment status set to "Invoicing App Legacy". 7. Create another timesheet for the same SOL 8. Go back to the SO created in step 2 and create another invoice to invoice the another timesheet. Current behavior: ---------------- The timesheet linked to the first invoice is now linked to the second one with the other timesheet. Expected behavior: ------------------ Since the first invoice is not really cancelled, the timesheet should still be linked to the invoice and so that timesheet should be considered as billed. opw-4556956 Forward-Port-Of: odoo/odoo#198277
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it
Original PR description
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking. OPW-3919976 Forward-Port-Of: odoo/odoo#196161
It is possible to have a lead linked to registration from different events by using the merge method on the leads. Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event. We just default to the first event for the name. Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes. task-4531433 Forward-Port-Of: odoo/odoo#196848
Original PR description
It is possible to have a lead linked to registration from different events by using the merge method on the leads. Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event. We just default to the first event for the name. Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes. task-4531433 Forward-Port-Of: odoo/odoo#196848
**Problem**: When focusing on an empty button (`<a>` tag with `btn` class) and pressing backspace, any visible content before it gets deleted. This happens because buttons are not considered as visible content when handling deletions. **Solution**: Modify `oDeleteBackward` to detect elements with the `btn` class. When deleting such an element, update the selection to avoid deleting preceding content. **Steps to Reproduce**: 1. Open the website builder. 2. Add some content with a button
Original PR description
**Problem**: When focusing on an empty button (`<a>` tag with `btn` class) and pressing backspace, any visible content before it gets deleted. This happens because buttons are not considered as visible content when handling deletions. **Solution**: Modify `oDeleteBackward` to detect elements with the `btn` class. When deleting such an element, update the selection to avoid deleting preceding content. **Steps to Reproduce**: 1. Open the website builder. 2. Add some content with a button. 3. Insert a form just before the button. 4. Press backspace while focusing on the button. 5. The form gets deleted along with the button. opw-4280705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196781
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date. ### Current behavior before PR: 1. Make e-commerce sales after 9 PM local time AR in
Original PR description
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next…
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date. ### Current behavior before PR: 1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal) 2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it. 3. We will receive ARCA (ex-AFIP) error telling us that we can not generate the invoice with today's date, we can only validate invoices with a date equal to or greater than tomorrow. ### Desired behavior after PR is merged: 1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal) 2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it. 3. Manual invoice will be generated and validated in AFIP with today's date as the invoice date. NOTE: We took the same approach that was used in the [POS module](https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/models/pos_order.py#L615-L631) to set the date, in this case, always forcing the Argentina timezone --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192808
Following this commit [1] introduced in Chrome 133.0.6836.0, this QUnit test for ImageField was failing as it reused twice the same DataTransfer instance. The Chrome's fix now properly updates the reference to its `files` property which results into an "empty" DataTransfer object once it has been consumed. This commit ensures a new DataTransfer instance created for each transfer (as "in real life") instead of reusing it. [1]: https://chromium.googlesource.com/chromium/src/+/ed04b9d9336db2e
Original PR description
Following this commit [1] introduced in Chrome 133.0.6836.0, this QUnit test for ImageField was failing as it reused twice the same DataTransfer instance. The Chrome's fix now properly updates the reference to its `files` property which results into an "empty" DataTransfer object once it has been consumed. This commit ensures a new DataTransfer instance created for each transfer (as "in real life") instead of reusing it. [1]: https://chromium.googlesource.com/chromium/src/+/ed04b9d9336db2e4f667fe0cfcda8f2156553fd2 Forward-Port-Of: odoo/odoo#198269
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A
Original PR description
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the…
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1. 2. Create a Manufacturing Order (MO) from this BoM. 3. Confirm the MO and set it to In Progress. 4. In the MO interface: Change the by-product from Product A to Product B. 5. Complete the MO. https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d **Current Behavior** The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A. **Expected Behavior** The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components). It would be worth to add the same kind of readonly condition on the byproduct side as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194972
Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-32
Original PR description
Steps to reproduce: - Add an snippet. - Click the "show/hide on desktop" button of visibility option. - Click on the little eye on the "hidden elements" section to have it displayed again. - Go to mobile preview mode. - Come back to desktop view by toggling off mobile preview button. - An empty overlay appears on the left of the screen. With dimensions similar to snippet in mobile view. After this commit: Empty overlays no longer appear when switching between preview modes. task-3270034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173328
Before this commit: The version set on an IoT box server side would never update as it was set only on creation. Also took the opportunity to refactor a bit this old part of the code to make it clearer and add some relevant logs to more easily investigate cases where it could be relevant After this commit: IoT version will now appear with the real value on the IoT app & beautiful relevant logs  *before this PR, the IoT would be stuck with the wrong version (here 18.0)*  *after this PR*  *logs example* opw-4502002 Forward-Port-Of: odoo/enterprise#79603
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#78013
Original PR description
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#78013
We use a couple manual SELECT queries in marketing_automation. However these do not flush before querying, meaning the result is potentially wrong if there was a change to the queried tables since the last flush. This is not too noticeable under regular use as only non-store computed fields hold statistics. However it does make the method innacurate in some cases. Notably tests need to flush manually. We now flush properly, as should have been done. As is done for the whatsapp ove
Original PR description
We use a couple manual SELECT queries in marketing_automation. However these do not flush before querying, meaning the result is potentially wrong if there was a change to the queried tables since the last flush. This is not too noticeable under regular use as only non-store computed fields hold statistics. However it does make the method innacurate in some cases. Notably tests need to flush manually. We now flush properly, as should have been done. As is done for the whatsapp override from 18.0 onwards. task-4589525 Forward-Port-Of: odoo/enterprise#79673