Tuesday, April 30, 2024
85 changes · master
Enhancements to existing features
The department kanban view and related settings pages have been reorganized across HR apps to make the interface more consistent and easier to navigate. A duplicated timesheet department view was also removed, reducing maintenance overhead without changing business functionality.
Original PR description
* = hr{, _holidays, _skills, _expense, _timesheet, _recruitment, _attendance}
Reorder settings views to be consistent with others modules.
task: 3817650
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen users create a subtask from a shared project, it now automatically keeps the same milestone as the parent task. This makes shared project behavior consistent with the main Odoo backend and reduces manual corrections.
Original PR description
Before this commit milestone set on task does not set on newly created sub task in project sharing by default and it was setting it by default in backend. This commit add contect to set milestone by default on newly created subtask from project sharing to be consistant with backend. task-3716784
This update moves tests for the web properties field to Odoo's newer testing framework. It helps maintain reliability for this part of the web interface without changing how users interact with the product.
Original PR description
task-3705027 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
Quiz reporting screens now display long eLearning questions more cleanly. This helps users review quiz results without question text being cramped or cut off.
Original PR description
When user goes to eLearning > Reporting > Quizzes and selects a long question, we notice that the text display of question is not ideal. This PR addresses the issue by: - Handling the display length of the question by adding the class `oe_title`. - Allowing the text of question to be displayed in multiple lines when it exceeds a certain limit, using `widget=text`. Task-[3870115](https://www.odoo.com/web#id=3870115&menu_id=4722&cids=2&action=333&active_id=965&model=project.task&view_type=form)
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)
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
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
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
The 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
Resolved issues and error corrections
Creating a button from the editor now opens the link dialog with the expected primary button option selected by default. This fixes a regression that could confuse users and helps them create styled buttons with fewer extra steps.
Original PR description
**Current behaviour before PR:** When hitting "Button" command through powerbox, link dialog gets opened with the default option of "link" instead of "Button Primary" which is the regression of commit [1]. **Desired behaviour after PR:** Now, hitting "Button" opens link dialog with the default option of "Button primary". [1]: https://github.com/odoo/odoo/commit/356c78b task-3850381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The Point of Sale navigation menu was rebuilt using Odoo’s standard menu component instead of a custom version. This makes the interface easier to maintain while keeping the user experience consistent across related POS flows.
Original PR description
In this commit we replace the custom burger menu in the pos navbar with the `Dropdown` component from `web`. This simplifies the codebase. https://github.com/odoo/enterprise/pull/61027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This is a followup on [1]. In Chrome the event's currentTarget is cleared after events such as "scroll" are handled. For asynchronously called methods to be able to access it, the current value of currentTarget needs to be kept. To help developers that might stumble on this issue when using `throttleForAnimation`, this commit emphasizes the fact that usage of that function is not limited to event handlers, and it adds a test case that illustrates a solution for tracking the lost scrol
Original PR description
This is a followup on [1]. In Chrome the event's currentTarget is cleared after events such as "scroll" are handled. For asynchronously called methods to be able to access it, the current value of currentTarget needs to be kept. To help developers that might stumble on this issue when using `throttleForAnimation`, this commit emphasizes the fact that usage of that function is not limited to event handlers, and it adds a test case that illustrates a solution for tracking the lost scroll event target. No scenario was identified in 15.0, but this could be used as an alternative solution for [1]. [1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d task-3449843 Forward-Port-Of: odoo/odoo#161908 Forward-Port-Of: odoo/odoo#131259
This fixes a test so it only checks modules that are actually installed in the current setup. It helps prevent false build failures across different Odoo editions or configurations, improving release reliability without changing user-facing behavior.
Original PR description
Before this commit, this test will fail depending on installed modules (community, single, ...) Filtering on installed modules fixes the issue. Build-error-62458
This update fixes an internal automated test for date and time entry so it waits properly for clicks to complete. It helps reduce false failures in the validation system, giving teams more confidence that builds fail only for real issues.
Original PR description
Use "await contains(...).click()" instead of just "click(...)" to be sure that the test wait that the event is finished before continuing. Fixes runbot error 62232 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 fixes an issue where the web app did not properly clear an auto-save listener when a form tab became hidden. It helps avoid unnecessary background behavior and keeps form handling more reliable for users.
Original PR description
Fix for a mistake using the event listener api. The listener was never properly removed.
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
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
The web module's layout tests were converted to a newer internal testing framework. This helps keep quality checks maintainable and reliable without changing how users experience the product.
Original PR description
task-id: 3705027
Several Odoo modules had their automated tests updated to use the newer testing framework instead of older test utilities. This is an internal maintenance change that helps keep future development reliable without changing day-to-day user functionality.
Original PR description
The goal of this task is to get rid of all Qunit tests that rely on `@mail/../tests/helpers/test_utils` Task-3818666
Auto-save checks for forms were moved into a dedicated test file to make the test suite easier to maintain. This is an internal cleanup that helps developers work more efficiently without changing how users experience Odoo.
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
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing
Original PR description
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system…
**Step to reproduce:** - Go to /jobs (install website_hr_recruitment) - Go on a job offer - Click on the "Apply" button - Edit the form **Purpose:** Since the implementation of commit [1], our system employs alerts resembling `this field 'partner_name' is mandatory for the action 'actionName'`. However, this alteration has led to a bug where in certain forms exhibit an undefined action name value, particularly evident when users attempt to modify specific forms containing required fields. The bug manifests when an alert is triggered, and the action name becomes undefined due to the condition `this.modelCantChange` evaluating to `true` within the `willStart` function. Consequently, invoking `_super` results in the return of `willStart` without assigning a value to `currentActionName`. **After this commit:** Now, before returning the function, it sets a value for `currentActionName` and then proceeds with the necessary steps. This prevents the issue where an action was `undefined`. [1]: https://github.com/odoo/odoo/pull/120874/commits/491a25b2baaa415a9bc26340eba5a11af8605411 task-3680483 Forward-Port-Of: odoo/odoo#163057 Forward-Port-Of: odoo/odoo#157501
Steps to reproduce: - create an empty spreadsheet - type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")' => #ERROR There's no account that match the given code. The account.move.line domain ends up having a clause `('account_id', 'in', [])` The ORM detects the domain won't match anything and early returns an empty list [] Our code expects a query object and not a list => boom --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
Steps to reproduce:
- create an empty spreadsheet
- type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")' => #ERROR
There's no account that match the given code.
The account.move.line domain ends up having a clause `('account_id', 'in', [])`
The ORM detects the domain won't match anything and early returns an empty list []
Our code expects a query object and not a list => boom
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163455
Forward-Port-Of: odoo/odoo#163165If you create an applicability and remove the company field, they are never used. An applicability like this should be valid for all companies. We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields. Same idea as the distribution models. opw-3847415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162152
Original PR description
If you create an applicability and remove the company field, they are never used. An applicability like this should be valid for all companies. We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields. Same idea as the distribution models. opw-3847415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162152
Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to. task-3748816 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#162400
Original PR description
Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to. task-3748816 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#162400
This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues. opw-3839287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163018
Original PR description
This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues. opw-3839287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163018
Otherwise we leave the constraints in the table. Common source of upgrade issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161115
Original PR description
Otherwise we leave the constraints in the table. Common source of upgrade issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161115
Steps to reproduce the bug: - Create a storable product “P1”. - Update its quantity to 10. - Create a delivery picking: - Add the product “P1” with 10 units. - Mark as to do. - Scrap 1 quantity of “P1”. - Try to validate the picking. Problem: A wizard asking to create a backorder is triggered. This occurs because the move of the scrap is created, linked to the picking, and marked as 'done' (so, picked). Therefore, when validating the picking, we will checks if all the move
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”.
- Update its quantity to 10.
- Create a delivery picking:
- Add the product “P1” with 10 units.
- Mark as to do.
- Scrap 1 quantity of “P1”.
- Try to validate the picking.
Problem:
A wizard asking to create a backorder is triggered. This occurs because the move of the scrap is created, linked to the picking, and marked as 'done' (so, picked). Therefore, when validating the picking, we will checks if all the moves are picked (Even if not picked, it will work because we'll set them all to 'picked'). but as the first move is not picked and the scrap one is picked, the backorder wizard is raised.
opw-3821869
Forward-Port-Of: odoo/odoo#163395Steps 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 Forward-Port-Of: odoo/odoo#163375 Forward-Port-Of: odoo/odoo#162626
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 Forward-Port-Of: odoo/odoo#163375 Forward-Port-Of: odoo/odoo#162626
The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported. Original commit message: Since [1] when uploading images from URL the data is downloaded and then hosted on the Odoo instance. As stated in its task (task-3129360) it should not have been applied to document URLs. Because of this, when hitting a CORS issue to fetch binary data, we try to fetch the data through an `<img>` element by setting its `src
Original PR description
The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported. Original commit message: Since [1] when uploading…
The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported. Original commit message: Since [1] when uploading images from URL the data is downloaded and then hosted on the Odoo instance. As stated in its task (task-3129360) it should not have been applied to document URLs. Because of this, when hitting a CORS issue to fetch binary data, we try to fetch the data through an `<img>` element by setting its `src` field - which also fails when the data is not an image. This commit makes the changes of [1] specific to image uploads and restores the previous behavior for other files. Steps to reproduce: - Drop a "Text - Image" snippet. - Double-click on the image. - Go to the Documents tab. - Click on "Add URL". - Enter an example PDF URL. E.g.: https://www.africau.edu/images/default/sample.pdf - Click on "Add URL". => Fails because of a CORS issue. [the original commit]: https://github.com/odoo/odoo/commit/238566d1dea29fd11353e7e6529d29843c4f658b [1]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a task-3493618 Forward-Port-Of: odoo/odoo#163576
When the report is updated and `groupby` is updated, we might need to also update `user_groupby` if it was not compatible. Followup/fix of odoo/odoo@7d54c76aaee325449248fa698adb9e549c486ee For instance upgrading from before to after odoo/enterprise@d226977e19401f9d95b66991a69abebd466ee7e0 was an issue. Forward-Port-Of: odoo/odoo#163666 Forward-Port-Of: odoo/odoo#163526
Original PR description
When the report is updated and `groupby` is updated, we might need to also update `user_groupby` if it was not compatible. Followup/fix of odoo/odoo@7d54c76aaee325449248fa698adb9e549c486ee For instance upgrading from before to after odoo/enterprise@d226977e19401f9d95b66991a69abebd466ee7e0 was an issue. Forward-Port-Of: odoo/odoo#163666 Forward-Port-Of: odoo/odoo#163526
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:  saas-16.4:  fixed locally (16.4):  Forward-Port-Of: odoo/odoo#161111 Forward-Port-Of: odoo/odoo#161038
Steps to reproduce the problem: 1. Add a many2one field to lines of a model, example: sale.order.line 2. Add it to form view of the lines with a domain 3. Click on Search more... option 4. You will see results out of the scope of the domain In the getDomain is passed an object that has only the key fieldName but for knew in what view is the field placed it needs to be provided the key viewType, this both are placed on the class object this.recordParams builded at: https://github.com/od
Original PR description
Steps to reproduce the problem: 1. Add a many2one field to lines of a model, example: sale.order.line 2. Add it to form view of the lines with a domain 3. Click on Search more... option 4. You will…
Steps to reproduce the problem: 1. Add a many2one field to lines of a model, example: sale.order.line 2. Add it to form view of the lines with a domain 3. Click on Search more... option 4. You will see results out of the scope of the domain In the getDomain is passed an object that has only the key fieldName but for knew in what view is the field placed it needs to be provided the key viewType, this both are placed on the class object this.recordParams builded at: https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L129 If this key is not provided the viewType is beeing filled with the element viewType, this element is the record opened placed in the parent view, so by default if will be kanban or list. So if the domain is filled just in the form view, the search panel will get the domain [], so all the entries will be displayed and they will be able to be selected. If we see the next line: https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L431 We will see that getContext is getting this.recordParams as argument, for the same reason that the domain should have it. With this changes the getDomain method is getting the viewType to take the domain instead of the viewType of the lines displayed on the parent view. 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#163686 Forward-Port-Of: odoo/odoo#162983
### Steps to reproduce: Be sure to have the `sale_sms` module installed. - Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,... - Go to the field service app create a new task and change its state to `planned`. **> Access error: you are not allowed to access 'SMS Templates'** ### Expected behavior: Since the newly created user has the rights to modify the state of the task and since he does not try to access the
Original PR description
### Steps to reproduce: Be sure to have the `sale_sms` module installed. - Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,... -…
### Steps to reproduce: Be sure to have the `sale_sms` module installed. - Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,... - Go to the field service app create a new task and change its state to `planned`. **> Access error: you are not allowed to access 'SMS Templates'** ### Expected behavior: Since the newly created user has the rights to modify the state of the task and since he does not try to access the content of any sms.template he should not raise this access error. ### Cause of the issue: The stage `planned` is associated with an SMS template. As such, when a task is moved to this stage, an sms will be sent using the template. This action is done during the `write` override of the `project_sms` module: https://github.com/odoo/odoo/blob/5f1a3bdcaa63492cf169f6f5f3eb2e2281ad5ab5/addons/project_sms/models/project_task.py#L24-L32 However, this `_send_sms` method will need to 'read' the sms.template to generate the sms: https://github.com/odoo/odoo/blob/e6be732450d9ef662a48ba074e1ca1ad32e35c04/addons/sms/models/mail_thread.py#L191-L192 Since the user does not have the acess rights to 'read' this template because of the `ir_rule_sms_template_so_sale_manager` acess rule defined in the `sale_sms` module, the access error will be raised. ### Fix: Since the `_send_sms` method will only read records in order to generate the sms that will be send, we should bypass access rigths checks during the call of this method. Note: this was already the solution used for portal users. opw-3789197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163570 Forward-Port-Of: odoo/odoo#157702
[FIX] hr_expense: allow to create expenses via alias for employees not related to a user Current behavior: When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe) Steps to reproduce the error : - Create an employee not related to a user - Configure alias for expenses - Try to send an email to the expense's alias and
Original PR description
[FIX] hr_expense: allow to create expenses via alias for employees not related to a user Current behavior: When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe) Steps to reproduce the error : - Create an employee not related to a user - Configure alias for expenses - Try to send an email to the expense's alias and check at the logs After this commit: Employees without a related user will be able to create an expense from an email alias opw-3892778 opw-3892701 opw-3893319 opw-3893591 Forward-Port-Of: odoo/odoo#163672 Forward-Port-Of: odoo/odoo#163494
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/odoo#163617 Forward-Port-Of: odoo/odoo#162960
In saas-16.2, the peppol_endpoint and peppol_eas fields were added to the partner. When importing an xml inheriting from EN16931 (Peppol Bis 3, A-NZ, E-FFF, NLCIUS, etc), use the peppol endpoint and eas to retrieve the correct partner, by passing a search domain to `_retrieve_partner` (through the `domain` argument). Hence, when retrieving the partner (using `_retrieve_partner`), we will sequentially: 1. search for a partner with a matching VAT 2. if there's a domain provided, search
Original PR description
In saas-16.2, the peppol_endpoint and peppol_eas fields were added to the partner. When importing an xml inheriting from EN16931 (Peppol Bis 3, A-NZ, E-FFF, NLCIUS, etc), use the peppol endpoint and eas to retrieve the correct partner, by passing a search domain to `_retrieve_partner` (through the `domain` argument). Hence, when retrieving the partner (using `_retrieve_partner`), we will sequentially: 1. search for a partner with a matching VAT 2. if there's a domain provided, search a partner matching the domain 3. search for a partner with a matching phone or email 4. search for a partner with a matching name If not partner is found, we create a new one. opw-3815296 Forward-Port-Of: odoo/odoo#163563 Forward-Port-Of: odoo/odoo#159742
Issue ----- The trailing text on the `ir.sequence` view is unreadable due to spanning only one column which leads to awkward line-wrapping. Steps ----- - Go to Settings -> Technical -> Sequences. - Select the sequence with code "sale.order". - Have a look at the legend. Cause ----- The `<div>` containing the text spans only one column which is not suitable for long text. opw-3820141 Forward-Port-Of: odoo/odoo#161403 Forward-Port-Of: odoo/odoo#160912
Original PR description
Issue ----- The trailing text on the `ir.sequence` view is unreadable due to spanning only one column which leads to awkward line-wrapping. Steps ----- - Go to Settings -> Technical -> Sequences. - Select the sequence with code "sale.order". - Have a look at the legend. Cause ----- The `<div>` containing the text spans only one column which is not suitable for long text. opw-3820141 Forward-Port-Of: odoo/odoo#161403 Forward-Port-Of: odoo/odoo#160912
Problem --- When logged in as a portal user, if the `/jobs` route is configured to allow filtering by department the user gets a 403 when choosing a department to filter by and an `AccessError` is thrown for the `hr.department` model Steps --- * install website, and create a "Career" page in the wizard * on the `.../jobs` page: Editor > Edit > Customize > toggle 'Departments Filter' * log out and log in as `portal` (pw: `portal`) * go to `.../jobs` and select a department to filt
Original PR description
Problem --- When logged in as a portal user, if the `/jobs` route is configured to allow filtering by department the user gets a 403 when choosing a department to filter by and an `AccessError` is thrown for the `hr.department` model Steps --- * install website, and create a "Career" page in the wizard * on the `.../jobs` page: Editor > Edit > Customize > toggle 'Departments Filter' * log out and log in as `portal` (pw: `portal`) * go to `.../jobs` and select a department to filter by (dropdown in the topbar) * An `AccessError` is thrown Fix --- Give access rights to the responsible piece of code, so the website functions as expected. opw-3874665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162396
Load taxes in an end script when all modules are loaded. Move script to end. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-14>", line 2, in new File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in locked return func(inst, *args, **kwargs) File "/home/odoo/src/odoo/saas-17.1/odoo/module
Original PR description
Load taxes in an end script when all modules are loaded. Move script to end. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in…
Load taxes in an end script when all modules are loaded.
Move script to end.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line
1286, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in
locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
119, in new
odoo.modules.load_modules(registry, force_demo, status,
update_module)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/migration.py", line
240, in migrate_module
migrate(self.cr, installed_version)
File
"/home/odoo/src/odoo/saas-17.1/addons/l10n_lu/migrations/2.2/post-migrate_update_taxes.py",
line 7, in migrate
env['account.chart.template'].try_loading('lu', company)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 144, in try_loading
return self._load(template_code, company, install_demo)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 195, in _load
self._post_load_data(template_code, company, template_data)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/chart_template.py",
line 31, in _post_load_data
company._get_and_update_tax_closing_moves(fields.Date.today(),
include_domestic=True)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/res_company.py",
line 162, in _get_and_update_tax_closing_moves
report, tax_closing_options =
tax_closing_move._get_report_options_from_tax_closing_entry()
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_move.py",
line 209, in _get_report_options_from_tax_closing_entry
report_options =
tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1631, in get_options
return
self.env['account.report'].browse(options['report_id']).get_options(variant_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1470, in _init_options_section_buttons
options['buttons'] =
sections_source.get_options(previous_options={**options,
'no_report_reroute': True})['buttons']
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1585, in _init_options_custom
self.env[custom_handler_model]._custom_options_initializer(self,
options, previous_options)
File "/home/odoo/src/odoo/saas-17.1/odoo/api.py", line 534, in
__getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
224, in __getitem__
return self.models[model_name]
KeyError: 'l10n_lu.tax.report.handler'
```
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#163114When the user tries to duplicate multiple invoices of different journals, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Configuration > Journals > Create new journal (Type: Sales) - Go to Customers > Invoices > Create new invoice with newly created journal - Create another invoice with a different journal - Select both invoices > Duplicate Traceback: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5848, in ensure_on
Original PR description
When the user tries to duplicate multiple invoices of different journals, a traceback will appear. Steps to reproduce the error: - Go to Accounting > Configuration > Journals > Create new journal…
When the user tries to duplicate multiple invoices of different journals,
a traceback will appear.
Steps to reproduce the error:
- Go to Accounting > Configuration > Journals > Create new journal (Type: Sales)
- Go to Customers > Invoices > Create new invoice with newly created journal
- Create another invoice with a different journal
- Select both invoices > Duplicate
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.journal(17, 11)
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, 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 1825, 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 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, 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/account/models/account_move.py", line 2652, in copy
new_moves = super().copy(default)
File "odoo/models.py", line 5563, in copy
vals_list = self.with_context(active_test=False).copy_data(default)
File "addons/stock_account/models/account_move.py", line 29, in copy_data
vals_list = super().copy_data(default=default)
File "addons/account/models/account_move.py", line 2646, in copy_data
if not self.journal_id.active and 'journal_id' in vals_list:
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)
```
https://github.com/odoo/odoo/blob/6c621e62d4b501bb0626276df798b3f8f585fa75/addons/account/models/account_move.py#L2657
Here, self has multiple records when the user duplicates multiple invoices,
So, it will lead to the above traceback.
sentry-5231989306
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163112Before this commit: Accidentally the test case in community inherited class from enterprise After this commit: We inherit the correct class which belongs to community --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163399
Original PR description
Before this commit: Accidentally the test case in community inherited class from enterprise After this commit: We inherit the correct class which belongs to community --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163399
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202 Forward-Port-Of: odoo/odoo#157
Original PR description
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202 Forward-Port-Of: odoo/odoo#157735
Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner function first looked for a partner with company_id = env.company.id. If a parter wasn't found, a global search without constraining `company_id` was made. Thus, a search in a database with 2 partners with the same VAT (one has a company_id, the other not) would return the partner linked to the right company. After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the case. The search is done with `[('company_id'
Original PR description
Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner function first looked for a partner with company_id = env.company.id. If a parter wasn't found, a global search without constraining `company_id` was made.
Thus, a search in a database with 2 partners with the same VAT (one has a company_id, the other not) would return the partner linked to the right company.
After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the case. The search is done with `[('company_id', 'in', [self.env.company.id, False])`, so 2 partners are found, and none are returned.
We reintroduce that loop in this commit to fix that case.
Forward-Port-Of: odoo/odoo#163386
Forward-Port-Of: odoo/odoo#163188It looks like even with the registry check, we can still have rare case were the websocket request arrives after registry test mode is removed. This is fixed by checking if current test is set This flag is more reliable, but needs the backport of the new current_test behaviour (https://github.com/odoo/odoo/pull/156852). Forward-Port-Of: odoo/odoo#163110 Forward-Port-Of: odoo/odoo#163035
Original PR description
It looks like even with the registry check, we can still have rare case were the websocket request arrives after registry test mode is removed. This is fixed by checking if current test is set This flag is more reliable, but needs the backport of the new current_test behaviour (https://github.com/odoo/odoo/pull/156852). Forward-Port-Of: odoo/odoo#163110 Forward-Port-Of: odoo/odoo#163035
Params fo onRpcBefore are unclear if you don't read the code. This PR add some documentation. Forward-Port-Of: odoo/odoo#163718
Original PR description
Params fo onRpcBefore are unclear if you don't read the code. This PR add some documentation. Forward-Port-Of: odoo/odoo#163718
**Current behaviour before commit:** In website when cropper is open, pressing ESC key hides side panel. **Desired behaviour after commit:** Now, pressing ESC works same as discard button. It closes the cropper and prevents hiding side panel. task-3787411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158543
Original PR description
**Current behaviour before commit:** In website when cropper is open, pressing ESC key hides side panel. **Desired behaviour after commit:** Now, pressing ESC works same as discard button. It closes the cropper and prevents hiding side panel. task-3787411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158543
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off offi
Original PR description
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time…
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off officer: Mitchell Admin * Select **Management** > **Allocations** * Create a new allocation * Employees: Mitchell Admin * Time off time: The one created previously * Validate the allocation * Select **Management** > **Time Off** * create a new time off * Employees: Any Employee A & Employee B * Time off type: > Observation: The new time off time is present in the name search while both employees don't have any allocation for it. Why the fix: ------------ The name search searches for time off type with ``` ['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]] ``` By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok `has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138 `max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192 Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388 When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin. The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form. opw-3816442 Forward-Port-Of: odoo/odoo#163635 Forward-Port-Of: odoo/odoo#161713
In this PR: - Added Ladakh (LA, 38), Foreign Country (IN_OC, 96), and Other Territory (IN_OT, 97). - Renamed `Dadra & Nagar Haveli` to `Dadra & Nagar Haveli & Daman & Diu` (Code 26). Ref: https://einvoice1.gst.gov.in/Others/MasterCodes Task ID: [3878468](https://www.odoo.com/web#id=3878468&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#163598 Forward-Port-Of: odoo/odoo#162624
Original PR description
In this PR: - Added Ladakh (LA, 38), Foreign Country (IN_OC, 96), and Other Territory (IN_OT, 97). - Renamed `Dadra & Nagar Haveli` to `Dadra & Nagar Haveli & Daman & Diu` (Code 26). Ref: https://einvoice1.gst.gov.in/Others/MasterCodes Task ID: [3878468](https://www.odoo.com/web#id=3878468&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#163598 Forward-Port-Of: odoo/odoo#162624
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hid
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hidden, then the ui elements which overflows the visible area of the html field will be hdden too that's why only a small part of them appear. Solution: ========= To conserve the same ui and not add extra padding , we add padding to the `note-editable` to make it possible to display the ui elements fully (needs 16px) and decrease the padding of the padding of the formView sheet. Before: ======  After: =====  task-3861784 Forward-Port-Of: odoo/odoo#162029
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag
Original PR description
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag started, therefore it would never start. This commit fixes the issue by setting the tolerance to 0, so the drag and drop starts immediately. task-3802746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157584
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course U
Original PR description
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course URL without being redirected to /invite_error. This fix includes checking if the seoContext doesn't have a seoName , in which case we redirect to seoNameDefault to prevent redirection to /invite_error on the Courses page. **Task**-3688285 Forward-Port-Of: odoo/odoo#161029
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
Original PR description
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number
Original PR description
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number of days are calculated to 3.00 (jan, feb, mar). - We save the record, `already_accrued` is not saved (defaults to false) - When the scheduled action runs (2024-04-01), it will allocate 2 days instead of 1 ### Solution: This commit fixes this behavior by adding the `already_accrued` field to the form view so that it is saved when the record is created. opw-3851320 Forward-Port-Of: odoo/odoo#161508
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None
Original PR description
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None), thus generating a new alarm with the wrong call date. After this commit, we make an extra check for recurrences in the 'get_next_alarm_date' function in order to get the correct next date for the next alarm from the next recurrent event. Additionally, if there is no next date to be called in the in the future, we skip the 'send_reminder' function which was wrongly creating another alarm using 'now' as time. Issue-from: odoo/odoo#147914 Forward-Port-Of: odoo/odoo#161941
Currently we are able to receive Peppol documents in a specific journal. This change allows other modules to hook into the saving process of new Peppol documents to save them somewhere else than directly in a journal. [task-3519604](https://www.odoo.com/web#id=3519604&model=project.task&view_type=form) Related to https://github.com/odoo/enterprise/pull/57018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163405 Fo
Original PR description
Currently we are able to receive Peppol documents in a specific journal. This change allows other modules to hook into the saving process of new Peppol documents to save them somewhere else than directly in a journal. [task-3519604](https://www.odoo.com/web#id=3519604&model=project.task&view_type=form) Related to https://github.com/odoo/enterprise/pull/57018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163405 Forward-Port-Of: odoo/odoo#154706
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initiali
Original PR description
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initialization blocks is the latest to have been added, in Node.js 16.11, according to MDN's compatibility data. Forward-Port-Of: odoo/odoo#163787
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. Enterprise PR: https://github.com/odoo/enterprise/pull/60537 opw-3809693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161669 Forward-Port-Of: odoo/odoo#161498
Prior to this commit, the presence of an invalid order in the browser cache could prevent the PoS from loading. This issue typically arises after a database upgrade, where changes in fields can render unpaid orders in the cache unloadable. This commit resolves this issue by discarding any problematic unpaid orders that can no longer be loaded. opw-3874858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163201 Forward-Por
Original PR description
Prior to this commit, the presence of an invalid order in the browser cache could prevent the PoS from loading. This issue typically arises after a database upgrade, where changes in fields can render unpaid orders in the cache unloadable. This commit resolves this issue by discarding any problematic unpaid orders that can no longer be loaded. opw-3874858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163201 Forward-Port-Of: odoo/odoo#162408
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 printe
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 Forward-Port-Of: odoo/odoo#161250
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
Original PR description
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Creat
Original PR description
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Create sale order, order lines with each of the products. 4) On save, a traceback error is raised. Notes: opw-3810770 Forward-Port-Of: odoo/odoo#162547
- 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
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