Daily updates from Odoo
Thursday, September 4, 2025
31 changes · saas-18.4
Enhancements to existing features
Payroll contract templates now carry over country-specific payroll fields more reliably when new employee contracts are created. This helps HR teams avoid missing local compliance or payroll details and adds validation to reduce future regressions.
Original PR description
This commit implements _get_whitelist_fields_from_template() method across all HR payroll localizations to ensure that localization-specific fields are properly copied when creating contracts from templates. Additionally, tests has been added for all localizations to validate the whitelist functionality and ensure proper template loading behavior. task-4954283
Resolved issues and error corrections
Fixes a website editor issue where changing an Image Wall layout could crash if one of the images had a link. This helps users safely edit image galleries without losing work or being blocked by an error.
Original PR description
When at least one of the images in the image wall has a link, the editor will crash when trying to change the mode of the Image Wall, i.e. from Masonry to Grid. Steps to reproduce the issue: - Drag and drop an images wall - Click on any of the images - Add a link (Click on the chain icon in the `Media` option and then add a URL) - Click on 'Mode' - Try to change to Grid for example. => We have a traceback. This commit follows the [html_builder refactoring]. Task-5005626 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Fixes an issue where website editors did not immediately see the correct navigation bar layout after changing previewable settings such as content width. The preview now refreshes the layout right away, helping users make design decisions without needing to resize the browser or reload the page.
Original PR description
Following this [commit] and the [html_builder refactoring], when we preview or apply changes that effect the navbar, we wouldn't see the proper layout until a resize event or reload. Steps to see the issue: - Open website and start editing - Click on a navbar - Change the Content Width to "Small" => The navbar isn't centered, and potentially reflowing if we have enough items in the navbar. Related to task-4367641 [commit]: https://github.com/odoo/odoo/commit/10d727175f5845d6be6fa69f6adaae1126eea826 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb
Canceling an import after uploading a spreadsheet now safely checks the import data before continuing. This prevents users from seeing an error and returns them to the previous screen when the import cannot proceed, improving reliability across import workflows.
Original PR description
Before commit: - After uploading an Excel file, when user cancels a bank statement import, it caused an `InvalidDomainError` due to an invalid `resIds` value in the domain. After commit: - This error is resolved and now the `Cancel` button validates `resIds` before passing it into the domain. If `resIds` are invalid, the user is navigated back instead. **Note:** This `InvalidDomainError` occurred in all modules when users canceled import operations. This PR fixes the issue across the system by adding proper validation for `resIds` before processing the domain. Task : 4974749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now correctly shows the highlight tool as active when selected highlighted text is revisited. This helps users understand the current formatting state and avoid unnecessary repeated edits.
Original PR description
With the initial [website builder refactor], the highlight tool did not show when it is active or not. This commit adds the `active` class on the button when it is. Steps to reproduce: - Open website builder - Select some text - Add a highlight - Select the same text again (and expand the toolbar again) - Bug: the highlight tool is not shown as active [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Discuss now correctly clears unread indicators when a user opens a channel after another browser session already marked it as read. This prevents stale unread badges and keeps message status consistent across multiple browser windows.
Original PR description
Before this commit, if you opened an unread channel that the server already considered “read,” the channel would remain marked as unread in your browser. This typically happens when one browser instance misses the bus notification that cleared the unread status. Steps to reproduce: 1. Open Discuss as the same user on two browsers (A and B) 2. Send a message to said user 3. Stop bus notifications on browser A 4. Read the message on browser B 5. Re-enable bus notification on browser A 6. Open the channel on browser A -> not being marked as read This happens because the method `_set_last_seen_message` skips sending the notification when the message seen is older than the current `seen_message_id` (previously set by the other browser). This commit fixes the issue by setting the `allow_order` parameter in the rpc call. task-4863058 Forward-Port-Of: odoo/odoo#224881 Forward-Port-Of: odoo/odoo#218623
This fixes an error that prevented users from activating the Employee calendar view through Studio. The calendar setup now uses searchable employee contract dates, allowing the view to be enabled without a crash.
Original PR description
Steps to reproduce: - On the Employee app, activate Studio - Switch to the "Views" menu - Click on "Calendar" under the "Timeline views" group - A traceback happens and you can not activate the view Reason: The calendar view tries to setup itself with the fields "date_start" and "date_end" of hr.version. However, those two fields are computed fields, and thus not stored, which causes an error when the fields are used in a SQL query. How it was fixed: By defining a search method for both hr.version.date_start and hr.version.date_end that overrides them with contract_date_start and contract_date_end which are not computed fields. Task ID: 5043792
This fixes an issue where some public-facing pages, such as meeting room booking and kiosk installation screens, could appear blank. The page now loads correctly even when a usual page container is missing, improving reliability for users accessing these screens.
Original PR description
**Before this PR:** The screen appears blank in places like meeting room booking view, install kiosk app page (events, attendance, rooms, frontdesk), etc. **Version:** Although this issue exists in future versions, it is fixed in the version where public interactions are introduced. **Technical reason:** The issue was introduced by this commit: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b Happens while loading frontend assets. Here, if `#wrapwrap` is absent in dom then interaction service is not started and returned as a null. Now we keep `body` as a fallback of `#wrapwrap`. **After this PR:** The screen will load correctly and will no longer be blank. Task-4915155 Forward-Port-Of: odoo/odoo#222033
This fix keeps the editor’s text selection when users select content with the keyboard and preview formatting changes. As a result, color and background color tools remain available instead of closing unexpectedly, making text editing more reliable.
Original PR description
Steps to Reproduce: - Go to To-do and create a new item. - Type something in the editor. - Select all the text using Ctrl + A (keyboard). - Try to change the color/background color. - The toolbar closes suddenly. Current behavior before PR: - The selection was only being saved when using a mouse. Keyboard-based selections (like Ctrl + A) were not staged. - As a result, when undoing a preview, the editor couldn't restore the selection. Desired behavior after PR is merged: - Now the selection is saved earlier, so it can be restored properly when reverting to previous step. - This keeps the toolbar open and working as expected. task-4941601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now more accurately recognizes internal Odoo links, including links that use the Odoo instance domain. It also better identifies valid website pages, reducing incorrect warnings when users preview links such as shop category pages.
Original PR description
Before this commit: the condition to check if an url is internal is not complete as the user could user the odoo instance domain instead of the real domain. The check if an internal url is a frontend one is rather naive as there are cases where the url ends with a number but actually not leading to a record. Reproduction for the second use case: 1. create a link with frontend url for example `/shop/category/16` 2. click on the link, when it loads the preview, a warning pops up After this commit, the cases explained above are included. task-4971829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update speeds up an internal test selection process by avoiding unnecessary checks when special test tags are not being used. It also helps prevent issues in environments where source files are unavailable, improving reliability for development and release workflows.
Original PR description
`get_method_additional_tags` can be slow when there are a lot of test to load while the feature is only needed in rare cases. This commit removes the check if the corresponding tag is not in the config test-tags. This should also solve an issue when the sources are not available. Forward-Port-Of: odoo/odoo#225109 Forward-Port-Of: odoo/odoo#225061
This fix prevents a timing issue where newly uploaded attachments could be deleted by an automated cleanup before their record was fully saved. It improves reliability for users accessing documents such as PDFs and uploaded files, reducing the risk of broken or missing attachments.
Original PR description
Should ideally land in 13.0... Let's merge it in 18.3 where we need it first... Then backport it to 16.0 if deemed useful/necessary. --- There is a race condition between `ir.attachment.create` and…
Should ideally land in 13.0... Let's merge it in 18.3 where we need it first... Then backport it to 16.0 if deemed useful/necessary.
---
There is a race condition between `ir.attachment.create` and `ir.attachment._gc_file_store` that can lead to the creation of an attachment with no related file in the file store.
Race
----
The race runs as follow:
1) `_gc_file_store` acquires a write exlusif lock on the ir_attachment table, but is interrupted by the OS before it can load the file gc checklist.
2) `create` kicks in, write a new file on file-system, adds an entry in the checklist, but can't create the ir.attachment record yet as the table is locked.
3) `_gc_file_store` resumes, load the checklist, see that `create`'s file as no attachment and removes it. It then releases the write exclusif table lock.
4) `create` resumes, it creates the `ir.attachment` record.
Subsequent access on the ir.attachment created record `raw` or `datas` fields fails because the file doesn't exist on disk.
Test
----
https://gist.github.com/Julien00859/512cfbad47c15febbfd667a017df7c8b
The `test_attachment_concurrency_create_gc` test reproduces the above steps to reproduce the bug. It does so by mocking the appropriate functions and using `threading.Event` to synchronize the execution plan between the two threads. Run it using the following command:
--test-tags database_breaking.test_attachment_concurrency_create_gc
It is database breaking because the ir.attachment file created during the test may not cleaned after the test run (in case the power goes down at the wrong moment).
Description
-----------
The bug was introduced by commit afdfdbfa5b36b in 13.0. Before that commit the create override in ir.attachment would first create the record, and only then write the file on disk. This way the `create` function acquired first a row exclusif lock and only then wrote the file and the checklist.
That the error went undercover for several years can be explained as follow:
1. The ir.autovacuum model and its cron has been unreliable for many years, it was often reported that the `_gc_file_store` (being the last in the list) did not run.
2. That the cron did not run made for a huge checklist that couldn't be processed all at once.
3. The cron usually only run once per night, when there are less people connected on the database to create attachments.
4. Finally, embarassing, we did discard some "missing file" reports and instead blamed the customers who reported them.
That we discover the error now is another chain of events:
1. The ir.autovacuum model now makes an advanced usage of the cron progress API. The cron is now automatically scheduled to run again "as soon as possible" when an exception occured in one of the `@api.autovacuum` methods.
2. The documents autovacuum is failing in 18.3 100% of the time (this is being addressed in another PR). This forces the "run again as soon as possible" condition permanent. The cron is basically always running.
3. The Odoo employees are all paid at the same time, and we all receive a PDF payslip as attachment. As many attachments as there are employees are created at a same time.
Some of us couldn't download our August payslip :-(
Forward-Port-Of: odoo/odoo#224833The website editor now handles icon spin effects and color changes more reliably. Users can undo icon spin changes, see the toolbar state correctly, and color selected text and icons together with consistent background opacity.
Original PR description
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted…
**Current behavior before PR:** - Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail. - The spin icon in the toolbar was not highlighted after applying the effect. - When some text is selected along with icon, trying to apply color only affects the icon, the text remains uncolored. **Desired behavior after PR:** Now, - History step is created after adding spin effect to an icon, allowing undo to work properly. - The spin icon in the toolbar is properly highlighted to reflect the applied effect. - This PR removes `color_apply_overrides` from icon_plugin to let color_plugin handle coloring the icons ensuring that the selected text is also colored along with icon. - This PR also makes sure that default 60% opacity is applied when applying solid background color on icons or table cells. task-4794673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225017 Forward-Port-Of: odoo/odoo#210341
This fixes website analytics goal tracking so custom goal details are sent in the expected format again. Businesses using Plausible analytics can rely on conversion reports with custom parameters, such as cart-related goals, remaining accurate after the recent website framework update.
Original PR description
Since commit b9b3a60, conversion to owl, the props are sent as string instead of object.
This commit restores old behaviour of using a JSON object for props.
Before commit b9b3a60:
> $($0).data('event-params')
{Type1: 'cart'}
After commit b9b3a60:
> $0.dataset.eventParams
'{"Type1": "cart"}'
After this commit:
> JSON.parse($0.dataset.eventParams)
{Type1: 'cart'}
opw-oxpslide-stbu
Forward-Port-Of: odoo/odoo#225324This update prevents Turkish Nilvera invoices from being sent with non-compliant negative lines and corrects how discount and product identification data appear in the electronic invoice file. It also fixes an access issue so eligible accounting users can check Nilvera customers even without the Accountant app installed.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to fix certain compliance issues apparent in the UBL structure of Nilvera. an access right issue was also occurring when account is…
Description of the issue/feature this PR addresses: This PR aims to fix certain compliance issues apparent in the UBL structure of Nilvera. an access right issue was also occurring when account is installed but not account_accountant when doing check_nilvera_customer. Current behavior before PR: - access right error when doing check_nilvera_customer with account_accountant uninstalled. - negative lines were allowed in nilvera invoices and were reflected in the xml document. - StandardItemIdentification displays the products barcode under the invoice line. - multiplierfactor was not reflecting the discount % of the invoice line Desired behavior after PR is merged: - added read access to account module specific groups. - raise a blocking error if there are discount lines in the invoice. - remove the StandardItemIdentification node from the xml document - show discount % in the multiplierfactor task-4907751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224028 Forward-Port-Of: odoo/odoo#223136
The Secure Entries wizard has been optimized so it can open reliably even when a company has accumulated a very large number of accounting entries waiting to be secured. This greatly reduces memory use and waiting time, helping users complete the process instead of encountering failures or timeouts.
Original PR description
Description ----------- On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be…
Description
-----------
On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be hashed.
This can lead to the processing of a large number of moves when opening the Secure Entries wizard, more specifically:
```
-> `_compute_warnings`
-> `_compute_hash_date`
-> `_compute_max_hash_date`
-> `_get_chains_to_hash`
```
While manipulating this large recordset, the ORM prefetcher will read *all* fields on the model upon the first cache miss, which usually are a lot, and some of them are quite large (label type fields).
This commit refactors the code to avoid any cache miss by fetching only what is necessary. This is achieved by:
- Use of a `_read_group` instead of 2 subsequent `groupby`
- Delegate `max` and `min` lookup to the database
- Explicitly fetch the fields that are going to be read
- Avoid the linear search into the associated statement lines for unreconciled moves
- Introduce a context key `chain_info_warnings` to skip the warnings computation of `_get_chain_info`, as it's unused for the context of `_compute_max_hash_date`.
Benchmark
---------
On a database with over 1.3M `account.move` that are pending hashing, opening the wizard for the Secure Entries took:
| | Before* | After | Improvement |
|--------------|---------|---------|-------------|
| Memory | 6.8 GiB | 700 MiB | 9.9x |
| Query Count | 26.7k | 18.5k | 1.4x |
| Timing SQL | 41.2s | 18s | 2.3x |
| Timing PY | 7.29min | 14s | 31.2x |
| Timing Total | 7.98min | 32s | 15x |
\* - benchmark was taken with unlimited memory, the request takes more than 2 GiB -> OOM killed and never completes
Reference
---------
opw-5014345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225247
Forward-Port-Of: odoo/odoo#224105This fix prevents Odoo test runs from crashing when no test tags are configured. It helps CI pipelines using pytest integrations complete reliably instead of failing on an internal configuration default.
Original PR description
Description of the issue/feature this PR addresses: The issue arises when using pytest (to get junit xml for CI) with [pytest-odoo==1.0.1](https://github.com/camptocamp/pytest-odoo) ``` run_tests def get_method_additional_tags(self, test_method): run_tests """Guess if the test_methods is a query_count and adds an `is_query_count` tag on the test run_tests """ run_tests additional_tags = [] run_tests > if 'is_query_count' in odoo.tools.config['test_tags']: run_tests E TypeError: argument of type 'NoneType' is not iterable run_tests run_tests ../custom/src/odoo/odoo/tests/common.py:778: TypeError ``` Info @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225496
When a user is archived, their assigned activities are now found and removed even if those activities belong to a company that is not currently selected. This prevents old tasks from remaining visible after a user has been deactivated, improving data cleanup consistency in multi-company setups.
Original PR description
**Steps to reproduce:** - Set up one user with a new company - With this user : - Create sale order - Create activity on the new sale order - Go back to the admin user - Disable the new company in…
**Steps to reproduce:**
- Set up one user with a new company
- With this user :
- Create sale order
- Create activity on the new sale order
- Go back to the admin user
- Disable the new company in the top right menu
- Archive the user
- Activities of the user are still present
**Issue:**
In `activities_to_delete = self.env['mail.activity'].search([('user_id', 'in', self.ids)])`, the access rights of the records used in the activities are checked, which means that the sale order domains are applied. If the given domain doesn't match (for example `('company_id', 'in', company_ids)` when the company_id is manually disabled), the search can miss the activity to unlink.
**Fix:**
Added `.sudo()` to ensure all of the user's activities of any company
are considered, overwriting the current company context.
opw-4716031
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225389
Forward-Port-Of: odoo/odoo#206813This fixes guided tours so they wait for page changes to finish before looking for the next item to click. It prevents tours from accidentally going backwards or failing when a menu action is still loading a new screen.
Original PR description
Step to reproduce: - Create a tour - Add a step that click on a menuitem on the systray with a view already opened - Then add a step that click on the search bar of the view Before this commit, if the step of a tour was triggering an action (e.g.: a menuitem) and that the next step's trigger was finding an element on the view before the action has finished to update the view, then the tour was backwarding because the found element diseppeared when the new action loaded the new view. Now, the tour interactive wait that the action manager finish to update the view to be sure the get the right element for the step trigger. ISSUE: https://github.com/odoo/odoo/issues/214652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220319
Incoming vendor invoice emails are now accepted when the sender is an existing user who does not have access to the target company. This prevents valid emailed invoices from being rejected in multi-company setups and keeps invoice creation through journal email aliases reliable.
Original PR description
To reproduce the bug: 1- Create a DB with two companies and accounting app 2- Create a user and allow it to access company 2 3- Send a email using the user email to alias from purchase journal alias of company 2 4- The email will be rejected 5- Send a email using a random email address to alias. 6- The email will be accepted and an account.move is created. In a normal flow, when a user associated to the email not exists, the user_id is set to odoobot, otherwise, the user accosiated to the email. In the buggy flow the bug happens because `_compute_company_id` in account_move model, will set `company_id` to empty when user has no access to the company, as a result the `account_move` will fail. opw-4853027 Forward-Port-Of: odoo/odoo#225263 Forward-Port-Of: odoo/odoo#217322
This fix ensures mandatory leave days are calculated correctly when there are one or several leave requests across one or several employees. It helps HR teams get more reliable leave planning and avoids incorrect leave balances or scheduling outcomes.
Original PR description
- Fixed the calculation of leave mandatory leaves to account for one or multiple leaves for one or multiple employees Task-4804618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225427 Forward-Port-Of: odoo/odoo#223349
The Indian e-waybill screen now shows errors and warnings with the correct visual colors, making important messages easier to understand. Errors appear in red and warnings in yellow, reducing confusion for users reviewing e-waybill issues.
Original PR description
Before: --- Error and warning colors were mismatched in the e-waybill view. In this commit: --- Fixed the e-waybill view to correctly display error messages - Errors now display in red (alert-danger) :red_square: - Warnings now display in yellow (alert-warning) :yellow_square: AccessError now handled correctly. --- task-5050937 Forward-Port-Of: odoo/odoo#225288 Forward-Port-Of: odoo/odoo#225078
This fix prevents Accounting app installation from failing when demo data is loaded for a German database. It allows the system’s chart template cleanup process to proceed without incorrectly triggering audit trail protections, reducing setup errors for new databases.
Original PR description
When installing the Accounting app on a new database created with Germany as country and with demo data loaded, the demo loader invokes in `account/demo/account_demo.xml` the `<function name="try_loading">` call which does a wholesale `records.with_context({MODULE_UNINSTALL_FLAG: True}).unlink()`. This cascades into deleting mail.message records, but the audit‑trail hook in only bypasses its check when the `bypass_audit` token is present not when `MODULE_UNINSTALL_FLAG is set causing a “You cannot remove parts of the audit trail” UserError.
Steps to reproduce:
- Created new database, with Germany as country
- Install l10n_de
- Download demo data
- Attempt to install Accounting application ! Receive error message
OPW- 4712364
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221260Odoo Sign now checks uploaded PDFs more carefully and blocks unsupported encrypted files before users try to sign them. This prevents a validation failure that could interrupt document completion, giving users a clearer and more reliable signing flow.
Original PR description
Currently an error occurs when signing an encrypted file with empty password. **Steps to replicate** * Install `Sign` * Sign> Upload a pdf > Add following…
Currently an error occurs when signing an encrypted file with empty password. **Steps to replicate** * Install `Sign` * Sign> Upload a pdf > Add following [pdf](https://drive.google.com/file/d/1M0_VzWLzv-lSZ-IlI9Zmx-M7jFGvtJJj/view?usp=sharing)> Sign the document using `Sign now` * Validate and send completed document `AttributeError: 'NoneType' object has no attribute 'seek'` **Cause:** This occurs because [1] returns `None` to the variable `output` at [2] which in turn passes the `None` value to [3] causing the error. Error occurs in python 3.12+, because it does not throw an exception in `_check_pdf_data_validity`. **Solution:** * Add a validation to prevent upload of unsupported files. [1]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_document.py#L242-L243 [2]: https://github.com/odoo/enterprise/blob/e7861f1ddef2fb9628eebca93942e64c73cc95fc/sign/models/sign_completed_document.py#L33-L34 [3]: https://github.com/odoo/odoo/blob/033c7a63bdf3d10d9d2c5084959fd34f52011bea/odoo/tools/pdf/signature.py#L51 **Sentry-6784800544,6802557168** Forward-Port-Of: odoo/enterprise#91766
The wage index wizard now selects the right contract version depending on whether users start from an employee form or list. Wage changes are applied consistently to matching contract versions and recorded in the employee history, improving payroll accuracy and traceability.
Original PR description
This commit fixes the wage index wizard broken since the contract-version refactor. - If coming from an employee form view, the wizard will by default select the selected version - If coming from an employee list view, the wizard will by default select the current version id of the selected employees - The wage is indexed for all versions that have the same contract date start/end of the selected version on the wizard - The changes are written in the employee's chatter (it indicates all versions that were indexed) task-4997195
Danish Intrastat and EC Sales List reports now use whole-unit rounding where required for official reporting. Users can still view decimal values in the interface when needed, but government export files are always rounded to meet submission rules.
Original PR description
This commit will change the options of the reports so that we have a rounding in units since the intrastat and ec sales list report must be rounded. This solution still allows people to have the report with decimals if needed task-4948271 Forward-Port-Of: odoo/enterprise#93783 Forward-Port-Of: odoo/enterprise#91268
This fix helps website generation recover properly when two processes try to update data at the same time. Instead of failing permanently, the system can now retry the operation, reducing occasional errors for users creating or updating websites.
Original PR description
When a concurrency error occurs, we need to let it retry. To do this, we must catch the Serialization Failure and raise it.
This update ensures a quality control test can run correctly when the module is installed on its own without demo data. It avoids false test failures related to missing user permissions for serial number label printing, improving reliability for validation and maintenance.
Original PR description
## Issue:
The test `test_receipt_validation_triggers_serial_number_label_print` fails when running `quality_control` alone without demo data
## Cause:
The user is missing the group `stock.group_production_lot`, that enable serial number printing
As a result, the condition `self.env.user.has_group('stock.group_production_lot')` in `stock.picking` `_get_autoprint_report_actions()` is not satisfied
The `button_validate()` in `stock.picking` will have an empty report_actions and will not print anything
The Demo data that allow the test to work is in `stock`
https://github.com/odoo/odoo/blob/9b08449f25cd16dc15117d305726380298c313d8/addons/stock/data/stock_demo.xml#L176-L182
## Steps to reproduce:
- Install only `quality_control` (no demo data)
- Run the test `test_receipt_validation_triggers_serial_number_label_print`
related-to: https://github.com/odoo/enterprise/pull/90134
opw-4790427
Forward-Port-Of: odoo/enterprise#93799
Forward-Port-Of: odoo/enterprise#93296The PLM dashboard now shows a more accurate count of engineering change validations that are specifically waiting for the current user. This helps users prioritize their own approval work without being distracted by approvals assigned to others.
Original PR description
The dashboard of PLM displays for each ECO type the number of validations pending in general, and the validations waiting for me specifically. The latter has been incorrectly computed for quite some time, as it computes how many ECOs exists where I am an approver and an approval is waiting - but there is no guarantee that the waiting approval is one of mine; it might be that I am a past approver of the ECO and that another approval (waiting for somebody else than me) exists, or that two approval are required on the same stage (one by me, one by somebody else) and I already approved. This commit switches the computation around by looking for pending approvals waiting for me, and then get the number of (non-archived) ECOs bound to them. Forward-Port-Of: odoo/enterprise#93728 Forward-Port-Of: odoo/enterprise#92348
This fix ensures portal users cannot become owners of Documents spreadsheets, because spreadsheets cannot be shared with editing rights to non-internal users. It helps keep ownership and access permissions aligned, reducing confusion and preventing unsupported sharing scenarios.
Original PR description
Following the discussion I had with @flch-odoo regarding https://github.com/odoo/enterprise/pull/92134 , Since Spreadsheets can not be shared in edit mode to non-internal users, we prevent them from becoming owners. opw-4753670 Forward-Port-Of: odoo/enterprise#93800 Forward-Port-Of: odoo/enterprise#92409
This fix stops Documents from opening a broken linking flow when there are no vehicle records available. Users will no longer see a crash when trying to link a document from the Fleet folder before any vehicles have been created.
Original PR description
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet`…
*= documents_fleet Currently, when user tries to link a document with a vehicle and if there is no vehicle exists an error is raised. **Steps to Reproduce:** 1) Install `documents_fleet` module(without Demo Data). 2) Open Documents App. 3) Upload a file in `Fleet` folder. 4) Select the uploaded file and click on `'Link to a vehicle'` button. Error: `ValueError: invalid literal for int() with base 10: 'False'` Root Cause: The `link_to_record` method attempts to find the first record of the target model to use as a default value when opening the linking wizard. If no records exist, the search returns an empty recordset, and accessing `.id` at [1], on it results in the value `False`. The code then incorrectly constructs a default reference string like `fleet.vehicle,False`. The wizard crashes when it tries to parse this string and convert the `False` part to an integer. Solution: This commit prevents error by ensuring that the user cannot link a document to a model without existing records. [1]- https://github.com/odoo/enterprise/blob/83640d21b2c31ed9d572c48e02a9aeea9eb1607b/documents/models/documents_workflow_rule.py#L113 sentry-6792079496 Forward-Port-Of: odoo/enterprise#93738 Forward-Port-Of: odoo/enterprise#91888