Daily updates from Odoo
Thursday, April 25, 2024
42 changes
1 change
Resolved issues and error corrections
The update prevents users from accidentally changing protected invoice or bill fields after another user has already posted the document. This helps keep posted accounting records consistent while still allowing approved technical processes to bypass the check when necessary.
Original PR description
When an invoice/bill is in a draft state and opened by 2 users, If one of them posted the invoice, the other user's form are not up-to-date, resulting in some whacky behavior like modifying fields that are supposed to be unmodifiable on a posted move. This commit adds a check on move write function to prevent this behavior, by raising error when modifying a readonly field if the field the user is going to write in a readonly mode depending on its state. If by any reason it is needed to modify the readonly field through the code, instead of resetting the move to draft, writing the change, and posting it back (which can be tedious and resource heavy), we'll allow it by adding the context `skip_readonly_check=True` to skip this check. task-id: 3536150 related Community PR: https://github.com/odoo/odoo/pull/160096
41 changes
Resolved issues and error corrections
The Belgian POS Blackbox module has been temporarily disabled and made uninstallable until certification requirements are completed. This is a temporary measure that will be reverted once the certification process is finished. Users will not be able to install this module until the certification is done.
Original PR description
We make this module uninstallable until the certification is done. This commit will be reverted later.
This fix resolves an issue where the edit history wasn't being properly cleared when users clicked the discard button on knowledge articles. Previously, users could undo (Ctrl+Z) after discarding changes and see the discarded content reappear in reverse order. The fix ensures history is only reset when discarding changes, not when simply navigating through the undo/redo history.
Original PR description
related community pr : https://github.com/odoo/odoo/pull/155511 Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a knowledge article - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 Solution: ========= We pass the information via the context of the record so we can set `shouldReset` as true when we click discard and as false when we just restore history. there is no easy way to pass the information directly using the props se we make use of the record which is common between `html_field` , `controller` and `topbar` task-3768456
Fixed a formatting issue in the customer statements report where text was not wrapping properly in the activity column, causing information to extend beyond the page boundaries. The fix removes unnecessary text-wrapping restrictions to ensure all content displays correctly when printing customer statements with multiple payments.
Original PR description
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before:  After: 
This fix resolves an issue where the Brazil Avatax services module was causing test failures when installed without the EDI (Electronic Data Interchange) module. The service tax calculation function now properly handles cases where EDI is not installed, preventing errors and allowing the module to work correctly in non-EDI environments. Users who need full service tax computation features will need to install the EDI module separately.
Original PR description
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no sale.order override various tests will fail with NotImplementedError() [1]. Ideally there should have been a l10n_br_avatax_sale_services module that contained just this one override. In absence of that, we make the function set False to stop breaking the tests. Users who just want tax computation on services will need to install the EDI part manually. [1] https://runbot.odoo.com/runbot/build/61615058
This update corrects the visibility logic for the Share and Link buttons in the Documents module. Previously, these buttons would appear or disappear incorrectly depending on which documents were selected. Now the buttons display properly: the Link button only shows when appropriate for the selected documents, and the Share button correctly appears when at least one non-archived document is selected.
Original PR description
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61400 Forward-Port-Of: odoo/enterprise#61118
Fixed a bug in the Planning module where night shift employees were not being automatically assigned to open shifts due to rounding errors in workload calculations. The system now correctly rounds allocated hours to ensure shifts are properly assigned when an employee's availability matches the shift requirements.
Original PR description
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 which creates rounding issues. Solution: ========= round the allocated rate opw-3874283
This fix corrects how fleet service costs are recorded when bills are created in a currency different from the company's default. Previously, the system would incorrectly store the bill amount in the company's currency, causing cost discrepancies. Now it properly uses the correct debit value to ensure accurate fleet service cost tracking.
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/enterprise#57639
This fix resolves an issue where the survey access rule was being overridden when both the HR Appraisal and HR Recruitment modules were installed together. Previously, only the rule from the last installed module would apply. Now the rules are properly combined so both modules work correctly together.
Original PR description
The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. task - 3597033 Forward-Port-Of: odoo/enterprise#60941
The Frontdesk module has been updated to properly declare its dependency on the SMS module. Previously, Frontdesk was using SMS features without explicitly stating this requirement, which could cause issues if someone tried to uninstall SMS. This fix ensures the system correctly recognizes that Frontdesk needs SMS to function properly.
Original PR description
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909
Fixed an issue where running timers were not being counted when creating invoices for timesheet-based service products. Previously, users had to discard running timers when invoicing. Now, the system automatically stops all running timers and includes their time in the invoice calculation, streamlining the invoicing workflow.
Original PR description
Steps to reproduce: - Make a service product, with invoicing policy based on timesheet and project & task set for create on order. - Make an SO for that product - The SO will create the task and the project - Register timesheet linked with the task with 15 min - Start a timer - Create the invoice Issues: The timer is still running, with the only choice possible being to discard it. Solution: The behaviour wanted by the po is to stop all the timer and count them in the invoice. opw-3715694
Product images in the Point of Sale were appearing zoomed in and cropped incorrectly, especially for images with unusual aspect ratios. This fix restores the previous behavior where images are resized to fit properly within their container without unwanted cropping, improving the visual presentation of products.
Original PR description
The cover scss rule first stretches the image to fill the container completely, then cropped at the size of the container. This results in some poor display result if the image has a weird aspect ratio. This is a behaviour change from saas-16.3 where the image wasn't cropped and simply resized to fit inside the container. opw-3826349 saas-16.3:  saas-16.4:  fixed locally (16.4):  Forward-Port-Of: odoo/odoo#161038
This update removes a problematic field from the gamification goals sorting logic that was causing system warnings. The fix ensures that goals can be properly searched and sorted by completion status and performance metrics without triggering errors, improving the reliability of the gamification feature.
Original PR description
We are removing the ``completeness`` field from the order because it's a non-storable field. When we attempt to access this field, it triggers a logger warning check at line [1]. This commit will help you to implement a ``goals`` search by domain and order by ``ID`` and sorting by ``completeness`` and ``current`` value, with condition-based sorting for 'higher' or 'lower' requirements check at line[2]. [1] : https://github.com/odoo/odoo/pull/127353/commits/12e9749bcc1dc4f7b1a129933ae16840195bcae8#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bL5317 [2] : https://github.com/odoo/odoo/blob/5c5b4d991423e0282d06a98e5677977d53dc0817/addons/gamification/models/gamification_challenge.py#L545-L548 sentry - 5162134321
This fix resolves an issue where Point of Sale orders would incorrectly revert to draft status when sync failures occurred, even after receipts were printed. Previously, validated orders that failed to sync with the server would lose their saved state and could not be recovered properly. Now, orders maintain their saved state during sync failures, ensuring that printed receipts are never lost or modified.
Original PR description
If an order was validated in PoS but encountered a sync error, the order would revert to a draft state and no receipt would be printed. However, if an order was validated in PoS without internet, the receipt could still be printed. When the internet connection was restored, the system would attempt to validate the unsynced order. If a server error occurred during this process, the system would try to revert the order to a draft state and fail. This behavior is not ideal as an order with a printed receipt should not be modified or changed. This commit ensures that in the event of a sync failure, the saved orders do not revert to a draft state. opw-3858994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug in manufacturing orders where unlocking and adjusting the quantity of an overproduced order resulted in removing twice the expected materials from inventory. For example, when a 2-unit order was produced as 3 units and then adjusted to 3 units, the system was removing 6 components instead of 3. The fix ensures material consumption is calculated correctly by processing quantity changes at the proper system level.
Original PR description
Usecase to reproduce: - Create a MO for 2 unit (1 component per finished product) - Produce 3 units - Mark as done - Unlock and change the quantity to 3 units Expected behavior: 3 components removed from stock Current behavior: 6 components removed from stock It happens because the set_quantity_done create a new stock.move.line with excessive quantity. Then the write of qty_producing in mrp.production will write this quantity on all the `stock.move.line`. It results by moving number of sml * the new quantity producing Solution do the write of new quantity done on the `stock.move` level and let him manage the `stock.move.line` 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#161650
Fixed an issue preventing portal users from creating new opportunities when they don't have any existing ones. This restores functionality that was previously available, allowing users to initiate new business opportunities directly from the portal interface.
Original PR description
Issue ----- Users cannot create a new opportunity on the portal if they don't have any. Fix ----- Apply the same change in 17.0 than 58356928dd9cf07158bca4e8c1ce0dcf5177d0b9 did in following versions. **opw-3809571**
Fixed a bug where the replenishment wizard was ignoring the vendor selected by the user and creating purchase orders from the default vendor instead. The system now correctly tracks and uses the vendor chosen in the replenishment dialog, ensuring purchase orders are created from the intended supplier.
Original PR description
Steps to reproduce:
- Create a product with 2 vendors
- Click replenish on the product page and select the second vendor
- The PO is created for the first vendor
Bug:
the replenishment will create a move which will create/edit a PO the selected supplier is discarded
Fix:
set the partner on the procurement group to keep track of it
note:
'supplierinfo_name' no longer used, will be removed in master related test ("test_procure_not_default_partner") is now irrelevant
opw-3776680This fix resolves an issue where users on mobile devices could not properly select analytic accounts when configuring analytic distributions. Previously, clicking on the selection modal would close the widget instead of registering the selection. Now users can successfully configure analytic distributions on mobile devices.
Original PR description
Steps to reproduce: - Activate "Analytic Accounting" in Accounting settings - Switch to a mobile view - Go to any view where there is the analytic distribution widget (e.g. expense form) - Try to configure the analytic distribution Issue: When an analytic account is selected, it is not taken into account. Cause: In mobile view, a modal is opened with a kanban view to select the analytic account. Any click on this modal is closing the analytic distribution widget. opw-3734050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Expenses were showing zero amounts on the accounting dashboard due to incorrect column references. This fix corrects the data retrieval logic and ensures that partially paid expenses are also displayed, giving users accurate visibility into amounts owed for employee expenses.
Original PR description
Steps to reproduce: - create-aprove-post an expense - Go to the accounting dashboard Issue: expenses' amount is 0 Cause: In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result: https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644 Solution: Get the right columns. We also change the domain to make sure that expenses partially paid are also displayed. Note: For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed. In master: Use the amount_residual (discussed with po Laura) opw-3849036
Fixed an issue where users would see a technical error message when trying to send an empty message in the portal's quotation chatter. The system now properly handles this scenario and displays a user-friendly error message instead of a traceback.
Original PR description
Steps to reproduce: - Install e-Commerce - Go to your portal into a quotation - Go to the chatter and send an empty message Issues: A traceback is shown Solution: Catch the error and discard it as the parent method is already displaying the error message to the user. opw-3877096
The customer portal was displaying a redundant "Addresses" box that provided the same functionality as the "Edit information" option. This update removes the unnecessary box to simplify the user interface. The multiple addresses feature will be added in a future release.
Original PR description
Steps to reproduce: - Install eCommerce - Go to My account Issues: There is a box "Addresses" which is useless for the moment as it's the same page that can be accessed by clicking on "Edit information". The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless. opw-3869920
This fix resolves a critical issue that occurred during database migrations when a company was archived. The system was unable to properly set up Point of Sale configurations for archived companies because it couldn't find the required warehouse information, causing the setup process to fail. The fix now allows the system to correctly handle archived warehouses when creating Point of Sale configurations.
Original PR description
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the…
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
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#151719This fix resolves a payment processing error that occurred when customers registered for paid events through the website checkout with an extra information step enabled. The issue prevented the order from being properly tracked in the session, causing payment validation to fail. This fix ensures the order is correctly recorded so customers can complete their event registration and payment without errors.
Original PR description
This commit fixes an issue where the `sale_last_order_id` was not being set in the session when the extra info step was added to the checkout process. This caused an error during the validation of event payment in `shop_payment_validate`. Steps to reproduce the issue: 1. Install `website_event_sale` and set up a payment provider. 2. Add the extra info step to the checkout in the website. 3. Register for a paid event from the website. 4. Proceed to pay the order, which would previously result in an error. opw-3864873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug in the invoice sending process where incorrect object references caused the system to crash when processing multiple invoices. The issue occurred because the code was referencing the wrong object in a loop, leading to a "too many values to unpack" error. This fix ensures invoices are sent successfully without errors.
Original PR description
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values.…
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values. This becomes problematic when the ``ensure_one`` method is called. Due to this below error is raised
Traceback :
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move.send(168, 167)
File "addons/payment/models/payment_transaction.py", line 985, in _cron_finalize_post_processing
tx._finalize_post_processing()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 144, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/account_payment/models/payment_transaction.py", line 217, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/payment/models/payment_transaction.py", line 1001, in _finalize_post_processing
self.filtered(lambda tx: tx.operation != 'validation')._reconcile_after_done()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 87, in _reconcile_after_done
self._post_subscription_action()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 166, in _post_subscription_action
orders._send_success_mail(tx.invoice_ids, tx)
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order.py", line 1866, in _send_success_mail
linked_invoices.with_context(email_context)._generate_pdf_and_send_invoice(template)
File "addons/account/models/account_move.py", line 4841, in _generate_pdf_and_send_invoice
return composer.action_send_and_print(force_synchronous=force_synchronous, allow_fallback_pdf=allow_fallback_pdf, bypass_download=bypass_download)
File "addons/account/wizard/account_move_send.py", line 738, in action_send_and_print
return self._process_send_and_print(
File "addons/account/wizard/account_move_send.py", line 663, in _process_send_and_print
moves_data = {
File "addons/account/wizard/account_move_send.py", line 666, in <dictcomp>
**self._get_mail_move_values(move, wizard),
File "addons/account/wizard/account_move_send.py", line 170, in _get_mail_move_values
'mail_attachments_widget': wizard and wizard.mail_attachments_widget or self._get_default_mail_attachments_widget(move, mail_template),
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4931, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 68, in _compute_mail_attachments_widget
super()._compute_mail_attachments_widget()
File "addons/account/wizard/account_move_send.py", line 311, in _compute_mail_attachments_widget
self._get_default_mail_attachments_widget(wizard.move_ids, wizard.mail_template_id)
File "addons/account/wizard/account_move_send.py", line 138, in _get_default_mail_attachments_widget
return self._get_placeholder_mail_attachments_data(move) \
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 112, in _get_placeholder_mail_attachments_data
if self.mode == 'invoice_single' and self._needs_ubl_cii_placeholder():
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
[1] : https://github.com/odoo/odoo/blob/167dedab5c7423097689c6a7d0d6ee6dd904a8bf/addons/account/wizard/account_move_send.py#L311-L312
sentry - 5234450902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an issue where customers submitting empty product reviews would see an unexpected error dialog popup. Now, users will only see a helpful message prompting them to add either text or an attachment, providing a better user experience when submitting reviews.
Original PR description
**Current behavior:** Attempting to leave a review with no body text or attachment shows an error dialog popup. **Expected behavior:** We should just see the prompt appear above the text input area informing the user to provide either text or an attachment. No dialog window should popup. **Steps to reproduce:** 1. Go to an item in the web store and in the editor enable customer ratings 2. As a portal user go to that item and attempt to submit a review with no text nor attachment **Cause of the issue:** In the input validation for this text area we reject the pending promise if there is no body text and attachment without catching the potentially undefined return. **Fix:** Add a catch block to the block where we may have an undefined return. opw-3876444
This fix resolves a conflict in how survey access permissions are managed when both the recruitment and appraisal modules are installed together. Previously, only the last installed module's permissions would apply. Now the permissions are properly combined, and they're also correctly removed when a module is uninstalled, ensuring consistent and reliable access control.
Original PR description
The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. On top of it, the domain is not corrected when the app is unistalled. This commit fixes that too task - 3597033 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#162238
This fix ensures that theme preview images are properly displayed in the theme selection page after upgrading a database to a new version. Previously, when databases were upgraded and new themes or theme screenshots were introduced, the images would not appear because the image update process wasn't being triggered during the upgrade. The fix now ensures this process runs automatically whenever the website module is updated.
Original PR description
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`.…
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`. This was also done in a `website` override of `ir.module.module.update_list()` which is called when updating a module interactively. Unfortunately, even though this override is defiend, at the time `update_list()` is called from `loading.py` when using `-u` on the command line, the modules are not loaded yet, and therefore the override is not applied. Because of this, when a database was upgraded between versions that introduce new themes or new screenshots for themes, `update_theme_images` was not called during the upgrade, and the new images were missing in the upgraded database. This commit solves this by calling `update_theme_images` from a `function` data record, so that it is run both on install and on update of `website`. Steps to reproduce: - Install website and a theme in 14.0. - Upgrade to 15.0. - Access the theme selection page. => Images were missing for some themes. task-2719425 Forward-Port-Of: odoo/odoo#162966 Forward-Port-Of: odoo/odoo#160452
Fixed a bug where Point of Sale sales reports were not including taxes in the total price when taxes were added separately to the product price. Now when you view order reports and pivot tables in Point of Sale, the totals will correctly reflect the full amount including all applicable taxes.
Original PR description
Current behavior: If you make a sale of a product that use a taxe not included in the price. Then go in order analysis in PoS, the total price of the product will not include the taxes. Steps to reproduce: - Create a tax of 15% that is not included in price - Create a product with 10$ price and add this tax to it. (Total price including tax should be 11.5$) - Sell it in the PoS and close the session - Go in PoS > Reporting > Order. Open the pivot view and check the total price for the product - The total is 10$ instad of 11.5$ opw-3817535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162984 Forward-Port-Of: odoo/odoo#162883
A test in the Manufacturing module was failing inconsistently depending on the database configuration. The fix adjusts how the test calculates work order duration to ensure it runs reliably regardless of working hours settings. This improves the stability of our automated testing process.
Original PR description
The `test_update_workcenter_adapt_finish_date` test was not consistent when the db was installed without demo data. The test was failing because the working hours were not the same and so the duration was different. To fix this we adjust the starting time of the work order so that it last exactly 30 minutes, and is not impacted by the working hours. runbot error : https://runbot.odoo.com/web#id=61595&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162074
This fix corrects how fleet service costs are recorded when bills are created in a currency different from the company's default currency. Previously, the system would incorrectly store the bill amount in the company's currency while using the original bill's currency value, causing cost discrepancies. Now the system properly converts and stores the correct cost value in the company's currency.
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/odoo#155632
When a database is duplicated, CDN (Content Delivery Network) settings are now automatically disabled to prevent broken website functionality. Previously, copied databases would retain CDN settings pointing to the original domain, causing images and assets to fail loading on the new domain. This fix ensures duplicated databases work properly without manual intervention.
Original PR description
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a…
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a CDN url is bound to a domain, when you copy the database (and most likely run it on its own different domain), it just won't properly work. Indeed, if you setup a CDN X for domain A and then copy a DB to domain B, this will happen: - You access website B - You try to load an img, which is using CDN X URL - CDN X URL is fetching the ressource on DB A instead of DB B, which might or might not exist (an image will likely share the same path so it might work, but for assets url it might not if the bundle url has changed) In the event of the assets having changed, they will never be loaded and the duplicated DB won't be loading properly. The only workaround in this case is to switch to debug mode to bypass the post processing and so the CDN url transform. Useful commits: - Introduction of neutralize https://github.com/odoo/odoo/pull/67825 - Conversion of neutralize from ORM calls to raw SQL https://github.com/odoo/odoo/commit/e5dbded9bb363351feff7ca8a56c7f8a6860f492 opw-3880102 Forward-Port-Of: odoo/odoo#163109
This fix resolves a critical error that occurs when upgrading accounting systems with duplicate journal codes. The system was attempting to process multiple journals simultaneously, causing the upgrade to fail. The fix ensures only the first matching journal is selected, allowing upgrades to complete successfully.
Original PR description
issue generated during upgrade. when it's try to find journal with journal_data['code'] and translated_code, wil get two journal, and that will raise exception as signtone error there are two journal…
issue generated during upgrade.
when it's try to find journal with journal_data['code'] and translated_code, wil get two journal,
and that will raise exception as signtone error
there are two journal with 1. INV code
2. FAC code as translated code so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
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#163022
Forward-Port-Of: odoo/odoo#162388This update adds helpful warnings when users have outdated configuration options in their settings files. Two configuration options that were renamed years ago (osv_memory_time_limit to transient_age_limit, and geoip_database to geoip_city_db) will now trigger alerts to guide users toward the correct settings, preventing silent failures.
Original PR description
Some options have been renammed a long time ago but there was no mechanism to warn the user should those option be still present in its configuration file. Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and `geoip_database` in their configuration, those two options have been renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and saas-16.1 c59750d82440 but no deprecation warning / automatic failover were provided. 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 fix ensures that when a new sales order line is created and saved, the quantity delivered field is properly initialized with a default value instead of remaining empty in the database. Previously, this field would be null, which could cause issues with order tracking and fulfillment processes.
Original PR description
Steps to reproduce: - - Create an SO with an SOL and save the record. **The `qty_delivered` of that SOL will be null in the DB.** Cause of the issue: - Since the `qty_delivered` field is computed, the default value is set in the DB comes from the `_compute_qty_delivered` method at record creation. However, no default value is set here when the `qty_delivered_method` is not `'analytic'`. ### Note: In 15.0, a default value was set because of these lines: https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353 These were removed by this commit de4911a. opw-3771589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156917
This update removes the display of subscriber numbers that were appearing next to mailing list names in website forms configured for newsletter signups. The subscriber count information was unnecessary and has been cleaned up to provide a cleaner user experience when visitors subscribe to newsletters through website forms.
Original PR description
*: website_mass_mailing Before this commit, when a "Form" snippet was added and the action was changed to "Subscribe to Newsletter", the mailing lists appeared as checkbox fields with the number of subscribers in parentheses. This commit removes the display of this unnecessary information. Steps to reproduce: - Install the "Email Marketing" module and Website. - Navigate to the Website in edit mode. - Drag & drop the "Form" block (dynamic content section). - Change the form action by setting the "Action" option to "Subscribe to Newsletter". Bug: The number of subscribers appears next to the mailing list names. task-3472820 Co-authored-by: Adrien Milis <miad@odoo.com> Forward-Port-Of: odoo/odoo#163215 Forward-Port-Of: odoo/odoo#160509
This fix resolves a testing issue where portal user tests were failing when the system runs without demo data. The solution creates a portal user during test setup to ensure tests can run reliably in all environments. This improves the stability of the testing framework.
Original PR description
The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass. build-error: 55927 Forward-Port-Of: odoo/odoo#163116
This fix removes duplicate code that was causing the inbox message counter to increment twice for each new message. The same notification logic was being executed in two different places, leading to incorrect counter values. Removing this duplication ensures users see accurate unread message counts.
Original PR description
This code is a duplicate of the mail.message/inbox notification (https://github.com/odoo/odoo/blob/17.0/addons/mail/static/src/core/web/mail_core_web_service.js#L43) resulting in the counter being incremented twice.
This fix resolves a crash that occurred when users tried to remove the start date from Resource Time Off records. The system was attempting to calculate the end date based on a missing start date, causing an error. The fix ensures the end date is only calculated when a valid start date exists, preventing the crash and allowing users to manage time off records without errors.
Original PR description
This traceback arises when the user tries to remove the `start date` Steps to produce 1. Install `resource` 2. Open `Settings/Technical/resource/Resource Time Off` 3. Create a new record and remove…
This traceback arises when the user tries to remove the `start date`
Steps to produce
1. Install `resource`
2. Open `Settings/Technical/resource/Resource Time Off`
3. Create a new record and remove the `start date`
Error:
```AttributeError: 'bool' object has no attribute 'tzinfo'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1073, in onchange
todo = [
File "addons/web/models/models.py", line 1076, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1189, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6664, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar_leaves.py", line 58, in _compute_date_to
date_to_tz = user_tz.localize(leave.date_from) + relativedelta(hour=23, minute=59, second=59)
File "pytz/tzinfo.py", line 317, in localize
if dt.tzinfo is not None:
```
when the user tries to remove the start date, an error will be produced because _compute_date_to seems to be computing the date_to based on the date_from field. when removing the `date_from` from calculations on empty or none
which leads to traceback from here
https://github.com/odoo/odoo/blob/322e7ea19b7c069fdb92d3b86e5615c55489ca21/addons/resource/models/resource_calendar_leaves.py#L54-L59
This PR solves the above issue by computing `date_to` for records that have
`date_from`. Apart from that, this PR also removes `# -*- coding: utf-8 -*-`
from the first line of the modified file.
sentry-4983497879
Forward-Port-Of: odoo/odoo#163136
Forward-Port-Of: odoo/odoo#154555This update corrects how test users are configured in the base module's testing framework. The fix ensures that tests properly use the demo user defined in the test class, which resolves a build error and improves test reliability. This is a maintenance fix that doesn't affect end users but strengthens the quality of the software.
Original PR description
build-error: 55926 Forward-Port-Of: odoo/odoo#163107
This update makes it easier for businesses to customize the default time period used in stock quantity reports. Instead of requiring code changes, administrators can now adjust the reporting period through system settings, improving flexibility and reducing implementation time.
Original PR description
Use an ir.config_parameters to set the period for the stock quantity report to ease customization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163017
This update allows businesses to manage subcontractor inventory using standard stock practices, which may affect on-hand inventory values. The change maintains safeguards for internal locations to protect financial valuation accuracy. This gives companies more flexibility in how they track and manage subcontractor stock.
Original PR description
Some people want to manage the subcontractor stock the same way than a classic stock. It will then impact the on hand value but it's the behavior they want. I keep the constraint on internal location since it will impact valuation. 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#163177
This update fixes how the website handles page scrolling to work correctly regardless of where the scroll is positioned. It resolves bugs that occurred when customizations changed the default scrolling behavior, while keeping the standard version unchanged. The fix unifies code across different versions for better consistency.
Original PR description
*: web, web_editor Follow-up of [1] (see its own explanation for details). This is about fixing the remaining code. In the future, we will probably go even further: - No more wrapwrap element at all - No support of a main scroll which is not left up to the browser (see some more details about that in [2] which explains the many problems which occurred when the scroll was on the wrapwrap element). Those final points have yet to be confirmed though. All in all, this PR should not change any behavior in the standard stable versions. But it will fix bugs in some custo trying to change the page scrolling behavior, while unifying the versions codebases. [1]: https://github.com/odoo/odoo/commit/ffc19547c8da2ef7fee8e2ac743ab99a607dcf90 [2]: https://github.com/odoo/odoo/pull/98429 Forward-Port-Of: odoo/odoo#163247 Forward-Port-Of: odoo/odoo#159748