Wednesday, October 23, 2024
36 changes · saas-17.4
Resolved issues and error corrections
The CRM onboarding tour has been corrected so users can complete the guided setup as expected. This helps new CRM users get started more smoothly and reduces confusion during onboarding.
Original PR description
Fixed onboarding CRM tour which is not working properly. Task-4210376
Inbox notifications created from the chatter will now update the unread counter without acting like live chat messages. This prevents unnecessary sounds, pop-up chat bubbles, and duplicate notifications, reducing distractions for users.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/182347 PR above improved out-of-focus counter, one of such improvements is to take new inbox messages into account. However, doing so had to unintended side-effect to make them play sound, open chat bubble, and display more than 1 notification. This happens because the inbox notification were treated like new message in chat notifications. This commit fixes the issue by limiting PR above of inbox new messages to contribute for the out-of-focus counter. In other words, the following behaviors have been fixed: - new inbox messages from chatter no longer open a chat bubble - new inbox messages from chatter no longer play sound - new inbox messages from chatter only show 1 notification at most
The DIN 5008 invoice layout now adds colons after key field labels on generated invoices, matching the document preview. This improves consistency and readability for customers using Austrian localization with the DIN 5008 format.
Original PR description
Added colons (:) after field labels in the invoice template for better consistency and improved readability. Steps to reproduce: -> Have the Austria localization modules installed -> Set the invoice document to DIN 5008 -> Notice in the preview on the top right corner the Colon ':' is next to the invoice number and others below -> When creating an invoice from an SO and viewing the invoice the Colons ':' are not there opw-4245658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale SMS receipts now use the customer's mobile number instead of the general phone field. This reduces the chance of messages being sent to the wrong or less suitable contact number.
Original PR description
Prior to this commit, the phone field was used to send SMS, which could be incorrect. Enterprise PR: https://github.com/odoo/enterprise/pull/72449 opw-4273085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue where two language indicators could appear at the same time on certain view translation controls. The change keeps the interface clearer for users working with translations and avoids confusing duplicate labels.
Original PR description
after odoo/odoo#169782 translation button is only rendered when hover/focus but for the hack of ir.ui.view.arch which 1. is a not translatable computed field 2. borrows the translation button from ir.ui.view.arch_db 3. shows the en_US value of ir.ui.view.arch_db. The 'visibility: visible !important' in odoo/odoo#169782 when hover/focus make the dummy EN logo and the language logo for the current language appear at the same time e.g. FREN This FIX increases the specificity of 'visibility: hidden' of the language logo for the current language in oe_no_translation_content to remove the bug. 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
When a signer cancels a document request from an email link, Odoo now records that signer on the cancellation activity log. This keeps the audit trail complete and makes it easier for businesses to see who cancelled a signing request.
Original PR description
**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the creation. task-4213637
WhatsApp messages from Point of Sale receipts now use the customer's mobile number instead of the general phone field. This reduces the chance of messages being sent to the wrong or unusable number, improving customer communication reliability.
Original PR description
Prior to this commit, the phone field was used to send WhatsApp messages, which could be incorrect. Community PR: https://github.com/odoo/odoo/pull/184660 opw-4273085
This fix adjusts spacing in the salary contract form so labels no longer overlap or block nearby input fields. Users can now click and edit the affected fields more reliably, reducing small but frustrating form-entry issues.
Original PR description
The span padding is taking too much place and prevent to click on the input above. So we set the correct class to avoid issues.
Miscellaneous changes
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of:
Original PR description
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of: odoo/odoo#184845
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
Original PR description
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product
Original PR description
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost…
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product Type Route = Manufacturing Category = AVCO or FIFO 2.) Create Product B: Storable Product Type Routes = Buy Category = AVCO or FIFO 3.) Make a BOM Product A Quantity = 1 Kit Components: 12 units of Product B 4.) Create a Purchase Order: Buy 1 unit of Product A at $100 5.) Confirm PO -> this will generate a receipt 6.) Validate receipt 7.) Note the valuation is 12 units @ a value of 99.96 where it should be 100 Current behavior before PR: svl.value = 99.96 Desired behavior after PR is merged: svl.value = 100 opw-4208554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184737 Forward-Port-Of: odoo/odoo#183267
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-410782
Original PR description
On chrome mobile, when going in the pos self order and trying to do a search on the products you would get a traceback. This was happening because jQuery was not defined. Steps to reproduce: ------------------- * Install pos_self_order and barcodes * Open the PoS on a chrome mobile device (use browserstack) * Try to do a search on the products page > Observation: You get a traceback Why the fix: ------------ jQuery is not always defined, so we remove the use of jQuery. opw-4107823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180163
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184692 Forward-Port-Of: odoo/odoo#184584
Original PR description
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184692 Forward-Port-Of: odoo/odoo#184584
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba">
Original PR description
Updated the label for `total_amount` to display `Total` when the expense is not in multiple currencies and the product has a cost, and to show an empty label in the other previously considered cases. This change ensures that the label is displayed correctly without repetitions or omissions in the relevant scenarios. Current behavior before PR: <img width="438" alt="Screenshot 2024-10-10 at 11 05 52 PM" src="https://github.com/user-attachments/assets/af93e767-bc0f-487b-bb35-49ad4602f0ba"> Desired behavior after PR is merged: <img width="450" alt="Screenshot 2024-10-10 at 11 04 51 PM" src="https://github.com/user-attachments/assets/40f531a8-0d79-4eb6-a3d6-cd80abcb145c"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183280
In this commit, we changed the way the addresses were displayed in accounting. https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e We now want the same behavior with the sale orders. task-3951205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166877
Original PR description
In this commit, we changed the way the addresses were displayed in accounting. https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e We now want the same behavior with the sale orders. task-3951205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166877
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Original PR description
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in. Forward-Port-Of: odoo/odoo#176962
Have a parent company [PARENT] Create an invoice [INV1] Create a branch company [BRANCH] Create an invoice [INV2] for [BRANCH] company Go to invoice list view Select both companies Select both invoices Click 'Register Payment' Traceback ``` File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches return self.browse(self.__accessible_branches()) File "<decorator-gen-107>", line 2, in __accessible_branches File "[...]/odoo/tools/cache.py", lin
Original PR description
Have a parent company [PARENT]
Create an invoice [INV1]
Create a branch company [BRANCH]
Create an invoice [INV2] for [BRANCH] company
Go to invoice list view
Select both companies
Select both invoices
Click 'Register Payment'
Traceback
```
File "[...]/odoo/addons/base/models/res_company.py", line 405, in _accessible_branches
return self.browse(self.__accessible_branches())
File "<decorator-gen-107>", line 2, in __accessible_branches
File "[...]/odoo/tools/cache.py", line 97, in lookup
key = key0 + self.key(*args, **kwargs)
File "<string>", line 1, in <lambda>
File "[...]/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.company(2, 1)
```
opw-4027692
Forward-Port-Of: odoo/odoo#172792Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when us
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be…
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Outlook, it will be correctly synchronized in Outlook as well. This approach will also reduce the possibility of duplicated events in Odoo side (and by transitivity, in Outlook side). task-4261237 Forward-Port-Of: odoo/odoo#183926
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , java
Original PR description
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed…
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , javascript will create it at time 00:00 in the UTC timezone, so for users with negative timezone offset (GMT-x), `formatDate` will print the the date as one day behind. It’s the case for American users for instance. Now, we create the date using `DateTime.fromISO(yyyy-mm-dd)`, it will be created at 00:00 in the local time zone (not the UTC timezone anymore), and printing it with `formatDate` will therefore yield the correct value expected by the user. opw-4116982 Forward-Port-Of: odoo/odoo#184178 Forward-Port-Of: odoo/odoo#182933
Steps --- * install `mrp`, `purchase` * create the following products: * P, storable, route = manucfature, bom: * C storable (qty = 1) * K storable, (qty = 1) kit bom: * C (qty = 1) * set the quantiy on hand for C to 1 * create a purchase order for 20 C * create an MO for 5 P > *Confirm* * in the overview we have 2 component line (each for C), but the 2nd line's status is *To Order* even though we already have a PO. if we look at the d
Original PR description
Steps
---
* install `mrp`, `purchase`
* create the following products:
* P, storable, route = manucfature, bom:
* C storable (qty = 1)
* K storable, (qty = 1) kit bom:
* C (qty = 1)
* set the quantiy on hand for C to 1
* create a purchase order for 20 C
* create an MO for 5 P > *Confirm*
* in the overview we have 2 component line (each for C), but the 2nd
line's status is *To Order* even though we already have a PO.
if we look at the details of the first line, we can see the replenishment
for the second line was wrongly assigned to the first.
Cause
---
When matching replenishments to bom line moves, we check if quantity
from the replenishments is enough for the move, if so we go on to the
next move. But when we do this we do not account for pre-reserved
quantity of partially available moves.
opw-4128775
Forward-Port-Of: odoo/odoo#178261Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetche
Original PR description
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical"…
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetched (no fetching of unnecessary emails) * Email are marked as read after processing and NOT deleted Drawbacks of POP protocol that most end users are not necessarily aware of: * After fetching emails are deleted on the fetched mail server, i.e. no hard copy of the original mail is kept which might be an issue if a bug in Odoo fetches the mail "correctly" (routing succeeded), but a downstream bug creates side effects (attachments deleted, wrong record creted) * Since POP will try to fetch ALL mails in the inbox, if the customer (un)purposely hoards Odoo unrelated emails, these will be always fetched but never routed -> time spend for nothing routing, logs are spammed and percieved delay for fetching new emails (since older ones are processed for nothing over and over again) Proposed solution: Change `default` parameter to `imap` argument. Will not change old records ad-hoc, but preset new incoming email servers. User is free to still change the server type if they feel the need to use the POP protocol. Recent support tickets with related issues: OPW-4206157 OPW-4229682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183712
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`.
Original PR description
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the…
__Current behavior before commit:__ Since [this PR][1], the search box is inside a `t-nocache` to prevent the searched text from being cached. Now however, variables created with `t-set` outside the `t-nocache` are no longer accessible inside it. Therefore when searching from the header search box, many attributes that utilize the value of `search_type`, `_classes`, `display_description`, etc. are not put inside the searchbox `<input>` because those variables are assigned with `t-set`. __Description of the fix:__ The `t-nocache` is put directly inside the header templates in order for all subsequent `t-set` to be accessible from its scope. __Example of steps to reproduce the issue on runbot:__ 1. On the website, click on the search button inside the header 2. Type "desk" for example No results are shown below the search box although when hitting ENTER, there are some results. This is due to the fact that the searchbox input lacks the `search_type="all"` attribute. opw-4246129 [1]: https://github.com/odoo/odoo/pull/180548 Forward-Port-Of: odoo/odoo#183465
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
Original PR description
Before this commit: The TDS amount in the wizard was editable, so users were able to change it manually. After this commit: The TDS amount in the wizard is now read-only and can’t be changed, since it’s calculated based on the base amount and TDS tax. Forward-Port-Of: odoo/odoo#184546
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archIn
Original PR description
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archInfo.activeActions.edit === true` opw-4272416 Forward-Port-Of: odoo/enterprise#72516
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72522 Forward-Port-Of: odoo/enterprise#72468
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
Original PR description
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399 Forward-Port-Of: odoo/enterprise#72032
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#69948
Original PR description
Harmonize 'phone' field, normalize email usage Task-4154838 Forward-Port-Of: odoo/enterprise#69948
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#71851
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules. Forward-Port-Of: odoo/enterprise#72410 Forward-Port-Of: odoo/enterprise#71691
Original PR description
Remove the default stages before assigning new stages to the demo project. This update prevents the removal of stages that are being used in other projects, thereby avoiding conflicts with demo data from other modules. Forward-Port-Of: odoo/enterprise#72410 Forward-Port-Of: odoo/enterprise#71691
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72534
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of th
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_timesheet_enterprise. - Select Billing Rate Target and then Billing Rate Leaderboard in settings. - Click on 'Set employee billing time targets'. - Open Mitchell Admin form view and set the value of the Billing Time Target to 150 in the HR Setting tab. - Open 'my timesheet'. - Open the leaderboard, on the right-hand side. - Notice that 'x/150' is displayed for Mitchell admin. - Open Mitchell Admin employee form view. - Set the value of the Billing Time Target to 100. - Again open the leaderboard in the timesheet. ### Issue 'x/' is displayed without the new target value. ### Cause Due to the wrong regular expression for the value. ### Solution Correct the regular expression. task-3970348 Forward-Port-Of: odoo/enterprise#66825
Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72260
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule. Forward-Port-Of: odoo/enterprise#72481
Original PR description
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule. Forward-Port-Of: odoo/enterprise#72481
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling
Original PR description
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications. Forward-Port-Of: odoo/enterprise#70697
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Original PR description
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Cu
Original PR description
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration. i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount. opw-4081350 Forward-Port-Of: odoo/enterprise#72406 Forward-Port-Of: odoo/enterprise#72192