Wednesday, December 13, 2023
19 changes · 17.0
Enhancements to existing features
This update adds support for the Bank of Guatemala's official exchange rates as a currency rate provider in Odoo. Users in Guatemala can now automatically fetch daily exchange rates directly from the Bank of Guatemala's webservice. Additionally, the currency rate provider list has been reorganized with country codes and alphabetical sorting for better usability.
Original PR description
In Guatemala the practice is to use the exchange rates provided by the Bank of Guatemala. They offer a webservice to fetch the daily rates that we are adding as a Currency Rate Provider in this commit. Further we are cleaning up the Current Rate Provider list by adding the country code in front of the label and sorting alphabetically. [task-3581837](https://www.odoo.com/web#id=3581837&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#52540 Forward-Port-Of: odoo/enterprise#50686
When a closed subscription order is reopened (such as when a customer makes a payment to reactivate), the system now automatically clears the expiration date. This prevents the order from being automatically closed again on the same day it's reopened. Sales teams can manually adjust the expiration date if needed for specific situations.
Original PR description
Before this commit, when a churned order was reopened by portal payment, the end_date was left untouched. The expiration cron could close it the same day than the reopening. This commit remove the end date. We need to remove it and notify because we can't track all the possibilities: * order reaches the end date, auto close, customer pay to reopen it: --> we want to remove the end_date * 2 years order is closed by customer after a few months, it was a mistake. We want to reopen it but the end date should be preserved. It is not possible to distinguish easily these 2 cases and the others. As we want to keep the flow simple, we decide to let the salesperson decide. opw-ticket 3614318 Forward-Port-Of: odoo/enterprise#52523 Forward-Port-Of: odoo/enterprise#51732
Resolved issues and error corrections
This change restores a faster way to load email delivery failures, avoiding long waits and memory errors for users opening the related Discuss view. It is a pragmatic performance fix for the stable version while preserving the previous quick behavior.
Original PR description
Earlier PR improved ACLs in Discuss [1]. Route `/mail/load_message_failures` was made in non-sudo as to take ACLs into account, so that we don't get mail failures that we don't have access [2] However, checking ACLs on `mail.message` from `search` on `mail.notification` is very slow [3], to the point where the RPC takes minutes and results in a `memoryerror`. Ideally we should have non-sudo and make checking ACLs more performant. As a quick fix in a stable version, we revert to using `sudo`, which results in same quick results as before. [1]: https://github.com/odoo/odoo/pull/138330 [2]: https://github.com/odoo/odoo/pull/138330/files#diff-6be51f3695e69474a19cf6857370c8bb9b529a15d568952258cec9a0ae519fc4R23 [3]: https://github.com/odoo/odoo/blob/17.0/addons/mail/models/res_partner.py#L251
The attendance kiosk now correctly uses the configured front camera when scanning from a mobile device. This fixes a setup issue where the wrong setting was passed internally, helping employees check in more smoothly.
Original PR description
Issue: ====== Front camera doesn't open even if we set it in the configuration. Steps to reproduce the issue: ============================= - Install attendance - Go to attendance/ configuration and put front camera in barcode source - Use mobile : Go to kiosk mode and start scanning Origin of the issue: ==================== There was a typo in the props values where we assigned `employee` to `barcodeSource` opw-3621239 opw-3608019
Fixes a crash that could occur in Manufacturing shop floor operations when users changed the quantity of a tracked component in the detailed operations popup. The popup now saves the updated quantity and closes normally, preventing disruption during production workflows.
Original PR description
To reproduce: - Create and confirm MO with a tracked component (qty 1, in stock) - Open the shop floor app and click on the move line for the component - In the pop-up, change the quantity to 2 and click save Current behavior: Crash on an infinite recursion. The issue was introduced in [1], as setting picked to True in the stock.move write triggers another call to write on the stock.move, resulting in the infinite recursion. Expected behavior when this PR is merged: The quantity on the stock.move is updated, and the popup closes. By just updating the vals of the write, we do not trigger the write method again and avoid the recursion while still maintaining the wanted functionality from [1]. [1] https://github.com/odoo/odoo/commit/fe508c6b2cb1b92d7b063cc194a3dad37f4eb255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public visitors can now browse the shop without hitting an access error when products are configured not to continue selling after stock runs out. This keeps the storefront accessible while still respecting product availability settings.
Original PR description
Issue: ====== When we have a product with `out of stock:continue selling` disabled, accessing the shop page will give an access error. Steps to reproduce the issue: ============================= - Make sure to have a storable product with `out of stock: continue selling` disabled in the sales tab of the product. - Log out and go to shop - Access error related to warehouse records Origin of the issue: ==================== The function `_website_show_quick_add` being called from the template in odoo/addons/website_sale/views/templates.xml to display the shopping card button in at the bottom of the product. Since the user is public he doesn't have the right to access the record in warehouse to see if the product is out of stock or not. The test `test_back_in_stock_notification_product` already tests the fix and doesn't work without this fix , so no need to add extra test. opw-3620172
Currency conversion results now update correctly when exchange rates are created or changed. This prevents outdated cached rates from being reused, reducing the risk of incorrect financial amounts.
Original PR description
Currently there is the following issue with cached conversion rates from the "from currency" to the "to currency". When the rate of the res_currency_rate of the "to currency" changes the cache is not invalidated. Thus the cached value may be used wrongly (leading to wrong results). This commit simply invalidates all the cached rates in case we update or create a res_currency_rate.
This update fixes a bug in the Knowledge app where downloaded files were getting an unwanted underscore character added to their names. The issue was caused by hidden formatting characters being accidentally included when saving file names. Users will now see correctly named files when downloading from Knowledge documents.
Original PR description
There is an issue on some browsers where the name of a download file always has an `_` at the end of it. How to reproduce: - open Knowledge and insert a /file block - click on the file name and edit it (don't use the `_` character) - confirm with enter - click on Download Current Behavior: - the downloaded file name has an `_` at the end of it even though it should not Technical explanation: The pen icon that is displayed on hover contains a `zeroWidthSpace` character added by the editor and that character was mistakenly appended to the name of the file since it was recovered with `textContent` applied on a `div` ancestor. The name will now be recovered directly from the `textContent` of the `span`, and a class is added to the `span` to ensure that it will not be sanitized by the editor (see [1]). [1]: https://github.com/odoo/odoo/commit/0f4914a1576108bb0843694a62d679bc78a8574a task-3627975
This fix corrects an issue where the Field Service Management module was displaying total inventory from all warehouses instead of just the user's assigned warehouse. When technicians added products to FSM tasks, they now see accurate stock levels for their specific warehouse location, ensuring better inventory visibility and task planning.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock`. - Create a new warehouse. - Assign you a default warehouse on your user's profile. - For a defined product ensure there is stock in the 2 warehouses. - Create a new FSM task, and click on the add product stat button. - You should see that the On Hand stock displayed if the stock of all warehouse. Cause: This issue happen because, when retreiving the `qty_available` for the products, the context doesn't contain the warehouse that should be used, so the method `_compute_quantities` get quantities from all warehouse. Solution: Override `action_fsm_view_material` in industry_fsm_stock to add the user default warehouse in the context. opw-3516524 Forward-Port-Of: odoo/enterprise#51400
Fixed a bug in the budgeting module where budget amounts were only calculated correctly when using the project's default analytic plan. Now users can create budgets with any analytic plan and see accurate budget figures. This resolves issues where budgets using alternative plans would incorrectly show zero amounts.
Original PR description
Only the project default plan was taken into account. To reproduce: * create a budget using a plan that is not the project one * impossible to get something else than 0 for the practical amount [opw-3611855](https://www.odoo.com/web#id=3611855&model=project.task) [opw-3599827](https://www.odoo.com/web#id=3599827&model=project.task) [opw-3624641](https://www.odoo.com/web#id=3624641&model=project.task) [opw-3612305](https://www.odoo.com/web#id=3612305&model=project.task) [opw-3633650](https://www.odoo.com/web#id=3633650&model=project.task) [task-3634231](https://www.odoo.com/web#id=3634231&model=project.task)
This fix resolves a crash that occurred when sending signature requests through the activity chatter. The issue was caused by a missing required parameter in the signature request workflow. Users can now successfully send signature requests without encountering errors.
Original PR description
To reproduce ============ - In the chatter, click on "Activities" - Change the "Activity Type" to "Request a Signature", then "Schedule" it - For the newly created entry in the Chatter, "Request Signature", click on "Request Signature" - Select a "Template" for the Signature Request, then a "Customer" - "Send" the Signature Request -> Traceback Problem ======= in the patch of `Activity`, the `onClose` method of `requestSignature` is set to `onUpdate`, but `onUpdate` needs the `thread` argument which is not given Solution ======== give `thread` argument opw-3626964
Users with "Bookkeeper" or "Read-Only" accounting access rights were unable to open the accounting app dashboard due to missing permissions for EDI export records. This fix adds read-only access permissions for the Account Report Async Export feature, allowing these users to view the dashboard without errors.
Original PR description
Issue: traceback when opening the accounting app with Marc Demo (if its Accounting access rights is "Bookkeeper" or "Read-Only"). "You are not allowed to access 'Account Report Async Export' (account.report.async.export) records. This operation is allowed for the following groups: - Accounting/Accountant Contact your administrator to request access if necessary. " This is raised when loading the dashboard of the accounting app (see `_get_journal_dashboard_data_batched` in l10n_fr_reports). Solved by adding a readonly ir.model.access for the `account.report.async.export` model. runbot error: 28388 Forward-Port-Of: odoo/enterprise#52618
This fix resolves an issue where users encountered errors when trying to archive articles that were already inactive. The system was incorrectly attempting to reactivate these inactive articles during the archiving process, which violated database constraints. The fix ensures that only active articles are toggled to inactive status during archiving, preventing the error.
Original PR description
In the `_action_archive_articles` action, the `toggle_active` function is called to deactivate all articles intended for archiving. Internally, this function flips the active status of all records in the recordset. If a user attempts to archive an already inactive article, the `toggle_active` method inadvertently reactivates the article. Given the SQL constraint stipulating that archived articles should be inactive, users encounter a `CheckViolation` error when trying to archive an inactive article. To address this issue, we will invoke the `toggle_active` method on the active records and disregard the inactive ones, ensuring that they are not mistakenly reactivated. task-3624569 Forward-Port-Of: odoo/enterprise#52061
This fix corrects an issue where subtasks created in Field Service Management projects were incorrectly assigned to the default "Field Service" project instead of the parent task's project. The system now properly inherits the project from the parent task, ensuring subtasks stay within the correct project context.
Original PR description
Versions: --------- - saas-16.2 - saas-16.3 Steps to reproduce: ------------------- - create a new FSM project; - create a task in this project; - create a subtask for this task in the "Sub-tasks" tab. Issue: ------ The project of the subtask is the "Field Service" project. Cause: ------ If no project is found in the context, the first project found in the default database is used by default. Solution: --------- Add the project of the parent task (found via the context) or fallback to the first fsm project in the company. Note: From version saas-16.4, no project is added. opw-3602334 Forward-Port-Of: odoo/enterprise#52531 Forward-Port-Of: odoo/enterprise#52025
Fixed a bug in Web Studio where toggling a field's conditional visibility setting wasn't being saved properly. When users tried to remove or change the invisible property on a form field, the system would ignore the change and keep the field invisible. This fix ensures visibility changes are now correctly applied and saved.
Original PR description
Consider a field in a form view having a conditional invisible property. When toggling the invisible property (setting it to either true or false), the `onChangeModifier` method removes the invisible property from the `attrs` object. However, a bug occurs when this attrs object is now empty. Before this commit, the `attrs` attribute will now be removed from the attribute update operation. As a result the old value is kept, instead of the attribute being removed. To fix the bug, the `attrs` attribute should be kept in the operation with an empty string value instead. opw-3497068 Forward-Port-Of: odoo/enterprise#52552 Forward-Port-Of: odoo/enterprise#47518
Sales users without accounting permissions were unable to view invoices due to a security restriction error. This fix restricts access to certain internal fields to accounting users only, allowing Sales users to properly view invoices they created while maintaining security controls.
Original PR description
- Install Sales, Accounting and l10n_mx_edi - Switch to a MX company (e.g. ESCUELA KEMPER URGATE) - Create an user with Administration rights in Sales and no right in Acounting (e.g. User X) - With…
- Install Sales, Accounting and l10n_mx_edi - Switch to a MX company (e.g. ESCUELA KEMPER URGATE) - Create an user with Administration rights in Sales and no right in Acounting (e.g. User X) - With User X, create a SO and confirm it - Create an invoice from the SO - With an user with Accounting rights, confirm the invoice - Generate CFDI with "Send & Print" button - Register payment - With User X, try to open the invoice => An AccessError is raised: "Due to security restrictions, you are not allowed to access 'Journal Item' (account.move.line) records." Cause: The error is raised when accessing "l10n_mx_edi_update_payments_needed" field in the invoice form view. Solution: In the invoice form view, "l10n_mx_edi_update_payments_needed" and "l10n_mx_edi_update_sat_needed" fields are invisible fields that are only used for the invisible attribute of 2 buttons that are limited to "account.group_account_invoice" group. Therefore, these 2 fields can also be limited to "account.group_account_invoice" group. opw-3611022 Forward-Port-Of: odoo/enterprise#51572
This fix resolves a layout issue in Canadian check printing where the memo field was overlapping with the vendor's address country information. The memo has been repositioned lower on the check to prevent this overlap when printing checks with complete address information including Street 2.
Original PR description
### Steps to reproduce * install `l10n_ca_check_printing` * switch the company to 'CA Company' * in the settings, select the top or middle check layout * create a vendor payment with the 'Checks' payment method * fill in the Vendor, Amount and Memo field. Make sure the vendor has all the address fields filled in, including 'Street 2' * confirm and print the check You should see that the memo overlaps with the country of the address. opw-3576240 Before:  After:  Forward-Port-Of: odoo/enterprise#52245
This fix ensures that Mexican electronic invoices are only marked as cancelled when the cancellation request is successfully processed by the SW sapien service provider. Previously, invoices were being cancelled without verifying the service's response code, which could lead to data inconsistencies. Now the system properly validates that the cancellation request returns a success code (201 or 202) before updating the invoice status, matching the behavior of other supported service providers.
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Configure MX PAC with SW sapien - Create an invoice, confirm it and process it by E-invoicing service - Once processed, request EDI cancellation => The invoice is directly set as cancelled without checking the returned code of the cancellation request. Solution: Only cancel the invoice if the cancellation request returns 201 or 202 code as it is done for "Quandrum" and "Solucion Factible" services. opw-3459442 Forward-Port-Of: odoo/enterprise#52638 Forward-Port-Of: odoo/enterprise#51367
This update removes recent changes made to the Field Service Management module's project sharing views that were not compatible with the stable version. The revert ensures consistency with a corresponding update made to the core Odoo system and prevents issues in production environments.
Original PR description
Revert [1] This commit is linked to another commit OC side that reverts [2] because [2] applied some changes not allowed in stable. Therefore, we also need no revert [1] [1] https://github.com/odoo/enterprise/commit/094009669beaac46ed6ebb7689ecffea59c375ae [2] https://github.com/odoo/odoo/commit/b3e3c92b52ce326661c262046cc455c3439fa1a1 OPW-3629163 sentry-4700256130