Wednesday, May 31, 2023
71 changes · master
Enhancements to existing features
Invoice sending now avoids showing a repeated prompt about missing customer email addresses. The warning about invalid customer email addresses only appears when the user has chosen to send the invoice by email, reducing confusion during invoice processing.
Original PR description
Description of the issue/feature this PR addresses: Improve warning message that gets shown when sending an invoice by removing the redundant "Please add an email..." message And only show the "The following customer doesn't have a valid address..." if the email checkbox is checked Based on [this task](https://www.odoo.com/web#id=3336623&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Current behavior before PR: Both warning message shows up when the user doesn't have an email address Desired behavior after PR is merged: No more of the redundant "Please add an email..." message And only show the "The following customer doesn't have a valid address..." if the email checkbox is checked --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
HR contract structure types can now be manually ordered, making them easier to manage in lists. When choosing a default structure type, the system now prioritizes the company country match, helping businesses apply the most relevant contract setup automatically.
Original PR description
added sequence + handle for tree view and updated compute to select company's country's structure type first. task 3279050
The project app now keeps the status button easier to find when project names are long or when using smaller screens. This improves navigation and reduces layout issues for users managing projects on desktop or mobile devices.
Original PR description
This commit will improve following UX - align the 'set status' button to the left when the project name is too long. Small Device: - set status button should be moved next to New button. task-3186684
This update expands internal JavaScript quality checks to the Sign module, while leaving older legacy code untouched. It helps developers maintain cleaner, more consistent code in Sign, reducing the risk of future issues without changing the user experience.
Original PR description
This commit enables JS tooling inside the sign module, with the exception of legacy code. task-3338273 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
The time off type setup now shows a clearer placeholder when no responsible person is selected. This helps administrators understand that nobody will be notified unless they choose a responsible person.
Original PR description
In this commit we have added "Nobody will be notified" placeholder in responsible of the leave type model. task-3334478
Resume line names and descriptions in the HR Skills app can now be translated. This helps multilingual organizations present employee resume information consistently in each user's language.
Original PR description
Before this commit, the name and description of resume lines were not translatable. task-3323624
The website contact footer now aligns its columns at the top instead of the bottom. This makes footers with longer text look cleaner and more consistent with other footer styles.
Original PR description
Before this commit, the columns in the "contact" footer template were aligned at the bottom, which looked bad and served no purpose. This commit aligns the columns towards the top, like the other footer templates. Steps to reproduce the bug: - Choose the "contact" footer for the homepage of a website. - Add multiple lines in one of the columns of the footer. - The columns are aligned at the bottom, and it looks quite ugly. task-3321445 task-3241256
Payroll structure types can now be arranged in a custom order. This helps HR teams control how contract and payroll options appear, making setup and selection more consistent.
Original PR description
see odoo/odoo#119810
The Sign application’s JavaScript code has been cleaned up to follow current coding standards, excluding older legacy areas. This reduces maintenance risk and helps future updates be delivered more consistently without changing day-to-day functionality for users.
Original PR description
This commit lints all existing JS except legacy code. task-3338273
Resolved issues and error corrections
This fixes an internal automated test for employee time off by running it on a fixed date when the employee is expected to work. It helps prevent false build failures and keeps quality checks stable without changing user-facing behavior.
Original PR description
Use freeze_time to ensure the tour runs on a date where the employee is supposed to work. Fixes runbot build error: 21683
Features or functions removed from Odoo
This removes obsolete internal code that is no longer used when handling manufacturing and inventory stock movements. The change simplifies maintenance and reduces technical clutter without changing day-to-day business workflows.
Original PR description
Since https://github.com/odoo/odoo/pull/102500 (v16) _multi_line_quantity_done_set is not used anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The live chat test files were reformatted to make upcoming work easier to review and maintain. This is an internal cleanup with no expected change to customer-facing live chat behavior.
Original PR description
This commit prepares the ground for the refactoring of the public livechat by prettifying the files that will be modified in order to ease the diff. part of task-2212347
Miscellaneous changes
Steps to reproduce: - set up a header with company logo - print 20 sale orders in arabic Bug: header disapears on most pages Fix: allow more time to render the documents according to the number of pages opw-3217155 Forward-Port-Of: odoo/odoo#122866 Forward-Port-Of: odoo/odoo#121054
Original PR description
Steps to reproduce: - set up a header with company logo - print 20 sale orders in arabic Bug: header disapears on most pages Fix: allow more time to render the documents according to the number of pages opw-3217155 Forward-Port-Of: odoo/odoo#122866 Forward-Port-Of: odoo/odoo#121054
Fixed an issue where inactive employees could appear without avatars in the Planning Gantt view. Avatars are now retrieved from employee resources, so schedules remain visually clear even for inactive staff records.
Original PR description
Before this commit when employee is non active gantt view does not display its avatar because progress bar for non active employees is undefined and here we tring to get employee from its progress bar. So this commit take employees from its resources instead of progress bar to get proper result when progress bar is not defined. task-3187910
This reverts commit 12355a80042c70d. Following of the next steps https://www.odoo.com/web#id=3338017&cids=1&model=project.task&view_type=form Initial opw-2992106 Forward-Port-Of: odoo/odoo#122563 Forward-Port-Of: odoo/odoo#122431
Original PR description
This reverts commit 12355a80042c70d. Following of the next steps https://www.odoo.com/web#id=3338017&cids=1&model=project.task&view_type=form Initial opw-2992106 Forward-Port-Of: odoo/odoo#122563 Forward-Port-Of: odoo/odoo#122431
When we input some string in many2many field under Coins/Bills in configuration setting of point of sale module . it will give an error with the message - 'could not convert string to float' Steps to Produce:- 1. Go to Point of Sale then configuration 2. click on 'Settings' 3. Under 'Payment' input some string in Coins/Bills Trace-back will be generated. Reason - The 'name_create' method of the 'pos_bill' model generates an error when a string is provided as input for the 'name
Original PR description
When we input some string in many2many field under Coins/Bills in configuration setting of point of sale module . it will give an error with the message - 'could not convert string to float' Steps to…
When we input some string in many2many field under Coins/Bills in configuration setting of point of sale module . it will give an error with the message -
'could not convert string to float'
Steps to Produce:-
1. Go to Point of Sale then configuration
2. click on 'Settings'
3. Under 'Payment' input some string in Coins/Bills
Trace-back will be generated.
Reason -
The 'name_create' method of the 'pos_bill' model generates an error when a string is provided as input for the 'name' field, since the expression 'float(name)' is unable to convert a string to a float.
Traceback -
```
ValueError: could not convert string to float: 'chéque cadeau'
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 457, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 430, in _call_kw_model
result = method(recs, *args, **kwargs)
File "addons/point_of_sale/models/pos_bill.py", line 15, in name_create
result = super().create({"name": name, "value": float(name)})
```
Applying these changes will resolve this issue.
Sentry - 4122478677
Forward-Port-Of: odoo/odoo#120207**TicketBAI features** - Generation of XML documents for invoices - Automatic signing of documents with certificates - Sending XML to the appropriate tax agency's servers - Parsing and storing their response - Preserving the invoice signature chain integrity - Displaying the TicketBAI QR code on the invoice PDF - Downloading XSD files for local validation - Test mode using tax agencies' test servers **Supported accounting flows** - Posting and canceling invoices - Foreign and na
Original PR description
**TicketBAI features** - Generation of XML documents for invoices - Automatic signing of documents with certificates - Sending XML to the appropriate tax agency's servers - Parsing and storing their response - Preserving the invoice signature chain integrity - Displaying the TicketBAI QR code on the invoice PDF - Downloading XSD files for local validation - Test mode using tax agencies' test servers **Supported accounting flows** - Posting and canceling invoices - Foreign and national customers - Multi-currency - Refunds (credit notes) - Discounts - Simplified invoicing **Not supported accounting flows** - Specific VAT regimes - Handling of third-party invoices - XML generation and EDI operations for vendor bills (Bizkaia LROE) - Modelo 140 (Bizkaia LROE) - Invoice batching (Bikzaia LROE) Forward-Port-Of: odoo/odoo#122574 Forward-Port-Of: odoo/odoo#109907
On this situation: * P1 consumable product, kit, with components P2 and P3 in its BoM using 1 of each * P2 comsumable product, kit, with component P3 using 1 in the BoM * P3 storable product, 10 units in stock Before: The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we need precisely two of P3s, one for P2 BoM then an extra for P1 BoM. After: The qyt_available for P1 is 5. Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
On this situation: * P1 consumable product, kit, with components P2 and P3 in its BoM using 1 of each * P2 comsumable product, kit, with component P3 using 1 in the BoM * P3 storable product, 10 units in stock Before: The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we need precisely two of P3s, one for P2 BoM then an extra for P1 BoM. After: The qyt_available for P1 is 5. 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#121660 Forward-Port-Of: odoo/odoo#120752
Follow-up of https://github.com/odoo/odoo/pull/121468 Since https://github.com/odoo/odoo/commit/9f4622492c5cd84847368d32bf02b0b538a6dd69 (16.2), ´additionalClasses´ has to be added on the field instead of the component. Forward-Port-Of: odoo/odoo#122659
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/121468 Since https://github.com/odoo/odoo/commit/9f4622492c5cd84847368d32bf02b0b538a6dd69 (16.2), ´additionalClasses´ has to be added on the field instead of the component. Forward-Port-Of: odoo/odoo#122659
Since https://github.com/odoo/odoo/pull/121355, add_to_compute on no-store compute field, lead to recompute the field at the end of request and it can lead to some non deterministic bug (compute with a bad context by example). Avoid to add_to_compute no-store or no-compute fields. Forward-Port-Of: odoo/odoo#122867 Forward-Port-Of: odoo/odoo#122496
Original PR description
Since https://github.com/odoo/odoo/pull/121355, add_to_compute on no-store compute field, lead to recompute the field at the end of request and it can lead to some non deterministic bug (compute with a bad context by example). Avoid to add_to_compute no-store or no-compute fields. Forward-Port-Of: odoo/odoo#122867 Forward-Port-Of: odoo/odoo#122496
=== ISSUE === If you open the `Expenses` module, the buttons placed on the left inside the Control Panel have a custom margin. One of them has a `.mx-1` and another one has a custom `.gap` defined in the SCSS files. === AFTER === We remove the `.mx-1` class to replace it with a `.me-1` class, which is used across Control Panels to space buttons. task-3330141 part of task-332626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
=== ISSUE === If you open the `Expenses` module, the buttons placed on the left inside the Control Panel have a custom margin. One of them has a `.mx-1` and another one has a custom `.gap` defined in the SCSS files. === AFTER === We remove the `.mx-1` class to replace it with a `.me-1` class, which is used across Control Panels to space buttons. task-3330141 part of task-332626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121639
== ISSUE == With the refactoring of the `utilities_custom.scss` file, the transparent key from the map actually disappeared. This commit aims to reintroduce the key in order to make the class work. We also fix some synthax. == After this commit == We reintroduce the `.bg-transparent` class inside the `utilities_custom` file. This allow us to extend the default BS's maps rather than override them. task-3326297 part of task-3326263 --- I confirm I have signed the CLA and read t
Original PR description
== ISSUE == With the refactoring of the `utilities_custom.scss` file, the transparent key from the map actually disappeared. This commit aims to reintroduce the key in order to make the class work. We also fix some synthax. == After this commit == We reintroduce the `.bg-transparent` class inside the `utilities_custom` file. This allow us to extend the default BS's maps rather than override them. task-3326297 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121390
Description of the issue/feature this PR addresses: According to Singapore IRD documentation, Box 13 should only involve accounts of type "Income", Currently, Box 13 calculation is based "Net Profit" which is the combination of Operating incomes, Income, Cost of Revenue, Expenses and Depreciation. 2860997 Current behavior before PR: Box 13 calculation is based on Net profit = OPINC + OIN - COS - EXP - DEP Desired behavior after PR is merged: Box 13 calculation is purely on OPINC
Original PR description
Description of the issue/feature this PR addresses: According to Singapore IRD documentation, Box 13 should only involve accounts of type "Income", Currently, Box 13 calculation is based "Net Profit" which is the combination of Operating incomes, Income, Cost of Revenue, Expenses and Depreciation. 2860997 Current behavior before PR: Box 13 calculation is based on Net profit = OPINC + OIN - COS - EXP - DEP Desired behavior after PR is merged: Box 13 calculation is purely on OPINC --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113087
We are reverting this commit (f9da3590261b304f9c12f01f5800cec50faebc1a) because it is not compliant to the stable policy and is blocking users that had more than one cash payment methods in configuring their pos. opw-3331677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121959 Forward-Port-Of: odoo/odoo#121879
Original PR description
We are reverting this commit (f9da3590261b304f9c12f01f5800cec50faebc1a) because it is not compliant to the stable policy and is blocking users that had more than one cash payment methods in configuring their pos. opw-3331677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121959 Forward-Port-Of: odoo/odoo#121879
Previously, validating an order and initiating a print receipt request, followed by an immediate exit from the receipt screen caused an error. The error arose when the system attempted to update the className of a nonexistent element. This commit resolves this issue by ensuring the element's existence before attempting any updates. opw-3329887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121956
Original PR description
Previously, validating an order and initiating a print receipt request, followed by an immediate exit from the receipt screen caused an error. The error arose when the system attempted to update the className of a nonexistent element. This commit resolves this issue by ensuring the element's existence before attempting any updates. opw-3329887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121956
Before this commit, the reversal of a passed exchange move was not created on the correct date: - If sequence is reset by month, the reversal should be created at the end of the month of the exchange move, and if sequence is reset by year, at the end of the year. Steps: - With a foreign currency X activated and two different rates few months in the past. - Create and confirm an invoice with currency X at the date of the first rate. - Register a payment at the date of the second rate
Original PR description
Before this commit, the reversal of a passed exchange move was not created on the correct date: - If sequence is reset by month, the reversal should be created at the end of the month of the exchange move, and if sequence is reset by year, at the end of the year. Steps: - With a foreign currency X activated and two different rates few months in the past. - Create and confirm an invoice with currency X at the date of the first rate. - Register a payment at the date of the second rate (an exchange move is created). - Unreconcile the payment from the invoice. -> A reversal of the exchange move is created, but the date is wrong (set to today's date). opw-2856385 Forward-Port-Of: odoo/odoo#122929 Forward-Port-Of: odoo/odoo#121279
Currently, if you use the automatic entry wizard to change the period of a journal item dated prior to the lock date, you'll just get blocked with a UserError, with no workaround. This commit changes the date of the adjustment entry to be the first end of month after the lock date. As a result, the adjustment entry can be created. Based on @poma-odoo's PR #92439 , targeting 16.0, simplifying the test and refraining from 'optimizing' the widget :smile: Taskid: 2823170 Forward-Port-Of: od
Original PR description
Currently, if you use the automatic entry wizard to change the period of a journal item dated prior to the lock date, you'll just get blocked with a UserError, with no workaround. This commit changes the date of the adjustment entry to be the first end of month after the lock date. As a result, the adjustment entry can be created. Based on @poma-odoo's PR #92439 , targeting 16.0, simplifying the test and refraining from 'optimizing' the widget :smile: Taskid: 2823170 Forward-Port-Of: odoo/odoo#122544 Forward-Port-Of: odoo/odoo#121566
Before this commit, the widget value was updated(based on the current state) prior to updating the snippet UI. As a result, the widget value reflected the old value. After this commit, the widget value updates according to the current state after the snippet UI has been updated. PR:[120569](https://github.com/odoo/odoo/pull/120569) task-3112890 Forward-Port-Of: odoo/odoo#122722 Forward-Port-Of: odoo/odoo#120569
Original PR description
Before this commit, the widget value was updated(based on the current state) prior to updating the snippet UI. As a result, the widget value reflected the old value. After this commit, the widget value updates according to the current state after the snippet UI has been updated. PR:[120569](https://github.com/odoo/odoo/pull/120569) task-3112890 Forward-Port-Of: odoo/odoo#122722 Forward-Port-Of: odoo/odoo#120569
Prior to this commit, in the "Chatter", when a user planned an activity, a new section appeared at the top of the chatter displaying the planned activities. Users had the ability to collapse this section. When the section was collapsed, a title and a badge were displayed next to it, indicating the number of activities. However, since milk, it was observed that the badge was positioned too close to the title, requiring some spacing adjustments. Additionally, the badge has been updated to adher
Original PR description
Prior to this commit, in the "Chatter", when a user planned an activity, a new section appeared at the top of the chatter displaying the planned activities. Users had the ability to collapse this section. When the section was collapsed, a title and a badge were displayed next to it, indicating the number of activities. However, since milk, it was observed that the badge was positioned too close to the title, requiring some spacing adjustments. Additionally, the badge has been updated to adhere to milk by adopting a rounded-pill shape. task-3339256 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122461
Steps to reproduce: configure easypost for international shipping (e.g. using USPS) Make a sale order for a customer in another country Add a discount program (e.g. 10% off) Attempt to add shipping and get the rates Get traceback: `Easypost returned an error: Wrong parameter type. value: must be greater than or equal to 0` To fix this we need to exclude service type products when creating commodities from order lines (similar to creating commodities from stock move lines) opw-3269467
Original PR description
Steps to reproduce: configure easypost for international shipping (e.g. using USPS) Make a sale order for a customer in another country Add a discount program (e.g. 10% off) Attempt to add shipping and get the rates Get traceback: `Easypost returned an error: Wrong parameter type. value: must be greater than or equal to 0` To fix this we need to exclude service type products when creating commodities from order lines (similar to creating commodities from stock move lines) opw-3269467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122281 Forward-Port-Of: odoo/odoo#121123
Forward-Port-Of: odoo/odoo#122904
Original PR description
Forward-Port-Of: odoo/odoo#122904
Since the coming into force on 01/01/2016 of Legislative Decree 139/2015 implementing EU Directive 2013/34/EU, extraordinary gains and losses should no longer be accounted separately on the P&L statement. See this article https://www.fisco7.it/2017/02/come-ricollocare-nel-conto-economico-gli-abrogati-oneri-e-proventi-straordinari/ There is therefore no point in having special accounts for extraordinary gains and losses. So we are removing accounts 71 and 72, both from the CoA and from t
Original PR description
Since the coming into force on 01/01/2016 of Legislative Decree 139/2015 implementing EU Directive 2013/34/EU, extraordinary gains and losses should no longer be accounted separately on the P&L statement. See this article https://www.fisco7.it/2017/02/come-ricollocare-nel-conto-economico-gli-abrogati-oneri-e-proventi-straordinari/ There is therefore no point in having special accounts for extraordinary gains and losses. So we are removing accounts 71 and 72, both from the CoA and from the Profit and Loss accounts. Since they should no longer be used since 2016, this should not have any impact for existing users. Enterprise PR: https://github.com/odoo/enterprise/pull/41014 opw-3245724 Forward-Port-Of: odoo/odoo#122936 Forward-Port-Of: odoo/odoo#121288
Before this commit, due to milk changes, when a user was out of the office, an alert box with a border-radius was displayed at the top of the chat. This border-radius needed to be removed. This commit effectively resolves this issue. task-3337778 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122233
Original PR description
Before this commit, due to milk changes, when a user was out of the office, an alert box with a border-radius was displayed at the top of the chat. This border-radius needed to be removed. This commit effectively resolves this issue. task-3337778 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122233
Steps to reproduce: 1. Open the "project" app 2. Switch to the list view 3. Select "All items" 4. Unselect "All items" 5. The focus searchbar is now focused => bug The searchbar is autofocused (each time it enters into the dom). Unlike before, in lists, it is removed when there are selected records, and comes back when there's no selection anymore. As a consequence, it takes back the focus. It should only take the focus on a first load, not every time the searchbar re-appears Task I
Original PR description
Steps to reproduce: 1. Open the "project" app 2. Switch to the list view 3. Select "All items" 4. Unselect "All items" 5. The focus searchbar is now focused => bug The searchbar is autofocused (each time it enters into the dom). Unlike before, in lists, it is removed when there are selected records, and comes back when there's no selection anymore. As a consequence, it takes back the focus. It should only take the focus on a first load, not every time the searchbar re-appears Task ID: 3336233 Forward-Port-Of: odoo/odoo#122500
This PR changes how automatic readonly props are applied to list fields so that it doesn't override the getFieldProps method. It also fixes the method 'getCellReadonly' in ProjectTaskListRenderer, which was renamed to 'isCellReadonly' in the framework but not in the custom renderer. Task-3340379 Forward-Port-Of: odoo/odoo#122601
Original PR description
This PR changes how automatic readonly props are applied to list fields so that it doesn't override the getFieldProps method. It also fixes the method 'getCellReadonly' in ProjectTaskListRenderer, which was renamed to 'isCellReadonly' in the framework but not in the custom renderer. Task-3340379 Forward-Port-Of: odoo/odoo#122601
Before this commit, when viewing the received badges tab in an employee's profile, there was a lack of spacing below the "Grant a badge" button. This commit resolves the issue by introducing proper spacing between the button and the displayed badges. task-3329971 part of task-3326263 Reviewed here: https://github.com/odoo/odoo/pull/121673 (had to close) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122684
Original PR description
Before this commit, when viewing the received badges tab in an employee's profile, there was a lack of spacing below the "Grant a badge" button. This commit resolves the issue by introducing proper spacing between the button and the displayed badges. task-3329971 part of task-3326263 Reviewed here: https://github.com/odoo/odoo/pull/121673 (had to close) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122684
Before / After <img width="291" alt="before" src="https://github.com/odoo/odoo/assets/6569390/9dc4bd30-3ee3-4800-be00-83fa831a3142"> <img width="303" alt="after" src="https://github.com/odoo/odoo/assets/6569390/b00753f7-4155-4a98-903e-fdc2ca6435f8"> Forward-Port-Of: odoo/odoo#122700
Original PR description
Before / After <img width="291" alt="before" src="https://github.com/odoo/odoo/assets/6569390/9dc4bd30-3ee3-4800-be00-83fa831a3142"> <img width="303" alt="after" src="https://github.com/odoo/odoo/assets/6569390/b00753f7-4155-4a98-903e-fdc2ca6435f8"> Forward-Port-Of: odoo/odoo#122700
To reproduce (on runbot): - Go to /groups url - click on "Public Mailing List" This fix `AttributeError: 'PortalMailGroup' object has no attribute 'env'` (introduced by odoo/odoo@b60cf1f9777) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122729
Original PR description
To reproduce (on runbot): - Go to /groups url - click on "Public Mailing List" This fix `AttributeError: 'PortalMailGroup' object has no attribute 'env'` (introduced by odoo/odoo@b60cf1f9777) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122729
Since this commit [1], the image cropping feature is no longer functioning properly. The modification of the "activateCropper" function code to remove the use of underscore has resulted in a change in the "data" parameter value passed to the cropper compared to before. This alteration is the cause of the issue. Steps to reproduce the bugs: - Open the homepage in Website edit mode. - Drag and drop a text-image snippet onto the page. - Click on the image in the text-image snippet. - Click
Original PR description
Since this commit [1], the image cropping feature is no longer functioning properly. The modification of the "activateCropper" function code to remove the use of underscore has resulted in a change in the "data" parameter value passed to the cropper compared to before. This alteration is the cause of the issue. Steps to reproduce the bugs: - Open the homepage in Website edit mode. - Drag and drop a text-image snippet onto the page. - Click on the image in the text-image snippet. - Click on the "Crop Image" button in the image options. - Change the aspect ratio of the image by clicking on the "4:3" button. - Click on the "Apply" button to apply the changes. - Bug: The changes are not being applied. [1]: https://github.com/odoo/odoo/commit/f4f0f783183507df8227b37fe1234c256325df6d task-3339518 Forward-Port-Of: odoo/odoo#122512
If applied, this commit will solve the issue of keyError when we confirm the manufacturing order and work order (s) are deleted. ### Steps to produce: - Configure BOM with 'Operations'. - Set operations in the 'Consumed in Operation' field which is in 'Components'. - Create MO using that BOM. - Delete the work order(s) from MO. - Click on the 'Confirm' button. Fix this issue when the work order is not available for that operation, setting False in stock.move record(s). sentry - 417
Original PR description
If applied, this commit will solve the issue of keyError when we confirm the manufacturing order and work order (s) are deleted. ### Steps to produce: - Configure BOM with 'Operations'. - Set…
If applied, this commit will solve the issue of keyError when we confirm the manufacturing order and work order (s) are deleted.
### Steps to produce:
- Configure BOM with 'Operations'.
- Set operations in the 'Consumed in Operation' field which is in 'Components'.
- Create MO using that BOM.
- Delete the work order(s) from MO.
- Click on the 'Confirm' button.
Fix this issue when the work order is not available for that operation, setting False in stock.move record(s).
sentry - 4171798106
see traceback -
```KeyError: mrp.routing.workcenter(25,)
File "addons/stock/models/stock_rule.py", line 574, in run_scheduler
self._run_scheduler_tasks(use_new_cursor=use_new_cursor, company_id=company_id)
File "addons/point_of_sale/models/pos_session.py", line 1999, in _run_scheduler_tasks
super(ProcurementGroup, self)._run_scheduler_tasks(use_new_cursor=use_new_cursor, company_id=company_id)
File "addons/stock/models/stock_rule.py", line 545, in _run_scheduler_tasks
orderpoints.sudo()._procure_orderpoint_confirm(use_new_cursor=use_new_cursor, company_id=company_id, raise_user_error=False)
File "addons/stock/models/stock_orderpoint.py", line 542, in _procure_orderpoint_confirm
orderpoints_batch._post_process_scheduler()
File "addons/mrp/models/stock_orderpoint.py", line 148, in _post_process_scheduler
]).action_confirm()
File "addons/mrp/models/mrp_production.py", line 1263, in action_confirm
production.workorder_ids._action_confirm()
File "home/odoo/src/enterprise/16.0/mrp_workorder/models/mrp_workorder.py", line 568, in _action_confirm
res = super()._action_confirm()
File "addons/mrp/models/mrp_workorder.py", line 499, in _action_confirm
production._link_workorders_and_moves()
File "addons/mrp/models/mrp_production.py", line 1296, in _link_workorders_and_moves
'workorder_id': workorder_per_operation[move.operation_id].id
```
Forward-Port-Of: odoo/odoo#122746
Forward-Port-Of: odoo/odoo#122115Issue: ------ In a multi-company context, the creation of a public holiday in one company will affect leaves in other companies. We cancel leaves that have the same time slot as the public holiday, regardless of the company. Solution: --------- Take account of the company in which the public holiday is created and compare it with the company of the employee who has leave. opw-3339973 Forward-Port-Of: odoo/odoo#122896
Original PR description
Issue: ------ In a multi-company context, the creation of a public holiday in one company will affect leaves in other companies. We cancel leaves that have the same time slot as the public holiday, regardless of the company. Solution: --------- Take account of the company in which the public holiday is created and compare it with the company of the employee who has leave. opw-3339973 Forward-Port-Of: odoo/odoo#122896
This reverts commit bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c. Since that commit, the domain may be double-encoded in the database if the user reorganizes the layout of his dashboard: once by the JavaScript code, and once by the serialization of the innerHTML property. However, there is no need to have it double-encoded, and some tools such as the upgrade scripts will fail upgrading the domain. With this commit, we are serializing the document to XML instead of HTML and therefore the pro
Original PR description
This reverts commit bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c. Since that commit, the domain may be double-encoded in the database if the user reorganizes the layout of his dashboard: once by the JavaScript code, and once by the serialization of the innerHTML property. However, there is no need to have it double-encoded, and some tools such as the upgrade scripts will fail upgrading the domain. With this commit, we are serializing the document to XML instead of HTML and therefore the produced output is valid XML that will be correctly interpreted by all the tools. [OPW-3130117](https://www.odoo.com/web#id=3130117&model=project.task) Forward-Port-Of: odoo/odoo#122766 Forward-Port-Of: odoo/odoo#119518
Steps to reprodue: - Create a dropshipped product - Sell the product to a client with a different language set - Print the delivery slip Bug: delivery slip is currently being printed in the vendor's language Fix: Print the delivery slip in the client language when possible opw-3193015 Forward-Port-Of: odoo/odoo#122792 Forward-Port-Of: odoo/odoo#121305
Original PR description
Steps to reprodue: - Create a dropshipped product - Sell the product to a client with a different language set - Print the delivery slip Bug: delivery slip is currently being printed in the vendor's language Fix: Print the delivery slip in the client language when possible opw-3193015 Forward-Port-Of: odoo/odoo#122792 Forward-Port-Of: odoo/odoo#121305
When using a `cr.savepoint`, the transaction must be flushed but in we don't have any reference to the env that should be used on the cursor, meaning that the env is chosen in the list of existing env. This choice is random because `Transaction.envs` is using a Weakset. In some case, the chosen env does not have the correct access right because the context `allowed_company_ids` is corresponding to a company coming from another test, leading to an access error, hidden by the try except. Flus
Original PR description
When using a `cr.savepoint`, the transaction must be flushed but in we don't have any reference to the env that should be used on the cursor, meaning that the env is chosen in the list of existing env. This choice is random because `Transaction.envs` is using a Weakset. In some case, the chosen env does not have the correct access right because the context `allowed_company_ids` is corresponding to a company coming from another test, leading to an access error, hidden by the try except. Flushing the environment before creating the savepoint will help to prevent this issue by flushing on a well defined environment. Note that the weakset used to store environments was modified in https://github.com/odoo/odoo/pull/121604 (master) Forward-Port-Of: odoo/odoo#122857 Forward-Port-Of: odoo/odoo#121659
Before this commit, when a discuss composer is open on Safari, the focus was locked inside the composer. Click away did not resolve it. This most certainly happens because changing `selectionStart` and `selectionEnd` on an input in Safari puts the focus on the input. This commit fixes the issue by not changing the current selection of input just before backing up. Related to https://github.com/odoo/odoo/commit/4efb465f6adcf8e4f9c6d4daa0b6f90079832af5 Forward-Port-Of: odoo/odoo#122935
Original PR description
Before this commit, when a discuss composer is open on Safari, the focus was locked inside the composer. Click away did not resolve it. This most certainly happens because changing `selectionStart` and `selectionEnd` on an input in Safari puts the focus on the input. This commit fixes the issue by not changing the current selection of input just before backing up. Related to https://github.com/odoo/odoo/commit/4efb465f6adcf8e4f9c6d4daa0b6f90079832af5 Forward-Port-Of: odoo/odoo#122935
A raw query is not necessary to produce the desired result, found activities need to be kept only if the corresponding record can be found with standard search (which includes multi-company check). Part of task-3266643 Forward-Port-Of: odoo/odoo#122956 Forward-Port-Of: odoo/odoo#122354
Original PR description
A raw query is not necessary to produce the desired result, found activities need to be kept only if the corresponding record can be found with standard search (which includes multi-company check). Part of task-3266643 Forward-Port-Of: odoo/odoo#122956 Forward-Port-Of: odoo/odoo#122354
Currently when a server action causes an error it raises an Exception which will be caught by sentry and causes unnecessary traffic. So, we stop catching exceptoins from server actions which are supposed to be generated by User's Mistakes. sentry-4169384356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121432
Original PR description
Currently when a server action causes an error it raises an Exception which will be caught by sentry and causes unnecessary traffic. So, we stop catching exceptoins from server actions which are supposed to be generated by User's Mistakes. sentry-4169384356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121432
Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session cookie duration was set to 3 months, but the server-side garbage collection of inactive session was reaping them after 7 days of inactivity. The cookie lifetime was essentially superseded by the server-side GC. After https://github.com/odoo/odoo/pull/78857 these limits were made consistent with each other, but the lifetime value was kept at 3 months, which is a bit too long as a default. This commit changes the default SES
Original PR description
Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session cookie duration was set to 3 months, but the server-side garbage collection of inactive session was reaping them after 7 days of…
Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session cookie duration was set to 3 months, but the server-side garbage collection of inactive session was reaping them after 7 days of inactivity. The cookie lifetime was essentially superseded by the server-side GC.
After https://github.com/odoo/odoo/pull/78857 these limits were made consistent with each other, but the lifetime value was kept at 3 months, which is a bit too long as a default.
This commit changes the default SESSION_LIFETIME back to 7 days for both limits.
In addition, since the server-side GC is now implemented by a database-specific cron job, this commit introduces an optional system parameter `sessions.max_inactivity_seconds` that can be set to override the default server-side GC threshold, to make it shorter.
Note 1: the ICP does not modify the cookie lifetime which will remain set to the default 7 days. This means normal browser sessions won't stay alive for longer than 7 days of inactivity. So `sessions.max_inactivity_seconds` can't be effectively set to a longer expiration time. This seems like a reasonably safe default.
Note 2: the session GC happens during the execution of the autovacuum cron job ("Base: Auto-vacuum internal data") which is scheduled once per day by default. When setting a small `sessions.max_inactivity_seconds` value, it may be necessary to increase the frequency of that cron job accordingly.
Forward-Port-Of: odoo/odoo#122888Expected singleton: res.currency() when currency not provided also when remove company in invoice. Steps to Produce:- - While go to invoice and click on `REGISTER PAYMENT` - Remove currency from wizard Trace-back on sentry: ``` ValueError: Expected singleton: res.currency() File "odoo/http.py", line 2115, in __call__ response = request._serve_db() File "odoo/http.py", line 1698, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/s
Original PR description
Expected singleton: res.currency() when currency not provided also when remove company in invoice. Steps to Produce:- - While go to invoice and click on `REGISTER PAYMENT` - Remove currency from…
Expected singleton: res.currency() when currency not provided
also when remove company in invoice.
Steps to Produce:-
- While go to invoice and click on `REGISTER PAYMENT`
- Remove currency from wizard
Trace-back on sentry:
```
ValueError: Expected singleton: res.currency()
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 6540, in onchange
todo = [
File "odoo/models.py", line 6543, in <listcomp>
if name not in done and snapshot0.has_changed(name)
File "odoo/models.py", line 6326, in has_changed
return self[name] != record[name]
File "odoo/models.py", line 5932, in __getitem__
return self._fields[key].__get__(self, type(self))
File "odoo/fields.py", line 1209, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4302, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 99, in determine
return needle(*args)
File "addons/account/wizard/account_payment_register.py", line 588, in _compute_hide_writeoff_section
wizard.hide_writeoff_section = wizard.early_payment_discount_mode
File "odoo/fields.py", line 1209, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4302, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 99, in determine
return needle(*args)
File "addons/account/wizard/account_payment_register.py", line 561, in _compute_early_payment_discount_mode
wizard.currency_id.compare_amounts(wizard.amount, total_amount_residual_in_wizard_currency) == 0 \
File "odoo/addons/base/models/res_currency.py", line 231, in compare_amounts
self.ensure_one()
File "odoo/models.py", line 5192, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
Applying this changes will resolve this issue.
sentry - 4149615534
Forward-Port-Of: odoo/odoo#122723
Forward-Port-Of: odoo/odoo#121625A recent refactoring of discuss app unintentionally removed the feature to automatically notify and open chat window with new user when they log in for the 1st time. <img width="401" alt="Screenshot 2023-05-26 at 19 07 00" src="https://github.com/odoo/odoo/assets/6569390/ff04ddf3-8969-4bbc-9343-62c9d1da65a7"> Forward-Port-Of: odoo/odoo#122749
Original PR description
A recent refactoring of discuss app unintentionally removed the feature to automatically notify and open chat window with new user when they log in for the 1st time. <img width="401" alt="Screenshot 2023-05-26 at 19 07 00" src="https://github.com/odoo/odoo/assets/6569390/ff04ddf3-8969-4bbc-9343-62c9d1da65a7"> Forward-Port-Of: odoo/odoo#122749
Prior to this commit, the svg icon of `board` had duplicate `viewBox` that breaks the svg. This commit fixes this issue. task-3343278 Part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122893
Original PR description
Prior to this commit, the svg icon of `board` had duplicate `viewBox` that breaks the svg. This commit fixes this issue. task-3343278 Part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122893
Before this commit, when clicking on a category in emoji picker when using Firefox, sometimes the previous category was selected. This come from Firefox selecting the previous sticky section with `getBoundingRect()` and `elementFromPoint` on grid top coordinate. This commit fixes the issue by rounding to the integer, so that the previous hidden and sticky section is not selected in Firefox. Forward-Port-Of: odoo/odoo#122910
Original PR description
Before this commit, when clicking on a category in emoji picker when using Firefox, sometimes the previous category was selected. This come from Firefox selecting the previous sticky section with `getBoundingRect()` and `elementFromPoint` on grid top coordinate. This commit fixes the issue by rounding to the integer, so that the previous hidden and sticky section is not selected in Firefox. Forward-Port-Of: odoo/odoo#122910
When moving a package, the quant at source location is not automatically removed To reproduce the issue: 1. In Settings, enable - Packages - Storage Locations 2. Create a storable product P 3. Update the on hand quantity - 1 x P at WH/Stock in package PK 4. Create a planned delivery D with 1 x P 5. Confirm and reserve D - PK should be reserved 6. Validate 7. Open the package - Its location is "Partner Locations/Customers", which make sense 8. Inventory > Configura
Original PR description
When moving a package, the quant at source location is not automatically removed To reproduce the issue: 1. In Settings, enable - Packages - Storage Locations 2. Create a storable product P 3. Update…
When moving a package, the quant at source location is not automatically removed To reproduce the issue: 1. In Settings, enable - Packages - Storage Locations 2. Create a storable product P 3. Update the on hand quantity - 1 x P at WH/Stock in package PK 4. Create a planned delivery D with 1 x P 5. Confirm and reserve D - PK should be reserved 6. Validate 7. Open the package - Its location is "Partner Locations/Customers", which make sense 8. Inventory > Configuration > ... > Locations, open WH/Stock 9. Current Stock Error: There is a line with PK. The quantity is 0 but still, it create some confusion for the user who could believe that the package is still in WH/Stock This issue does not occur if the user goes through the product form and click on the on hand quantity. The "incorrect" quant will not be there. This is because, when loading the action, we call `_quant_tasks`: https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300 This method will clean the quants (merge & unlink) However, in the above case (step 9), the action is defined on XML side: https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26 https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196 So, we can't make it behave as it does from the product form, unfortunatly. As alternative, we can try to call `_unlink_zero_quants` when we are moving a package (and not `_quant_tasks` for perf matters as, so far, we will not have any quant to merge) OPW-3292238 Forward-Port-Of: odoo/odoo#122974 Forward-Port-Of: odoo/odoo#122673
This fix is a followup to the changes made in https://github.com/odoo/odoo/commit/5d951d91bb879a7238cb9c2396ebe2fff0c3eed2 where `format_currency` is replaced with `formatCurrency` which is based on a more standard way offormatting monetary values. Forward-Port-Of: odoo/odoo#122047
Original PR description
This fix is a followup to the changes made in https://github.com/odoo/odoo/commit/5d951d91bb879a7238cb9c2396ebe2fff0c3eed2 where `format_currency` is replaced with `formatCurrency` which is based on a more standard way offormatting monetary values. Forward-Port-Of: odoo/odoo#122047
Steps to reproduce: - install l10n_be (company B) - stay on Company A and create a cash rounding - Go to Company B and create an invoice - In Other Infos > Cash Rouding Method, set it to the earlier created one - Save Issue: You won't be able to save. But the message is too generic to know what is the cause of it "Missing required account on accountable invoice line." Cause: The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessib
Original PR description
Steps to reproduce: - install l10n_be (company B) - stay on Company A and create a cash rounding - Go to Company B and create an invoice - In Other Infos > Cash Rouding Method, set it to the earlier created one - Save Issue: You won't be able to save. But the message is too generic to know what is the cause of it "Missing required account on accountable invoice line." Cause: The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set. When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised. Solution: The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set opw-3185950 Forward-Port-Of: odoo/odoo#122949 Forward-Port-Of: odoo/odoo#120892
This commit removes the css that was creating two layout issues : - [1] When the chatter was rendered under the form view with the `isInFormSheetBg` class, it added an unwanted background and border. - [2] When an attachment was uploaded and created a preview (eg. in approvals), it created an unwanted border. This commit fixes these issues. 👉 https://www.awesomescreenshot.com/image/39783675?key=b69517b13efbf6cc71acb3e32bea9652 task-3334866 Part of task-3326263 --- I co
Original PR description
This commit removes the css that was creating two layout issues : - [1] When the chatter was rendered under the form view with the `isInFormSheetBg` class, it added an unwanted background and border. - [2] When an attachment was uploaded and created a preview (eg. in approvals), it created an unwanted border. This commit fixes these issues. 👉 https://www.awesomescreenshot.com/image/39783675?key=b69517b13efbf6cc71acb3e32bea9652 task-3334866 Part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121924
Before [1], chat windows were not shown on the website preview. Showing them was not intended and those chat windows overlap with the one of the livechat. This PR restores the previous behavior by preventing chat windows to be shown on the website. [1]: odoo#110188 Forward-Port-Of: odoo/odoo#122430
Original PR description
Before [1], chat windows were not shown on the website preview. Showing them was not intended and those chat windows overlap with the one of the livechat. This PR restores the previous behavior by preventing chat windows to be shown on the website. [1]: odoo#110188 Forward-Port-Of: odoo/odoo#122430
The adapted tests passed on runbot but failed (at least) on chrome 113. 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#123002
Original PR description
The adapted tests passed on runbot but failed (at least) on chrome 113. 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#123002
Before this commit, the attachment button had icon and label on different lines in mobile, which made the chatter topbar bigger in height than it should. Before / After <img width="371" alt="before" src="https://github.com/odoo/odoo/assets/6569390/5f60d62b-cb9c-4377-9a18-129ac812aad7"> <img width="373" alt="after" src="https://github.com/odoo/odoo/assets/6569390/832592d1-af09-46c7-b7a0-baed72377483"> Forward-Port-Of: odoo/odoo#123053
Original PR description
Before this commit, the attachment button had icon and label on different lines in mobile, which made the chatter topbar bigger in height than it should. Before / After <img width="371" alt="before" src="https://github.com/odoo/odoo/assets/6569390/5f60d62b-cb9c-4377-9a18-129ac812aad7"> <img width="373" alt="after" src="https://github.com/odoo/odoo/assets/6569390/832592d1-af09-46c7-b7a0-baed72377483"> Forward-Port-Of: odoo/odoo#123053
**Description of the issue/feature this PR addresses:** Previously, a performance improvement landed on https://github.com/odoo/odoo/commit/5a2efd2e5c3e65502c031f79f85319f3351f66e3 (https://github.com/odoo/odoo/pull/116217) It totally makes sense but there's a corner case that's actually hurt by this commit: there are cases where the heavy computation of `employee_quantity_available` is simply not used by the following loop. We have a database with lots of records, and that commit was a
Original PR description
**Description of the issue/feature this PR addresses:** Previously, a performance improvement landed on https://github.com/odoo/odoo/commit/5a2efd2e5c3e65502c031f79f85319f3351f66e3…
**Description of the issue/feature this PR addresses:** Previously, a performance improvement landed on https://github.com/odoo/odoo/commit/5a2efd2e5c3e65502c031f79f85319f3351f66e3 (https://github.com/odoo/odoo/pull/116217) It totally makes sense but there's a corner case that's actually hurt by this commit: there are cases where the heavy computation of `employee_quantity_available` is simply not used by the following loop. We have a database with lots of records, and that commit was actually a regression for us: a simple `name_search` on `hr.leave.type` would take `1.60s` instead of `0.14s`. With this PR, we go back to normal. I take the opportunity to improve this code block's readability by properly naming some variables. --- The PR includes 3 different commits to ease reviews. ping @Aurelienvd @kba-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#123008 Forward-Port-Of: odoo/odoo#122823
The missing 15A tax report line was added in odoo/odoo#90369 but it was not included in the VAT Payable/ Refundable Total line. With this commit, we add codes to TotalA and TotalB and modify the final total to use these codes instead. Bug report directly to me I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122979 Forward-Port-Of: odoo/odoo#122843
Original PR description
The missing 15A tax report line was added in odoo/odoo#90369 but it was not included in the VAT Payable/ Refundable Total line. With this commit, we add codes to TotalA and TotalB and modify the final total to use these codes instead. Bug report directly to me I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122979 Forward-Port-Of: odoo/odoo#122843
To Reproduce ============ - on Rental app change the name of product by adding apostrophe `'` - go back to Renatal > Schedule, and hover on the product - an error will occure Problem ======= - when hovering on the product we execute a query where the selector includes the name of the product - as the apostrophe `'` is a special charachter it breaks the query Solution ======== escape the apostrophe opw-3324981 Forward-Port-Of: odoo/enterprise#41331
Original PR description
To Reproduce ============ - on Rental app change the name of product by adding apostrophe `'` - go back to Renatal > Schedule, and hover on the product - an error will occure Problem ======= - when hovering on the product we execute a query where the selector includes the name of the product - as the apostrophe `'` is a special charachter it breaks the query Solution ======== escape the apostrophe opw-3324981 Forward-Port-Of: odoo/enterprise#41331
Generic EC Sales reports warning links are broken, they lead to empty invoices/partners list view. Those warnings appear when you have an Intra-community sale with a partner that have no VAT number set. Task: 3256341 Forward-Port-Of: odoo/enterprise#41677 Forward-Port-Of: odoo/enterprise#41640
Original PR description
Generic EC Sales reports warning links are broken, they lead to empty invoices/partners list view. Those warnings appear when you have an Intra-community sale with a partner that have no VAT number set. Task: 3256341 Forward-Port-Of: odoo/enterprise#41677 Forward-Port-Of: odoo/enterprise#41640
Before this commit: When we link any document with a task it is visible to the follower on the portal. However, when we delete that document, it is still visible on the portal After this commit: On deletion, the document is no longer visible on the portal. Task: 3199658 Forward-Port-Of: odoo/enterprise#41657 Forward-Port-Of: odoo/enterprise#39927
Original PR description
Before this commit: When we link any document with a task it is visible to the follower on the portal. However, when we delete that document, it is still visible on the portal After this commit: On deletion, the document is no longer visible on the portal. Task: 3199658 Forward-Port-Of: odoo/enterprise#41657 Forward-Port-Of: odoo/enterprise#39927
Opening a helpdesk ticket's FormView can lead to a MemoryError because of the partner_ticket_count/partner_open_ticket_count stats buttons. These two fields are non-stored computed fields with the same compute function, `_compute_partner_ticket_count`. Inside this function the `partner_open_ticket_count` is computed by first calling filtered on partner_ticket. Because partner_ticket can be quite large in this context (more than 20000 for some ticket), reading all the prefetchable fields value
Original PR description
Opening a helpdesk ticket's FormView can lead to a MemoryError because of the partner_ticket_count/partner_open_ticket_count stats buttons. These two fields are non-stored computed fields with the same compute function, `_compute_partner_ticket_count`. Inside this function the `partner_open_ticket_count` is computed by first calling filtered on partner_ticket. Because partner_ticket can be quite large in this context (more than 20000 for some ticket), reading all the prefetchable fields values and putting them in cache can lead to a MemoryError. Given that we only need the length of the results, it's safe to turn off prefetching here. We won't need the fields' values of all the partner_ticket recordset. opw-3285439 Forward-Port-Of: odoo/enterprise#40942
This commit aims to allow upsell on renewal to be correctly computed as well as simplify the discount logic. We also allow to upsell a SO that has not been invoiced yet. Before this commit, the prorata was based on the number of day in the current month, this could lead to some weird behaviour where 5 days were not treated the same dependins on when we were upselling. Now, we do a prorata based on the average number of day in a month to ensure a more coherent results. task-id : 3086493
Original PR description
This commit aims to allow upsell on renewal to be correctly computed as well as simplify the discount logic. We also allow to upsell a SO that has not been invoiced yet. Before this commit, the prorata was based on the number of day in the current month, this could lead to some weird behaviour where 5 days were not treated the same dependins on when we were upselling. Now, we do a prorata based on the average number of day in a month to ensure a more coherent results. task-id : 3086493 Forward-Port-Of: odoo/enterprise#38678 Forward-Port-Of: odoo/enterprise#35711
- Remove section E of the P&L - Enable a date range filter on the P&L - Correct spelling in the Balance Sheet - Add missing section A.VII to the Simplified Balance Sheet Community PR: https://github.com/odoo/odoo/pull/121288 opw-3245724 Forward-Port-Of: odoo/enterprise#41667 Forward-Port-Of: odoo/enterprise#41014
Original PR description
- Remove section E of the P&L - Enable a date range filter on the P&L - Correct spelling in the Balance Sheet - Add missing section A.VII to the Simplified Balance Sheet Community PR: https://github.com/odoo/odoo/pull/121288 opw-3245724 Forward-Port-Of: odoo/enterprise#41667 Forward-Port-Of: odoo/enterprise#41014
Current behaviour: --- When a suggested accessory of a rental product is in the cart, it is written "from per 3 hours $ 5.00" Expected behaviour: --- It should be "from $ 5.00 per 3 hours" Steps to reproduce: --- 1. Head over to Rental 2. Open Products 3. Create 2 products 4. Add time-based pricing monthly for both 5. Select one of the product: 6. In Sales, in Accessory Products, add the other one 7. Go to website, add to cart 8. "from per month $ 1.00" opw-3330250 Forward
Original PR description
Current behaviour: --- When a suggested accessory of a rental product is in the cart, it is written "from per 3 hours $ 5.00" Expected behaviour: --- It should be "from $ 5.00 per 3 hours" Steps to reproduce: --- 1. Head over to Rental 2. Open Products 3. Create 2 products 4. Add time-based pricing monthly for both 5. Select one of the product: 6. In Sales, in Accessory Products, add the other one 7. Go to website, add to cart 8. "from per month $ 1.00" opw-3330250 Forward-Port-Of: odoo/enterprise#41599
Several Peru-specific fields were added to the Partner view by l10n_pe_edi_stock_20. This commit hides them if the partner does not have Peru as its country and if the current company is not based in Peru. PR for versions 15 and 16: https://github.com/odoo/enterprise/pull/39939 Forward-Port-Of: odoo/enterprise#41373 Forward-Port-Of: odoo/enterprise#39943
Original PR description
Several Peru-specific fields were added to the Partner view by l10n_pe_edi_stock_20. This commit hides them if the partner does not have Peru as its country and if the current company is not based in Peru. PR for versions 15 and 16: https://github.com/odoo/enterprise/pull/39939 Forward-Port-Of: odoo/enterprise#41373 Forward-Port-Of: odoo/enterprise#39943
Bug === When switching from a document to an other, in the preview, it's possible to get a traceback. The reason is that the previous index is wrongly computed and can have a negative value. Task-3292279 Forward-Port-Of: odoo/enterprise#40701
Original PR description
Bug === When switching from a document to an other, in the preview, it's possible to get a traceback. The reason is that the previous index is wrongly computed and can have a negative value. Task-3292279 Forward-Port-Of: odoo/enterprise#40701
Issue: In debug mode, on the form view of an employee, if we click on the "Timesheets" button, an error appears. Cause: We do not call the right widget, because none is specified in the view. The default `Many2OneField` will be used, but the props will not match. Solution: We have to call `TimesheetGridMany2OneField` which is an extend of `Many2OneField`. opw-3329404 Forward-Port-Of: odoo/enterprise#41276
Original PR description
Issue: In debug mode, on the form view of an employee, if we click on the "Timesheets" button, an error appears. Cause: We do not call the right widget, because none is specified in the view. The default `Many2OneField` will be used, but the props will not match. Solution: We have to call `TimesheetGridMany2OneField` which is an extend of `Many2OneField`. opw-3329404 Forward-Port-Of: odoo/enterprise#41276