Monday, July 8, 2024
41 changes
20 changes
Resolved issues and error corrections
This fix stops the web interface from registering the same template extension more than once. It reduces the risk of unexpected crashes when duplicate frontend assets are loaded, improving stability for users.
Original PR description
Before that commit, it was possible to register several times the same template extension. This can lead to crash in some occasions. For example consider the template
```xml
<t t-name="A">
<div attr="a" />
</t>
```
and its extension
```xml
<t t-name="B" t-inherit="A" t-inherit-mode="extension">
<xpath expr=".//div[@attr='a']" position="attributes">
<attribute name="attr">b</attribute>
</xpath>
</t>
```
In that case, when building the template A with B registered twice, the first application of B to A will succeed while the second application will cause a crash (no target found for the xpath).
Here we prevent multiple registering of the same template extensions. Note that this is similar to what happens when the same js module is received several times: odoo.define has no effect after the first registering.The message composer now displays recipient names and joining words with proper spacing in the chatter. This makes the recipient list easier to read and avoids a small visual glitch when sending messages.
Original PR description
Before this commit the recipients list displayed when sending a message on the chatter missed spacing between the recipients and conjunctions. This happens because the container has display flex which removes whitespace from child elements. This commit fixes the issue by wrapping the list in a div tag so to preserve the whitespace. task-4032550 Before:  After: 
Miscellaneous changes
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0 where it should be 1 day or 8 hours/ressource callendar of the employee 2.b -> if you have selected an allocation where the unit is "half_day" or the number of days and the title doesn't corresponds to each other First introduction: ------------------- task: 3084
Original PR description
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0…
### To merge in 17.0 to master -.1
Bugs:
-----
1.
both: -go to time off and click on "New Allocation Request"
-change the allocation type to any other
2.a
-> the number of days or hours is set to 0 where it should be 1 day
or 8 hours/ressource callendar of the employee
2.b
-> if you have selected an allocation where the unit is "half_day" or
the number of days and the title doesn't corresponds to each other
First introduction:
-------------------
task: 3084232
PR: https://github.com/odoo/odoo/pull/116472
Reasons:
--------
a. We where using the fields where were made for the front-end only
and where not computed properly and thus resetting the value to 0
when changing the allocation type
b. The title was using the unit of the allocation type in db and not
Labels or the unit of the allocation duration
Fixes:
------
Not use the display fields for the computation of the title and make labels corresponding to the actual unit of the allocation duration
task-3852940
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#161035An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the cal
Original PR description
An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the call to the server to retrieve the cards is made when the partner is changed. At this point the request is awaited. Runbot Error: [57047](https://runbot.odoo.com/web/#id=57047&view_type=form&model=runbot.build.error&menu_id=405&cids=1) Forward-Port-Of: odoo/odoo#171226
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce: ------------------- * Install and configure an IoT box * Go to **Point of Sale** * Select the Shop, edit it * Check `IoT Box` * Configure `Customer Display` * Now go to the settings of the Shop * Enable `Customer Display` if not already done previously * Upload a background image, save * Open the Shop
Original PR description
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce:…
Currently, when using the customer display feature with a display connected to an IoT box, the background image is not used. Instead the placeholder image is used. Steps to reproduce: ------------------- * Install and configure an IoT box * Go to **Point of Sale** * Select the Shop, edit it * Check `IoT Box` * Configure `Customer Display` * Now go to the settings of the Shop * Enable `Customer Display` if not already done previously * Upload a background image, save * Open the Shop session * Select the customer display > Observation: The background image is not shown. Why the fix: ------------ When using the customer display feature with the IoT box, the request is done with a Public User: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L171-L176 Since Public Users don't have reading access on the `pos.config` model, access rights & rules are triggered: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/odoo/addons/base/models/ir_binary.py#L52-L58 Since we failed the try block, we end up loading the placehorder image by default: https://github.com/odoo/odoo/blob/f7e3ada5ed290a6f418e4e1a2abddfb9f242270c/addons/web/controllers/binary.py#L185 We want the field `iface_customer_facing_display_background_image_1920` to be available to public user. In the case we are trying to access it with a public user, we make the request in sudo. Sudo environment stops existing once the request is made. opw-3873765 Forward-Port-Of: odoo/odoo#171994 Forward-Port-Of: odoo/odoo#169808
[IMP] l10n_tr: improve turkey's tax structure Adding new accounts Adding entirely new taxes Restructure the tax and tax group Create new tax report Reason: Enhance the user-experience in turkey Task-3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172056 Forward-Port-Of: odoo/odoo#167258
Original PR description
[IMP] l10n_tr: improve turkey's tax structure Adding new accounts Adding entirely new taxes Restructure the tax and tax group Create new tax report Reason: Enhance the user-experience in turkey Task-3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172056 Forward-Port-Of: odoo/odoo#167258
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Original PR description
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to have the discount&loyalty and free shipping options enabled. - create a product that cost 100$. - create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$. - create a shipping method based on rules where the deliv
Original PR description
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to…
Issue: - when we have a shipping method that has a discount the shipping and the delivery prices are not displayed correctly (see attached screenshot). Steps To Reproduce: - configure the sale app to have the discount&loyalty and free shipping options enabled. - create a product that cost 100$. - create a new discount/loyalty where type is promotions and set rule to if minimum 300$ spent the reward is free shipping max to 75$. - create a shipping method based on rules where the delivery product is a service that costs 100$. - in your shipping mehtod pricing add a line with if quantity >= 3.0 then fixed price 100.0 and publish it. - in your website shop select 3 items from the product you created. and select your delivery method. - notice the prices not updating correctly. Solution: - Before the fix we always assumed that free_shipping_lines are equal to 0. - free_shipping_lines might be shipping discounts not actual free shipping.so I adjusted update_eshop_carrier method to make it handle the case of discounted shipping. opw-3718885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168917 Forward-Port-Of: odoo/odoo#154487
In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend. This is because these actions only set the lot_name, not the lot_id. After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stoc
Original PR description
In a receipt picking, you can automatically set the Serial/Lots with 3 actions: 'Generate Serial/Lots' / 'Import Serial/Lots' / 'Assign Serial Numbers'. However, if 'use_existing_lots' is True on the picking type, the resulting move lines will appear without lots on the frontend. This is because these actions only set the lot_name, not the lot_id. After this commit, these 3 actions will use lot_id instead of lot_name if 'use_existing_lots' is True. They will either assign an existing 'stock.lot' or create a new one in the correct company. --- ## BEFORE https://github.com/odoo/odoo/assets/29302288/f571d68d-86cb-42bf-bf8b-5e918c2ca2c2 ## AFTER https://github.com/odoo/odoo/assets/29302288/325c7870-a24a-4094-b0c0-5ff8274712d8 --- OPW-3983532 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171741 Forward-Port-Of: odoo/odoo#171388
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by upd
Original PR description
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP…
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by updating the _cron_peppol_get_participant_status cron to include EDI users that are not yet verified. When the user has been verified on the IAP side, the state 'verified' will be returned when making a call to the participant status endpoint, for which the most accurate mapping to a client state is 'pending'. Note that when managing users from versions 17.0 to 17.2 (inclusive) the support staff responsible for verifying the user should also take the steps to ensure that they are registered on the SMP too (since users of these versions will otherwise remain in the 'pending' state indefinitely until they are manually registered on the SMP). Forward-Port-Of: odoo/odoo#171823
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
Original PR description
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
Forward-Port-Of: odoo/odoo#172070
Original PR description
Forward-Port-Of: odoo/odoo#172070
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#172193 Forward-Port-Of: odoo/odoo#171244
Original PR description
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#172193 Forward-Port-Of: odoo/odoo#171244
Steps to reproduce the bug: - Create a storable product “P1”: - Create a reorder rule: - Min qty: 5 - Route: Buy - Click the “To order” button Problem: The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time. opw-3994600 Forward-Port-Of: odoo/odoo#171968
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a reorder rule:
- Min qty: 5
- Route: Buy
- Click the “To order” button
Problem:
The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time.
opw-3994600
Forward-Port-Of: odoo/odoo#171968Forward-Port-Of: odoo/odoo#172203
Original PR description
Forward-Port-Of: odoo/odoo#172203
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased produ
Original PR description
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased products 4. Enable Storage Locations in Settings > Inventory 5. Navigate to one of the product variants and click on the On Hand smart button 6. Observe that it shows the on hand quantity for both product variants opw-3988374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171306
When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commi
Original PR description
When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commit adds such attributes. This is similar to what was done on 9764e6f7 for the command palette to handle search results on the home screen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170291 Forward-Port-Of: odoo/odoo#165903
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001
Original PR description
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172167 Forward-Port-Of: odoo/odoo#170130
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utiliz
Original PR description
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utilization before PR -->  Reference flamegraph --> https://drive.google.com/file/d/1ptI8mOfvaACFmuwIEiN5f0rFRueu9h46/view?usp=drive_link After PR -->  Reference flamgraph --> https://drive.google.com/file/d/1dcaLz3jrDmkX96WagAylkL1V--dz9jNQ/view?usp=drive_link opw-3957975 Forward-Port-Of: odoo/odoo#171122
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All
Original PR description
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All users" - Set "Customer Account" to "Free sign up" - In a clean session (private browsing), try to sign up an account Old behavior: 403 error New behavior: 2FA page opw-3968129 Forward-Port-Of: odoo/odoo#169594
20 changes
Enhancements to existing features
The rental demo data now presents the meeting room quotation template as "Rent Rooms" and includes a printer as an optional add-on. This makes the sample rental flow clearer and better demonstrates upsell options for rental quotations.
Original PR description
1) Rename 'Meeting room' quotation template to 'Rent Rooms' 2) Add printer as an optional product to the quotation template
Bank statement validation now records a clearer message confirming validation and summarizing the affected accounts and amounts. Resetting a statement line also logs that it was returned to draft, making audit history easier to follow without overly long messages.
Original PR description
At validation, drop a message that indicates the statement line has been validated and summarizes all accounts and amounts in the journal entry. Aggregated the changes of all lines over the accounts to avoid very long validation messages in chatter so we have only, the account and the corresponding amount change. At resetting, drop a message to indicate that the statement line has been reset to Draft. task-3997721
The payslip form layout has been adjusted so the pay period appears below the payroll structure. This creates a more natural flow for payroll users when reviewing or entering payslip information.
Original PR description
This commit reposition the perdiod for the payslips to below the structure to make it more inline with a normal flow task-4004624
Enterprise apps now align with a platform update that shares more information about available views during a user session. This supports consistent behavior across Helpdesk and advanced reporting or planning views such as cohort, gantt, grid, and map.
Original PR description
We adapt the code in enterprise to the changes brought by https://github.com/odoo/odoo/pull/171919
Resolved issues and error corrections
This fixes an error that could occur when an employee was assigned to a preparation display order in Point of Sale. It helps keep kitchen preparation workflows stable and avoids interruptions during order handling.
Original PR description
Fix traceback when assigning employee_id to pdis order. taskId: 4037944
Code cleanup and technical improvements
Odoo removes an unused manual setup flow for XML validation files and moves validation into automated nightly tests. This reduces user-facing configuration while still checking that generated accounting, payroll, banking, and localization XML documents meet required external formats.
Original PR description
Problem --------- In times immemorial, XSD checks were added to Odoo, so that when we generate an XML file to be sent to a service, we validate it using the corresponding XSD before sending it. At…
Problem --------- In times immemorial, XSD checks were added to Odoo, so that when we generate an XML file to be sent to a service, we validate it using the corresponding XSD before sending it. At the request of the infra team, which was concerned that we were downloading XSDs again and again on new databases when people tried generating XMLs for the first time, this framework was refactored in 16.0 in the following task. This no longer made the download of XSDs automatic, but made it possible through a button in the settings in debug mode. Which means that 99% of users never use it. Objective --------- 1. Remove the whole 'XSD framework' 2. Instead, add nightly (l10n_external) tests that try to generate the XMLs, download the XSD and try to validate the XMLs using the XSDs. Solution --------- Remove all occurances of `action_download_xsd_files` et al. Instead, we now have a decorator `test_xsd`. 1. place the decorator on test functions 2. use either take a URL or path to an XSD file as argument 3. make sure the decorated method returns the XML to test for 4. make sure your test as the exernal tag if using a URL Upon running the test, the decorated method will run test the XML against the specified XSD. odoo/odoo/pull/171593 task-3619697
Message-related data is now sent in a flatter, simpler format, reducing repeated information when the same contact appears across multiple messages. This should lower data transfer and browser processing, helping messaging features in Knowledge, WhatsApp, and VoIP feel more efficient without changing user workflows.
Original PR description
This will reduce data transferred to the client and processed in JS when the same persona was appearing in multiple messages. This also makes more clear what is transferred by avoiding nested values. This is part 5, focusing on message and persona in message. Formatting code eventually becomes simpler too, by always adding data to the store rather than updating pre-existing dict manually. Part of task-3605717 https://github.com/odoo/odoo/pull/171585
Miscellaneous changes
[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838) Forward-Port-Of: odoo/enterprise#66202
Original PR description
[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838) Forward-Port-Of: odoo/enterprise#66202
Steps to reproduce ================== - Open "Documents" app - Select any workspace - Click dropdown next to "Upload" - Select "Share" - Select "Download and Upload" from the "Allows to" radio buttons - Select "Share" Solution ======== Use the same solution as - https://github.com/odoo/enterprise/commit/f3320efad924623ea553847538c6244459a734d5 - https://github.com/odoo/enterprise/commit/2c6716e7f619423414b615015bf86fbd11256953 - https://github.com/odoo/enterprise/commit/2820
Original PR description
Steps to reproduce ================== - Open "Documents" app - Select any workspace - Click dropdown next to "Upload" - Select "Share" - Select "Download and Upload" from the "Allows to" radio buttons - Select "Share" Solution ======== Use the same solution as - https://github.com/odoo/enterprise/commit/f3320efad924623ea553847538c6244459a734d5 - https://github.com/odoo/enterprise/commit/2c6716e7f619423414b615015bf86fbd11256953 - https://github.com/odoo/enterprise/commit/2820230bf722d602540943ff9f17bd72e991bea9 opw-3990839 Forward-Port-Of: odoo/enterprise#66011 Forward-Port-Of: odoo/enterprise#65207
Since commit [1], the NavBar actually removes the parts/buttons specific to small/desktop-like screens instead of hidding them with responsive classes. This commit adapts also the HomeMenu toggle icon's breakpoint to match `isSmall`, avoiding a ugly overlap between `md` and `lg` breakpoints. Steps to reproduce: - open an app with a resolution > 992px - resize the viewport below 992px => the app's icon and HomeMnu one are overlapping opw-4033259 [1]: odoo/enterprise@a586702247e5dbe3
Original PR description
Since commit [1], the NavBar actually removes the parts/buttons specific to small/desktop-like screens instead of hidding them with responsive classes. This commit adapts also the HomeMenu toggle icon's breakpoint to match `isSmall`, avoiding a ugly overlap between `md` and `lg` breakpoints. Steps to reproduce: - open an app with a resolution > 992px - resize the viewport below 992px => the app's icon and HomeMnu one are overlapping opw-4033259 [1]: odoo/enterprise@a586702247e5dbe3690377d19cc84f7ab54e77ee Forward-Port-Of: odoo/enterprise#66219
This commit fixes an issue with the Knowledge form view that loses its navbar when you reload an article's page. This issue is caused by the lack of a path inside the ir.actions.server `ir_actions_server_knowledge_home_page` which is the action called when opening the app. This field was set on the action calling the form view `knowledge_article_action_form` but it's not the one called when refreshing the browser. task-3874849 Forward-Port-Of: odoo/enterprise#65642 Forward-Port-Of:
Original PR description
This commit fixes an issue with the Knowledge form view that loses its navbar when you reload an article's page. This issue is caused by the lack of a path inside the ir.actions.server `ir_actions_server_knowledge_home_page` which is the action called when opening the app. This field was set on the action calling the form view `knowledge_article_action_form` but it's not the one called when refreshing the browser. task-3874849 Forward-Port-Of: odoo/enterprise#65642 Forward-Port-Of: odoo/enterprise#62509
**Version:** - saas-16.3 **Step to reproduce:** - In the sign app, open the sign template iframe view. - When zooming in, the 'Sign Now' button breaks the text and creates extra space in the breadcrumb. **Issue:** Currently, the sign now button text creates extra spacing. **Solution:** Add the CSS class so that it will not create additional spacing task-3977792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - In the sign app, open the sign template iframe view. - When zooming in, the 'Sign Now' button breaks the text and creates extra space in the breadcrumb. **Issue:** Currently, the sign now button text creates extra spacing. **Solution:** Add the CSS class so that it will not create additional spacing task-3977792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#64648
In the tour adaptation it seems a step has been removed which is very essential for the feature "Copy Previous Week". In sense tour fails when the user doesn't have any data(highly likely for an onboarding user). So the step is added to change the week. task-3997374 Forward-Port-Of: odoo/enterprise#64955
Original PR description
In the tour adaptation it seems a step has been removed which is very essential for the feature "Copy Previous Week". In sense tour fails when the user doesn't have any data(highly likely for an onboarding user). So the step is added to change the week. task-3997374 Forward-Port-Of: odoo/enterprise#64955
Steps to reproduce: ------------------- 1. Set the user with 'project > user' access rights level and nothing else. Remove every rights that are related to account/analytic accounting from the user (see record rules, access rights, groups, ...). 2. When opening the Project app, an Access Error occurs (related to 'account.analytic.line'). Fix: ------------------- The progress bar that appears when grouping tasks by project in the gantt view should be able to display the sum of the timeshe
Original PR description
Steps to reproduce: ------------------- 1. Set the user with 'project > user' access rights level and nothing else. Remove every rights that are related to account/analytic accounting from the user (see record rules, access rights, groups, ...). 2. When opening the Project app, an Access Error occurs (related to 'account.analytic.line'). Fix: ------------------- The progress bar that appears when grouping tasks by project in the gantt view should be able to display the sum of the timesheets amount per project even if the user has no access to 'account.analytic.line'. task-3973256 Forward-Port-Of: odoo/enterprise#65873 Forward-Port-Of: odoo/enterprise#63922
Currently, it is impossible to duplicate a recurring shift, because the "Edit Recurring Shift" modal opens instead. This PR fixes it by preventing this modal from opening and copying the shift as it should. The problem is that the "dragPillDrop" method will open the modal if the shift is recurring, no matter if you are trying to copy it or not. To fix it, a condition was added to check if the shift is being copied or not, and if so, it won't open the modal. task-3978527 Forward-Port-Of: o
Original PR description
Currently, it is impossible to duplicate a recurring shift, because the "Edit Recurring Shift" modal opens instead. This PR fixes it by preventing this modal from opening and copying the shift as it should. The problem is that the "dragPillDrop" method will open the modal if the shift is recurring, no matter if you are trying to copy it or not. To fix it, a condition was added to check if the shift is being copied or not, and if so, it won't open the modal. task-3978527 Forward-Port-Of: odoo/enterprise#65881
Steps: -------- - Install Field Service module - Now, go to the field service's configuration - Click on Time and Material invoicing - Make the new Task - Add products - Now in internal user, give users access right level > sale: own document only - Now login as a user who has user access right level - After login, go to field service module - Open that task in which sale order automatically generated, access error comes Issue: ------- - An user who has user access rights level tr
Original PR description
Steps: -------- - Install Field Service module - Now, go to the field service's configuration - Click on Time and Material invoicing - Make the new Task - Add products - Now in internal user, give…
Steps: -------- - Install Field Service module - Now, go to the field service's configuration - Click on Time and Material invoicing - Make the new Task - Add products - Now in internal user, give users access right level > sale: own document only - Now login as a user who has user access right level - After login, go to field service module - Open that task in which sale order automatically generated, access error comes Issue: ------- - An user who has user access rights level trying to read other user sale order. Cause: --------- - In this **PR enterprise-31363** added a new field pricelist_id on model project.task.This field is computed in _compute_currency_id.However user have no access to read record, therefore raises an access error for internal user. Fix: ----- - A sudo is used in method _compute_currency_id to be able to open the task but can not see sale order stat button. task-3610485 Forward-Port-Of: odoo/enterprise#66098 Forward-Port-Of: odoo/enterprise#52677
Steps to reproduce: - set a customer with Belgian VAT and check one with German VAT - Create sales: * one for the Belgian company using the 0% EU sale taxe * another for the German company using the 0% tax for construction (provider §13b) - Go To Statement Reports > EC Sales List Issue: Only the invoice for the Belgian company should appear in the report EC Sales 60 tag should not be present only tags in (41, 42, 21) source: https://apps.datev.de/help-center/documents/1017530 op
Original PR description
Steps to reproduce: - set a customer with Belgian VAT and check one with German VAT - Create sales: * one for the Belgian company using the 0% EU sale taxe * another for the German company using the 0% tax for construction (provider §13b) - Go To Statement Reports > EC Sales List Issue: Only the invoice for the Belgian company should appear in the report EC Sales 60 tag should not be present only tags in (41, 42, 21) source: https://apps.datev.de/help-center/documents/1017530 opw-3923031 Forward-Port-Of: odoo/enterprise#65958 Forward-Port-Of: odoo/enterprise#65098
When we are loading an offer in the salary configurator, if values are set to a benefit that depends on another one which is disabled. You are keeping the value of the contract, and it is not disabled as it should because the mandatory benefit is not set. We've got this issue because the variable in the loop has the same name as the one we really need declared before ('mandatoryBenefitSelected'). We also remove the loop and the split, as it is already done in the function 'updateDependentB
Original PR description
When we are loading an offer in the salary configurator, if values are set to a benefit that depends on another one which is disabled. You are keeping the value of the contract, and it is not disabled as it should because the mandatory benefit is not set.
We've got this issue because the variable in the loop has the same name as the one we really need declared before ('mandatoryBenefitSelected').
We also remove the loop and the split, as it is already done in the function 'updateDependentBenefits' that is called.
TASK-ID: NONE
Forward-Port-Of: odoo/enterprise#66124**Current behavior:** Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality check to end up in the failure location. **Expected behavior:** A product created in a manufacturing order can fail a quality check and end up in the designated failure location in WH. **Steps to reproduce:** 1. Set up a quality point on some storable product on manufacturing operations with:
Original PR description
**Current behavior:** Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality…
**Current behavior:**
Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality check to end up in the failure location.
**Expected behavior:**
A product created in a manufacturing order can fail a quality check and end up in the designated failure location in WH.
**Steps to reproduce:**
1. Set up a quality point on some storable product on manufacturing operations with:
`Control per: Quantity`
`Type: Pass - Fail`
`Failure Location: Some internal location`
3. Create a new MO with the quality controlled product and confirm it
4. Click the Quality Checks button, fail the check (make sure to select the faiure location here)
5. After the Quality Check, click Produce All -> Observe that the full quantity of products produced by the MO still was moved to whatever the default Stock location is, not the failure location specified.
**Cause of the issue:**
The method `_move_line_to_failure_location()` expects a picking and SML to exist, however when the quality check starts from an MO, we have neither (contrasted with a check starting from a picking). So the method just skips the logic where the re-route would occur.
**Fix:**
Override the method in the mrp_quality bridge module, if the quality check has a production_id then create the SML on the spot via `MrpProduction.action_confirm()`, then go through the same logic to split the created line as necessary based on the failed quantity vs. total quantity of the MO.
opw-3865301
Forward-Port-Of: odoo/enterprise#62731### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and confirm an MO using that bom - Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product #### > Invalid Operation: You should provide a lot/serial number for the final product ### Expected behavior: You should be able
Original PR description
### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and…
### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and confirm an MO using that bom - Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product #### > Invalid Operation: You should provide a lot/serial number for the final product ### Expected behavior: You should be able to validate the operations of the MO without assigning an SN but you should not be able to mark the MO as done without assigning the SN to the final product. Note: if no component were consumed in an operation, the invalid operation would not be raised. ### Cause of the Issue: The invalid operation is raised because of these lines: https://github.com/odoo/enterprise/blob/1b0435a92492d85f28549a207fcdb7224b457c66/mrp_workorder/models/mrp_workorder.py#L433-L434 However, the existence of "self.move_raw_ids" only indicates that a component has to be consumed in this opration rather than the existence of a move requiring a the SN of the final product to be set. ## opw-3987022 Forward-Port-Of: odoo/enterprise#66058 Forward-Port-Of: odoo/enterprise#65075
1 change
Resolved issues and error corrections
This update corrects how expense accounts are classified in Danish financial reports. The "Purchase of goods" account was reclassified from a general expense to a direct cost category, which ensures the test data accurately reflects the proper account ordering in reports. This fix ensures Danish compliance reporting works correctly.
Original PR description
[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838)