Tuesday, April 30, 2024
39 changes · master
Enhancements to existing features
The Documents app description has been updated to better explain what the app offers. This helps users understand its purpose and key capabilities more easily when browsing or installing apps.
Original PR description
This PR changes the summary of the documents app to better intimate the user about the features and functionalities provided by the app. Task-[3874778](https://www.odoo.com/web#id=3874778&cids=2&model=project.task&view_type=form)
Appointments that are assigned to users can now let customers pick a time first, then show which staff members are available for that slot. This makes booking easier when the appointment time matters more than choosing a specific person upfront.
Original PR description
This PR enables the 'time_resource' option for appointments based on users, allowing users to select the time first and then showing available users based on the selected time. Task-3729624
Invoice submission messages for Peru EDI now clearly indicate when documents are sent in testing mode. This helps users avoid confusing a test submission with a real submission to the government.
Original PR description
Before this commit, when you submit an invoice through the EDI even in testing mode, the message in the chatter is saying that the document has been sent to the government. Which is disturbing for the users, some of them think they submitted correctly the invoice but in fact it was in testing mode. From now on, when the setting is set, the message is changed to say that you are in testing mode. task-3300375
Product lifecycle and shop floor processes now capture manufacturing changes more accurately, including components, by-products, operations, and quality checks. Teams get clearer change history, better synchronization, editable version details, and smoother suggestion handling through notes instead of activities.
Original PR description
Adapt models to better reflect BoM changes: - component & by product - operation & quality step and improve the synchronization mecanism to better identify changes. Replace activities by notes for Suggestions. Fix some UI points. See odoo/odoo#137231 See odoo/upgrade#5225 task: 3059466
Field Service Reports now show the actual descriptions entered on timesheets, making work details easier for customers and teams to understand. The signature area is also visually separated with an added line break, improving the report layout and readability.
Original PR description
In this commit: - Display the actual descriptions of timesheets to enhance clarity. - Introduce a break line before the signature for improved visual organization. task-3837098
Time-related field labels have been standardized across service applications, including helpdesk, planning, project forecasting, field service reports, and customer portals. This makes screens and reports easier to understand and reduces confusion when users compare time information across different workflows.
Original PR description
In this commit we have made improvement in the time labels task-3330297
Payslips that create a journal entry now show whether that entry is still in draft or has been posted directly on the smart button. This helps payroll users quickly confirm accounting progress without opening the journal entry first.
Original PR description
When creating a journal entry (account.move) from a payslip, it shows a smart button to access the journal entry. With this, it will also show if the entry is still in draft or is posted. Task: 3861578
Documents now use a simpler standard list view by default in the activity view. This removes unnecessary document-specific panels and drag-and-drop behavior in that context, making the activity workflow cleaner and reducing the need for special fixes.
Original PR description
This commit adds a basic list view for documents.document model with no js_class attribute and with a higher priority to make it usable by default in the activity view. This avoid getting a fully customized list view with the document inspector and drag and drop utilities. This allows to revert various fixes, now not necessary anymore. Task ID-3837270
Users can now cancel signature requests directly from the signing interface, making it clearer how to opt out of reminders or decline a request. Refused and ignored requests are now handled consistently as canceled, simplifying follow-up and request tracking.
Original PR description
Although we make it possible to opt-out of automated reminders via a link in the email, this is not super visible and we should also make this possible in the sign UI. To simplify some flows, we can merge this with the 'refusal' flow and with the 'ignore' flow. Indeed, if one decides to ignore a sign request it means they have no intent to sign - might as well cancel it. Essentially, this commit merges refused and ignored states to canceled in the backend. On top of that we also add a cancel button on the kanban view of sign request and on the control panel in the sign request client action. task-3675303
Point of Sale-related modules can now receive and use additional server-calculated information on records without needing a predefined field. This makes country-specific invoicing, compliance, and payment flows easier to support while reducing duplicated client-side calculations.
Original PR description
*: All pos related modules
This commit allows to access arbitrary data in related models. This is
useful for data that are computed on the server side and that are not
recomputed on the client side.
Before this commit, it was only possible to access data that are linked
to a field in the model.
Now custom data coming from the server can be added to any record with
the prefix `_` in the key. For example, if the server sends the
following data for `pos.order`:
Classic fields:
```
{
id: 1,
name: 'Order 1',
partner_id: 1,
partner_name: 'Partner 1',
}
```
Custom fields:
```
{
id: 1,
name: 'Order 1',
partner_id: 1,
partner_name: 'Partner 1',
_custom_field: 'Custom value',
}
```
Comunity PR: https://github.com/odoo/odoo/pull/160169The Appraisals department kanban view and related settings layout were reorganized for better consistency with other Odoo modules. This makes the interface feel more familiar and easier to navigate for users managing appraisal-related department information.
Original PR description
* = hr_appraisal Reorder settings views to be consistent with others modules. task: 3817650
Barcode users can now scan a lot or serial number directly from the main barcode screen when tracking is enabled. This makes it faster to look up item details without navigating into another workflow, though duplicate lot or serial numbers will show the first matching product found.
Original PR description
In this commit , when tracking is active - it will show text 'Scan a Lot/SN to know its details.' on barcode main screen. - when scanning the lot/sns it will show details of it . - if there is a case where same lot/serial exists for different product then it will show details of the first found. task_id = 3601021
Resolved issues and error corrections
Updated the subscription checkout test setup so the website and sales order use the same company. This prevents currency access mismatches during automated testing, making subscription checkout validation more dependable without changing customer-facing behavior.
Original PR description
Modifies `test_cart_update_so_recurrence` to use a consistent company for both sale.order and website, resolving access issues to `company_id.currency`. Previously, the test encountered a scenario where `compute_all` could not access the correct currency, as it depended on the company from the sale.order, which differed from the website's company. By aligning the company across both entities, the test now correctly accesses the necessary currency, ensuring reliable test outcomes. Related: odoo/odoo#144389 task-2596416
Code cleanup and technical improvements
The restaurant appointment point-of-sale navigation menu was adjusted to work with Odoo's standard dropdown behavior. This keeps the user experience consistent after the broader POS menu update and reduces the risk of display or interaction issues.
Original PR description
In the corresponding commit we replace the custom burger menu in the pos navbar with the `Dropdown` component from `web`. In this commit we adapt an override to respect the new changes. https://github.com/odoo/odoo/pull/162397
Miscellaneous changes
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner. ![image](https://github.com/odoo/
Original PR description
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the…
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner.  2. Create a new invoice and select the partner configured in number 1.  The payment way doesn't change, it is "Por definir" by default. Desired behavior after PR is merged: After this is merged the invoice payment method will be the same as assigned in the partner.  Forward-Port-Of: odoo/enterprise#61114
Manufacturing users who do not have PLM access can now create Bills of Materials with lines without being blocked by a permissions issue. This helps manufacturing managers complete setup work without needing extra PLM permissions.
Original PR description
Currently, creation of BoMs with lines triggers a search of MrpEco records. This breaks BoM creation for non-PLM users (e.g. MRP managers). This commit fixes the issue by using `sudo().search()`.
Removed two unintended lines that were accidentally left in an accounting reports calculation method. This keeps the reporting code cleaner and helps reduce the risk of unexpected behavior in financial report processing.
Original PR description
This commit introduced 2 lines of unwanted code: https://github.com/odoo/enterprise/commit/e72b8dd7c48385cd189319938bbe40a886e9ea53
A bug in accounting reports was corrected so report groupings are validated using the report itself rather than looping through records incorrectly. This helps prevent report errors in affected accounting report configurations and keeps financial reporting behavior reliable.
Original PR description
Introduced in odoo/enterprise@e72b8dd7c48385cd189319938bbe40a886e9ea53
Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337 Forward-Port-Of: odoo/enterprise#61356 Forward-Port-Of: odoo/enterprise#58613
Original PR description
Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337 Forward-Port-Of: odoo/enterprise#61356 Forward-Port-Of: odoo/enterprise#58613
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. Community PR: https://github.com/odoo/odoo/pull/161498 opw-3809693 Forward-Port-Of: odoo/enterprise#60621 Forward-Port-Of: odoo/enterprise#60537
Before this commit: When a portal user navigates through the Signatures using the arrow buttons, an error "500: Internal Server Error" is raised. Traceback error: values = self._get_page_view_values(sign_item_sudo, sign_item_sudo.access_token, values, TypeError: CustomerPortal._get_page_view_values() got multiple values for argument 'access_token' This happened because the argument 'access_token' is passed two times: 1. sign_item_sudo.access_token 2. in **kwargs This commit aims to
Original PR description
Before this commit: When a portal user navigates through the Signatures using the arrow buttons, an error "500: Internal Server Error" is raised. Traceback error: values = self._get_page_view_values(sign_item_sudo, sign_item_sudo.access_token, values, TypeError: CustomerPortal._get_page_view_values() got multiple values for argument 'access_token' This happened because the argument 'access_token' is passed two times: 1. sign_item_sudo.access_token 2. in **kwargs This commit aims to fix the issue by deleting 'access_token' from kwargs. Task: 3853020 Forward-Port-Of: odoo/enterprise#60299
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The list of the excluded partners are passed in the "forced_domain" options. Like that, the ast.literal_eval function is not applied on it and the error is not raised. opw-3770944 Forward-Port-Of: odoo/enterprise#61452
Currently we are able to receive Peppol documents in a specific journal. When working with multiple purchase journals, or having specific flows in the Documents app to process incoming vendor bills, it makes sense to receive your Peppol documents in the Documents app to process them. This change does just that by giving the user the option to receive incoming Peppol documents either in a journal, the Documents app, or both. It also allows to assign specific tags to the document. [task-3
Original PR description
Currently we are able to receive Peppol documents in a specific journal. When working with multiple purchase journals, or having specific flows in the Documents app to process incoming vendor bills, it makes sense to receive your Peppol documents in the Documents app to process them. This change does just that by giving the user the option to receive incoming Peppol documents either in a journal, the Documents app, or both. It also allows to assign specific tags to the document. [task-3519604](https://www.odoo.com/web#id=3519604&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/154706 Forward-Port-Of: odoo/enterprise#61480 Forward-Port-Of: odoo/enterprise#57018
The soda import wizard message has been changed in commit https://github.com/odoo/enterprise/commit/6322a1850ec95948c517b6db5ecc9bff3e18f755\. The change in the message reflects a behavior change when the codabox module is installed. This message should stay unchanged when the codabox module is not installed. Forward-Port-Of: odoo/enterprise#61214
Original PR description
The soda import wizard message has been changed in commit https://github.com/odoo/enterprise/commit/6322a1850ec95948c517b6db5ecc9bff3e18f755\. The change in the message reflects a behavior change when the codabox module is installed. This message should stay unchanged when the codabox module is not installed. Forward-Port-Of: odoo/enterprise#61214
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/
Original PR description
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/odoo/enterprise/pull/49900 in attempt to keep the popover open when updating the sign item role. Forward-Port-Of: odoo/enterprise#60613
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
Original PR description
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
To reproduce: ============= - configure helpdesk team with email address - contact this email address with a contact doesn't exist in the database -> the created ticket won't have a description Problem: ======== the message's `author_id` is not set, which prevents the description to be set, as we compare the `partner_id` of the ticket with the message's `author_id` to make sure to deal with real customer and not Odoobot or anything else. Solution: ========= instead of comparing t
Original PR description
To reproduce: ============= - configure helpdesk team with email address - contact this email address with a contact doesn't exist in the database -> the created ticket won't have a description Problem: ======== the message's `author_id` is not set, which prevents the description to be set, as we compare the `partner_id` of the ticket with the message's `author_id` to make sure to deal with real customer and not Odoobot or anything else. Solution: ========= instead of comparing the `partner_id` of the ticket with the message's `author_id`, we compare the `partner_email` of the ticket with the message's `email_from`. opw-3850228 Forward-Port-Of: odoo/enterprise#60858
Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default. Forward-Port-Of: odoo/enterprise#61686
Original PR description
Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default. Forward-Port-Of: odoo/enterprise#61686
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206
Original PR description
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206
_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
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 Forward-Port-Of: odoo/enterprise#61509 Forward-Port-Of: odoo/enterprise#61277
Missing condition that is hiding the "Reset to Draft" button on all journal entries. Forward-Port-Of: odoo/enterprise#61677
Original PR description
Missing condition that is hiding the "Reset to Draft" button on all journal entries. Forward-Port-Of: odoo/enterprise#61677
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an helpdesk ticket for the same customer - select the previous created sale order item - create a timesheet for this helpdesk ticket - from the sale order, create the invoice - confirm the invoice - go to the invoice and click on preview - click on view timesheets --> we have the c
Original PR description
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an…
Steps to reproduce: ------------------- - create a product: - service - based on timesheets - create a project and task on order - create an order with this product - confirm the order - open an helpdesk ticket for the same customer - select the previous created sale order item - create a timesheet for this helpdesk ticket - from the sale order, create the invoice - confirm the invoice - go to the invoice and click on preview - click on view timesheets --> we have the correct timesheet (OK) - go to the task and create a timesheet - create the second invoice from the sale order - go to the second invoice and click on preview - click on view timesheets --> we have the two timesheets which is wrong (KO) Cause: ------ When we build the domain to search for timesheets linked to an invoice, we add an `OR` domain which takes into account timesheets linked to helpdesk tickets (and on the same sale order line). Solution: --------- When searching by invoice, it is necessary to look for timesheets in the helpdesk tickets, but making sure that they are not linked to an invoice that may not be the one requested in the search. opw-3865963 Forward-Port-Of: odoo/enterprise#61596 Forward-Port-Of: odoo/enterprise#61287
Before this commit: while creating new using the studio line is not visible also this same issue is in dark mode too. After this commit: while creating a new app using Studio Line should be visible properly in normal mode and dark mode too. Task-3845561 Forward-Port-Of: odoo/enterprise#61656
Original PR description
Before this commit: while creating new using the studio line is not visible also this same issue is in dark mode too. After this commit: while creating a new app using Studio Line should be visible properly in normal mode and dark mode too. Task-3845561 Forward-Port-Of: odoo/enterprise#61656
…ements - Add partner name check for Ultimate Debtor/Creditor (UltmtDbtr/UltmtCrdt) - Add transaction name check for Additional Remittance Information (AddtlRmtInf) Initial request from Swedish partner @daniel-stenlov, confirmed with documents: https://www.nordea.com/en/doc/nordea-caar-camt.053.001.02-account-statement-extended-0.pdf Related: https://github.com/odoo/enterprise/pull/49542 Co-authored-by: daniel-stenlov Forward-Port-Of: odoo/enterprise#59927
Original PR description
…ements - Add partner name check for Ultimate Debtor/Creditor (UltmtDbtr/UltmtCrdt) - Add transaction name check for Additional Remittance Information (AddtlRmtInf) Initial request from Swedish partner @daniel-stenlov, confirmed with documents: https://www.nordea.com/en/doc/nordea-caar-camt.053.001.02-account-statement-extended-0.pdf Related: https://github.com/odoo/enterprise/pull/49542 Co-authored-by: daniel-stenlov Forward-Port-Of: odoo/enterprise#59927
Following [#enterprise/60947](https://github.com/odoo/enterprise/pull/61042) , after neutralizing the field new_car, this had an effect on the wishlist simulation since the new wishlist contract considered that this contract had a new car, leading to an atn and a depreciated cost of 0 Forward-Port-Of: odoo/enterprise#61262
Original PR description
Following [#enterprise/60947](https://github.com/odoo/enterprise/pull/61042) , after neutralizing the field new_car, this had an effect on the wishlist simulation since the new wishlist contract considered that this contract had a new car, leading to an atn and a depreciated cost of 0 Forward-Port-Of: odoo/enterprise#61262
The Belgian "Post a tax report entry" wizard was modified to pop only when the closing entry corresponds to a Belgian tax. Prior to this commit, the "Post a tax report entry" wizard would pop when attempting to post a closing entry that corresponds to non-Belgian taxes. It should not pop up. task-3829124 Forward-Port-Of: odoo/enterprise#61556 Forward-Port-Of: odoo/enterprise#61223
Original PR description
The Belgian "Post a tax report entry" wizard was modified to pop only when the closing entry corresponds to a Belgian tax. Prior to this commit, the "Post a tax report entry" wizard would pop when attempting to post a closing entry that corresponds to non-Belgian taxes. It should not pop up. task-3829124 Forward-Port-Of: odoo/enterprise#61556 Forward-Port-Of: odoo/enterprise#61223
Mandatory Analytic Plans should be mandatory. This was not checked when reconciling a bank statement. This commit adds a check to ensure that the analytic distribution is correct when reconciling a bank statement. Task: 3864633 Forward-Port-Of: odoo/enterprise#60740
Original PR description
Mandatory Analytic Plans should be mandatory. This was not checked when reconciling a bank statement. This commit adds a check to ensure that the analytic distribution is correct when reconciling a bank statement. Task: 3864633 Forward-Port-Of: odoo/enterprise#60740
With an MX company setup Accounting > Reporting > Tax Report Choose "Generic Tax Report", select last fiscal year period Generate Closing Entry (Tax accounts needs to be configured) Post the closing entry Traceback will raise AttributeError: 'account.report' object has no attribute 'action_periodic_vat_entries' It is caused by a wrong inheritance of the MX tax report opw-3846942 Forward-Port-Of: odoo/enterprise#61251
Original PR description
With an MX company setup Accounting > Reporting > Tax Report Choose "Generic Tax Report", select last fiscal year period Generate Closing Entry (Tax accounts needs to be configured) Post the closing entry Traceback will raise AttributeError: 'account.report' object has no attribute 'action_periodic_vat_entries' It is caused by a wrong inheritance of the MX tax report opw-3846942 Forward-Port-Of: odoo/enterprise#61251
HOW TO REPRODUCE ================ Log in as an internal user who is not a member of the `documents_user` group. Go to your profile. You should see the "Documents" smart button. However, the button has a `groups` attribute to restrict its visibility to the members of the `documents_user` group. HOW TO FIX ========== This issue is already known and a tolerated side-effect (see this [commit](https://github.com/odoo/odoo/pull/29659/commits/3651a3721865a465f5457b67436939a91f904bd1))
Original PR description
HOW TO REPRODUCE ================ Log in as an internal user who is not a member of the `documents_user` group. Go to your profile. You should see the "Documents" smart button. However, the button…
HOW TO REPRODUCE ================ Log in as an internal user who is not a member of the `documents_user` group. Go to your profile. You should see the "Documents" smart button. However, the button has a `groups` attribute to restrict its visibility to the members of the `documents_user` group. HOW TO FIX ========== This issue is already known and a tolerated side-effect (see this [commit](https://github.com/odoo/odoo/pull/29659/commits/3651a3721865a465f5457b67436939a91f904bd1)) Moreover, it makes sense for any internal user to be able to access the Documents application, whether they have rights on it or not. As an employee, they may have documents they need to access (e.g.: contract, payslip...) The solution would be to remove the `groups` attribute from the smart button to reduce confusion among developers. And also, clarify that, indeed, any internal users can see the "Documents" smart button in their profile. task-3688377 Forward-Port-Of: odoo/enterprise#61227