Friday, March 29, 2024
46 changes · saas-17.1
Resolved issues and error corrections
This fix ensures background colors in Odoo email templates display correctly even when the Website app is not installed. It prevents parts of mass mailing templates from appearing transparent, improving visual consistency for recipients.
Original PR description
**Current behavior before PR:** Opening OXP template in mass mailing without installing website there are some background colors that became transparent. This issue is introduced by [1] commit. This issue occurs because the $bg-gradient variable referenced in the commit cannot be included within a file of web_editor. Additionally, it cannot use the o-website-value to retrieve its value. **Desired behavior after PR is merged:** Now it will show the background color of block without website installed. [1]: https://github.com/odoo/odoo/pull/75680/commits/5c4ad451787a1a52824a046c9ae81b0e86a05a3b task-3688383
Fixed a small display issue in the chatter area that showed an extra “on” indicator while users were creating a new record. This keeps the interface cleaner and avoids confusion during record creation.
Original PR description
**Current behavior before PR:** An extra 'on' indicator was incorrectly displayed in chatter while creating a new record, leading to UI display issues. **Desired behavior after PR is merged:** Resolved the issue where the extra 'on' indicator was not properly displayed during new record creation. Task-3826569 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant table appointments that end after midnight now appear correctly on the following day. When an appointment started the previous day, its displayed start time is adjusted to the start of the current day to avoid confusing staff.
Original PR description
Before this commit, if the end of a table appointment was ending the day after the start day, the appointment wouldn't be displayed. Fixing this, a new issue arises, if an appointment start the day before, showing it next day will create confusion since it will display the starting time of the previous day. To fix this we simply set the starting time to the start of the day.
The appointment test setup now specifies a timezone directly when demo data is unavailable. This prevents test failures caused by users without a saved timezone, improving reliability for quality checks.
Original PR description
With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. runbot-55570 runbot-55571 runbot-55572 runbot-55573 runbot-55574
Miscellaneous changes
## Description Adding missing indexes to support most of the searches on survey's models to avoid seq.scans and non-selective index scans. Also adding indexes that are inverse to One2many, or dependencies of compute fields (as those if not indexes will trigger a seq.scan when the ORM resolves the dependency tree). If a domain had multiple criteria, only fields with the highest selectivity were indexed. This shall also reduce the amount of tuples returned, reducing IO access and cache trashing.
Original PR description
## Description Adding missing indexes to support most of the searches on survey's models to avoid seq.scans and non-selective index scans. Also adding indexes that are inverse to One2many, or dependencies of compute fields (as those if not indexes will trigger a seq.scan when the ORM resolves the dependency tree). If a domain had multiple criteria, only fields with the highest selectivity were indexed. This shall also reduce the amount of tuples returned, reducing IO access and cache trashing. ## Cardinality survey_survey -> X (reference quantity) survey_question -> 10X survey_question_answer -> 50X survey_user_input -> 330X survey_user_input_line -> 7200X ## Reference task-3724844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158136
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being created / uniqueness constraint issues on journal codes. The matching happens in `_pre_reload_data`. This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid. The problem was introduced in commit d6695f2892ded178371f6c69cf594037
Original PR description
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being…
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name).
This then leads to duplicate journals being created / uniqueness constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
- (1) We load the chart data in en_US to be able to use the code translations
- (2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2); Code is not translatable.
- We compare those values (journal code / name) against the en_US term due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version) against the translated values.
Forward-Port-Of: odoo/odoo#159738
Forward-Port-Of: odoo/odoo#159635Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized the current user, further prioritize based on companies matching the records passed to `_mail_find_partner_from_email`, avoiding potential access rights errors in multi-company environments. opw-3705199 Forward-Port-Of: odoo/odoo#159108 Forward-Port-Of: odoo/odoo#156158
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159652 Forward-Port-Of: odoo/odoo#157026
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159652 Forward-Port-Of: odoo/odoo#157026
Before this commit, the custom attribute names were not correctly displayed when added to an order. opw-3795843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158805
Original PR description
Before this commit, the custom attribute names were not correctly displayed when added to an order. opw-3795843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158805
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the iss
Original PR description
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the issue / fix: This part of the report is displayed under a `t-elif` condition. However for internal trasnfers the condition of the `t-if` and of the `t-elif` are both `true` so that two `t-if` should be used for an appropriate display of the report. ### Note: Prior to commit 567b8d6, two `t-if` were used. opw-3797998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158852
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159769 Forward-Port-Of: odoo/odoo#159320
Original PR description
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159769 Forward-Port-Of: odoo/odoo#159320
*: stock Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 Forward-Port-Of: odoo/odoo#158844
Original PR description
*: stock Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 Forward-Port-Of: odoo/odoo#158844
Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
Original PR description
Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
Addresses the issue where reapplying an already applied coupon in the website shop led to the disappearance of the discount. With this fix, the discount remains applied, and the system continues to inform the user that the coupon has already been used, preventing confusion and maintaining consistency in the discount application process. task-3621246 Forward-Port-Of: odoo/odoo#153485
Original PR description
Addresses the issue where reapplying an already applied coupon in the website shop led to the disappearance of the discount. With this fix, the discount remains applied, and the system continues to inform the user that the coupon has already been used, preventing confusion and maintaining consistency in the discount application process. task-3621246 Forward-Port-Of: odoo/odoo#153485
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted. This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py". Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behavior
Original PR description
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted. This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py". Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behaviors. The goal here is to delete all the old drivers and interfaces before downloading the new ones to make sure we don't have this issus task-3729890 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159538 Forward-Port-Of: odoo/odoo#158412
Forward-Port-Of: odoo/odoo#159621
Original PR description
Forward-Port-Of: odoo/odoo#159621
Test 'test_unpack_and_quants_history' may fail with error ``` ERROR: StockQuant.test_unpack_and_quants_history Traceback (most recent call last): File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history dst_location = stock_location.child_ids[0] File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__ return self.browse((self._ids[key],)) IndexError: tuple index out of range ``` Forward-Port-Of: odoo/odoo#159611
Original PR description
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
Forward-Port-Of: odoo/odoo#159611Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
Original PR description
Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a modification of the HTML structure for date(time) input fields. Consequently, a bug emerged in the visibility options for fields reliant on a date(time) field. Specifically, the time condition selector failed to display the time conditions because they are rendered based on the HTML struc
Original PR description
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a…
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a modification of the HTML structure for date(time) input fields. Consequently, a bug emerged in the visibility options for fields reliant on a date(time) field. Specifically, the time condition selector failed to display the time conditions because they are rendered based on the HTML structure of the fields. Since the code was not adjusted to fit the new structure, this functionality stopped functioning. [1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 task-3790809 ---------------------------------------------- **[FIX] website: fix traceback with website form date(time) fields** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. A traceback appears when loading a website form containing a field dependent on a date(time) field. This traceback occurs because when checking the value of an empty date(time) field (which happens when the user hasn't yet filled out the form), we parse the field value into a Date(Time). Before the changes in commit [1], we parsed this differently, which didn't crash but returned "NaN" with an empty date(time) field. In this commit, we now check whether a date(time) is valid and if not, we now assign it "NaN" to maintain exactly the same behaviour as before the commit [1]. Any value other than "NaN" would not work with the date comparison system and would break certain conditions. This commit also adds steps to the "website_form_editor" test tour so that it fails without this commit. [1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 task-3790809 Forward-Port-Of: odoo/odoo#158288
Current behavior before PR: - Unable to save subtasks when adding a project. - Traceback occurs when creating a new task from the subtask kanban view in project sharing. Desired behavior after PR is merged: - Enable successful saving of subtasks after adding a project. - Resolve traceback issue during new task creation in project sharing, ensuring correct task creation without traceback. task-3584963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Current behavior before PR: - Unable to save subtasks when adding a project. - Traceback occurs when creating a new task from the subtask kanban view in project sharing. Desired behavior after PR is merged: - Enable successful saving of subtasks after adding a project. - Resolve traceback issue during new task creation in project sharing, ensuring correct task creation without traceback. task-3584963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143282
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numb
Original PR description
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number…
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numbers are skipped if they are the same as the partner's number. [Reproduce] - Install mass_mailing_sms, sale_management, and sale_subscription modules. - Add an SMS token to the IAP account. - Create a contact (C) with a valid phone number. - Create a new quotation with contact (C) as the partner. - Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module). - Do not change the contact number on the pop-up (ensure it matches C's phone number exactly). - Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error. opw-3596207 Forward-Port-Of: odoo/odoo#153429
Description of the issue/feature this PR addresses: Replace the use of 't-esc' with 't-field' for the payment icon image in the icons list template. The latter, for an image field, provides two options for rendering the payment icon image: use the PIL library to obtain the image when given the option 'qweb_img_raw_data', or use a URL. The former only considers the first option, allowing only image formats compatible with the PIL library. Current behavior before PR: Only image formats co
Original PR description
Description of the issue/feature this PR addresses: Replace the use of 't-esc' with 't-field' for the payment icon image in the icons list template. The latter, for an image field, provides two options for rendering the payment icon image: use the PIL library to obtain the image when given the option 'qweb_img_raw_data', or use a URL. The former only considers the first option, allowing only image formats compatible with the PIL library. Current behavior before PR: Only image formats compatible with the PIL library can be used for the payment icons. Desired behavior after PR is merged: Other formats including the ones compatible with the PIL library can be used for the payment icons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159586 Forward-Port-Of: odoo/odoo#158728
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do the certification through the received link - As admin, go to "Employee" and got to "Reporting -> Certifications" - You will see the certification in red under "Marc Demo" This means that the certification is already expired and should not. When completing a certification (survey), a hr_re
Original PR description
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do…
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do the certification through the received link - As admin, go to "Employee" and got to "Reporting -> Certifications" - You will see the certification in red under "Marc Demo" This means that the certification is already expired and should not. When completing a certification (survey), a hr_resume_line is inserted in the database with a start_date and an end_date set to the completion date, causing the certification to be expired right away. We only do "cosmetic" correction here as the real fix will be done in master to avoid multiple upgrade: - to avoid existing certification to be displayed in red in the reporting view, we correct the display (by avoiding adding danger decoration to the line if the date_start equals the date_end). That correction won't avoid to find those certifications as expired as we can't correct the computed field as it is stored. Also, if the expiration_status column is shown (hidden by default), it will display expired on those certifications. - We do a similar correction in the display of the employee resume. Note: the end_date problem is anterior to v17 but the resume line expiration has been introduced in v17. Task-3389395 Forward-Port-Of: odoo/odoo#158047
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156175
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156175
The method `_get_reward_values_free_shipping` assumes there is only one delivery line per sale order. But it is not always the case. This commit therefore makes sure the method does not raise an error in case of multiple lines by taking into account only the first delivery line. Fixes #136395 Forward-Port-Of: odoo/odoo#159584
Original PR description
The method `_get_reward_values_free_shipping` assumes there is only one delivery line per sale order. But it is not always the case. This commit therefore makes sure the method does not raise an error in case of multiple lines by taking into account only the first delivery line. Fixes #136395 Forward-Port-Of: odoo/odoo#159584
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft state, split the quantity into 10 **Problem:** The created MOs have component quantities of 0.1 instead of 1. When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_
Original PR description
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft…
**Steps to Reproduce the Bug:**
- Create a BoM:
- Product: P1, Quantity: 1 unit
- Component:
- C1, Quantity: 1 unit
- Create a MO to produce 10 units of P1:
- This requires 10 units of C1
- In draft state, split the quantity into 10
**Problem:**
The created MOs have component quantities of 0.1 instead of 1.
When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_qty of the MO. Therefore, the move will be updated to 1.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1793
Subsequently, the factor is calculated based on the `move_qty` and the `qty_initial` of the MO.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1828
Factor = 1 / 10 = 0.1
Afterwards, this quantity is set on the original move and the backorder moves:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1830
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1835
opw-3825708
Forward-Port-Of: odoo/odoo#159492Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined
Original PR description
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the…
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined Function: operator does not exist: date <= boolean` * confirm the invoice, ensuring the confirmation and invoice dates have different currency rates. * print the confirmed invoice.* print the invoice You should see that the printed rate does not align with the actual transaction amounts. ### Cause The system incorrectly uses the `l10n_sa_confirmation_datetime` to calculate and display the currency rate on the PDF. This field is only populated upon invoice confirmation, leading to errors when printing unconfirmed invoices. Moreover, using this date for confirmed invoices results in displaying an incorrect rate, as it may differ from the `invoice_date`, which should be used for accurate rate calculations. opw-3731624 Forward-Port-Of: odoo/odoo#156054
This commit's purpose is to display the correct currency for the hourly cost of employee in the project sol mapping. Currently, the currency displayed is the one of the sol instead of the currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c We added a monetary widget, but we are feeding it the wrong id. After this commit, the correct currency is displayed task - 3749225 Forward-Port-Of: odoo/odoo#159588 Forwa
Original PR description
This commit's purpose is to display the correct currency for the hourly cost of employee in the project sol mapping. Currently, the currency displayed is the one of the sol instead of the currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c We added a monetary widget, but we are feeding it the wrong id. After this commit, the correct currency is displayed task - 3749225 Forward-Port-Of: odoo/odoo#159588 Forward-Port-Of: odoo/odoo#154240
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed
Original PR description
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed on the right and expand on the left. (exactly the opposite of ltr direction). Before: ======  After: =====  task-3721794 Forward-Port-Of: odoo/odoo#159468 Forward-Port-Of: odoo/odoo#157400
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". =>
Original PR description
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". => The "Border" option is reset to 0. [1]: https://github.com/odoo/odoo/commit/2a6355c36ebfc4397451289589ebbeaa2afc1396 [2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4 task-3800288 Forward-Port-Of: odoo/odoo#159657 Forward-Port-Of: odoo/odoo#159452
Currently, a logger exception is generated when the user tries to upload any document in the mass mail. Stack trace on sentry: ``` UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70> File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url image = Image.open(io.BytesIO(content)) File "PIL/Image.py", line 3008, in open raise UnidentifiedImageError( ``` This is because an UnidentifiedImageError occurs when the user
Original PR description
Currently, a logger exception is generated when the user tries to upload any document in the mass mail.
Stack trace on sentry:
```
UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70>
File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url
image = Image.open(io.BytesIO(content))
File "PIL/Image.py", line 3008, in open
raise UnidentifiedImageError(
```
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1]-https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
Forward-Port-Of: odoo/odoo#157513**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a document from activity view. This issue arose because the 'activity renderer' tried to display records of all resIds obtained from activity data, including the record of the document currently in preview, which would be deleted already. Thus, leading to the aforementioned traceback. **After this
Original PR description
**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a…
**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a document from activity view. This issue arose because the 'activity renderer' tried to display records of all resIds obtained from activity data, including the record of the document currently in preview, which would be deleted already. Thus, leading to the aforementioned traceback. **After this PR:** The issue has been addressed by updating the behavior of the 'ActivityRenderer' to retrieve and display the updated activity records in order to ensure accuracy. Apart from that, the progress bar was not updated after the docs were deleted. This PR solves that issue by calling the 'load' method of activity model along with the 'rootParams', and then calling the 'notify' method to update the data correctly. Task: [3714544](https://www.odoo.com/web#id=3714544&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#59740 Forward-Port-Of: odoo/enterprise#56357
…when opening journal statements When opening journal, a check is done to update the bank sync state It is not possible to update the state without accounting manager access rights Introducing a skip for non account managers to allow opening the journal. Furthermore, non-managers can't see the online sync anyway so we don't update it until a manager opens the journal. opw-3800147 Forward-Port-Of: odoo/enterprise#59706
Original PR description
…when opening journal statements When opening journal, a check is done to update the bank sync state It is not possible to update the state without accounting manager access rights Introducing a skip for non account managers to allow opening the journal. Furthermore, non-managers can't see the online sync anyway so we don't update it until a manager opens the journal. opw-3800147 Forward-Port-Of: odoo/enterprise#59706
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
Original PR description
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
* With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. * Remove the use of demo data (Mitchell Admin and Joe Willis) for test tour. Forward-Port-Of: odoo/enterprise#59739
Original PR description
* With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. * Remove the use of demo data (Mitchell Admin and Joe Willis) for test tour. Forward-Port-Of: odoo/enterprise#59739
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Config
Original PR description
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Configuration -> Workspaces - Click on the search view dropdown - The filters section still has a filter named 'Archived Workspace' instead of 'Moved to trash' even though it displays trashed workspaces. This PR changes the string of filter from 'Archived Workspace' to 'Moved to trash'. Task: [3787404](https://www.odoo.com/web#id=3787404&cids=2&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#58248
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59625 Forward-Port-Of: odoo/enterprise#58332
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59625 Forward-Port-Of: odoo/enterprise#58332
Before this commit, the test fails since 23 March 2024 because next week the hours changed (summer time). The problem is there if the timezone is not UTC. This commit ensures the whole test uses the same timezone and only UTC one to avoid having to manage summer/winter time in the test. runbot-60932 Forward-Port-Of: odoo/enterprise#59366
Original PR description
Before this commit, the test fails since 23 March 2024 because next week the hours changed (summer time). The problem is there if the timezone is not UTC. This commit ensures the whole test uses the same timezone and only UTC one to avoid having to manage summer/winter time in the test. runbot-60932 Forward-Port-Of: odoo/enterprise#59366
This reverts commit 55cba9f899be0f058834bcd81bd239547c9cebd6. The issue this intended to fix was rooted in the fact that no timesheets were created for public holidays, leading to the remaining hours shown in Timesheets & Planning analysis being wrong. This is no longer an issue starting from version 16.3, timesheets do get created, so any *planned* hours that fall on a holiday get subtracted by the corresponding effective hours from timesheets. opw-3509155 Forward-Port-Of: odoo/enterp
Original PR description
This reverts commit 55cba9f899be0f058834bcd81bd239547c9cebd6. The issue this intended to fix was rooted in the fact that no timesheets were created for public holidays, leading to the remaining hours shown in Timesheets & Planning analysis being wrong. This is no longer an issue starting from version 16.3, timesheets do get created, so any *planned* hours that fall on a holiday get subtracted by the corresponding effective hours from timesheets. opw-3509155 Forward-Port-Of: odoo/enterprise#59645
Steps to reproduce: - Set up DHL shipping - Create Sale order add dhl shipping and validate the delivery Fix: set the correct shipper and receiver referrence opw-3775347 Forward-Port-Of: odoo/enterprise#59627
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order add dhl shipping and validate the delivery Fix: set the correct shipper and receiver referrence opw-3775347 Forward-Port-Of: odoo/enterprise#59627
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()
Original PR description
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()` in the bank reconciliation widget, resulting in a traceback Removing the HTML tags after the call to `read()` in the transient model allows the field to be correctly decoded. opw-3783078 opw-3773454 opw-3772561 and more. Forward-Port-Of: odoo/enterprise#58505
We now group the gantt view by resource_ids to manage appointment type where multiple resources can be chosen for the booking. It is now possible to manage appointment types of restaurant type (aka with manage capacity and multi resources). The field appointment_resource_id on the calendar event is removed as no longer useful. Everything is now managed with the computed resource_ids field and store with the appointment_resource_ids field through the appointment_booking_line table. The c
Original PR description
We now group the gantt view by resource_ids to manage appointment type where multiple resources can be chosen for the booking. It is now possible to manage appointment types of restaurant type (aka with manage capacity and multi resources). The field appointment_resource_id on the calendar event is removed as no longer useful. Everything is now managed with the computed resource_ids field and store with the appointment_resource_ids field through the appointment_booking_line table. The capacity distribution between resources is simplified and takes the shared resources in last. task-3812927 Forward-Port-Of: odoo/enterprise#59003
The term "Upsell" has a negative impact on customers in some countries. It has been changed to "Quotation" task_id: 3699064 Forward-Port-Of: odoo/enterprise#58645
Original PR description
The term "Upsell" has a negative impact on customers in some countries. It has been changed to "Quotation" task_id: 3699064 Forward-Port-Of: odoo/enterprise#58645
The product tracking is enabled by default in the demo data. Running the test without those data will break, as the 2 lines in the tour won't be grouped. runbot 54158 Forward-Port-Of: odoo/enterprise#59647
Original PR description
The product tracking is enabled by default in the demo data. Running the test without those data will break, as the 2 lines in the tour won't be grouped. runbot 54158 Forward-Port-Of: odoo/enterprise#59647
In the form view, new line were linked to new_id which computed the subscription_state value to a wrong version. Forcing readonly=False ensure the value is fetched from the origin and thus correct when computing the discount. task-id: 3699064 Forward-Port-Of: odoo/enterprise#58604
Original PR description
In the form view, new line were linked to new_id which computed the subscription_state value to a wrong version. Forcing readonly=False ensure the value is fetched from the origin and thus correct when computing the discount. task-id: 3699064 Forward-Port-Of: odoo/enterprise#58604
Steps: - install time sheet module - click on start button - before clicking on start button,width is different - after clicking on start button ,width is different Issue: - the width is unstable,seems different before and after clicking on start button Cause: - The problem occurs because of height issue solution: - if we give the height to that class the problem will be solved task-3645747 Forward-Port-Of: odoo/enterprise#59571 Forward-Port-Of: odoo/enterprise#50100
Original PR description
Steps: - install time sheet module - click on start button - before clicking on start button,width is different - after clicking on start button ,width is different Issue: - the width is unstable,seems different before and after clicking on start button Cause: - The problem occurs because of height issue solution: - if we give the height to that class the problem will be solved task-3645747 Forward-Port-Of: odoo/enterprise#59571 Forward-Port-Of: odoo/enterprise#50100