Thursday, July 25, 2024
28 changes · saas-17.4
Resolved issues and error corrections
This fixes an internal test timing issue for website tooltip behavior by waiting for scheduled actions directly instead of relying on a fixed delay. It helps reduce false build failures and keeps validation of the web interface more dependable, with no expected change for end users.
Original PR description
Use runAllTimers to wait the timeouts instead of a hardcoded time. Build error: 66010291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The barcode scanner error sound has been moved into the shared barcodes module so it can be reused beyond inventory workflows. This makes the same audible feedback available to other barcode-based processes, such as event registration desks, without duplicating files.
Original PR description
[task-3847374](https://www.odoo.com/web#id=3847374&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form) [PR COM 160368](https://github.com/odoo/odoo/pull/160368) #### barcodes MOV _See COM branch for related commit_ I've moved the OGG and MP3 sounds to the barcodes module so that other modules using barcode scanner can use the same sound file. task-3847374 Related COM PR: https://github.com/odoo/odoo/pull/160368
Miscellaneous changes
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which pe
Original PR description
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the…
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which performs slowly if the `self` and `read_group_res` are large. Improvement: Delegate the computation to Postgres and assign the values obtained from the result. Benchmark: In method `_compute_pos_order_count` Number of `pos.order.line` records eligible in computation --> 17803 Where `self` is a a `loyalty.program` recordset len(self)| Before (in seconds) | After PR (in seconds) | |---------|--------|--------| |1000| 177.28 s | 6.43 s | |212| 29.73 s| 0.5 s | Improvement by about 98% on average opw-3903159 Forward-Port-Of: odoo/odoo#172554 Forward-Port-Of: odoo/odoo#167386
Some aliases to save a lot of time to IoT Team: - odoo, - odoo_help, - odoo_logs, - write_mode, - read_mode, - install, - blackbox. Use `odoo_help` to have more information. Task: 3947538 Forward-Port-Of: odoo/odoo#174085
Original PR description
Some aliases to save a lot of time to IoT Team: - odoo, - odoo_help, - odoo_logs, - write_mode, - read_mode, - install, - blackbox. Use `odoo_help` to have more information. Task: 3947538 Forward-Port-Of: odoo/odoo#174085
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component.
Original PR description
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component. This allows to keep coherent values inside the initialValues and to generate a new property name properly when the property's definition changes. In case of a change in the property's name, the value of the property for all other records using it will be properly reset to default. OPW-4015949 Forward-Port-Of: odoo/odoo#173697 Forward-Port-Of: odoo/odoo#173505
Fixed printer and serial devices detection: both listing more devices than expected. Task: 3947355 Forward-Port-Of: odoo/odoo#174164
Original PR description
Fixed printer and serial devices detection: both listing more devices than expected. Task: 3947355 Forward-Port-Of: odoo/odoo#174164
Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is does not apply while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solutio
Original PR description
Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is does not apply while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solution: - Add the CSS filter for done stage name as success-done. task-3852596 Forward-Port-Of: odoo/odoo#174375 Forward-Port-Of: odoo/odoo#163086
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174326
Before this commit ============== When we were clicking on the product catalog in MO and BOM it was not showing the correct quantity and correct highlighted product selected in the MO and BOM. After this commit ============= This feature is fixed in this commit, correct quantity and highlighted product is shown. task-3944909 Forward-Port-Of: odoo/odoo#168126
Original PR description
Before this commit ============== When we were clicking on the product catalog in MO and BOM it was not showing the correct quantity and correct highlighted product selected in the MO and BOM. After this commit ============= This feature is fixed in this commit, correct quantity and highlighted product is shown. task-3944909 Forward-Port-Of: odoo/odoo#168126
Issue: ============================ There is a missing synchronization between the stock move line and stock move for manufacturing orders, by-products, and batch transfers. When clicking on the list icon and making changes in quantity in the detailed operation modal, the updates are not properly reflected. Resolution: ============================ For manufacturing and by-products, add a "quantity" field in the 'detailed operation' view so that whenever the save button is clicked, al
Original PR description
Issue: ============================ There is a missing synchronization between the stock move line and stock move for manufacturing orders, by-products, and batch transfers. When clicking on the list…
Issue: ============================ There is a missing synchronization between the stock move line and stock move for manufacturing orders, by-products, and batch transfers. When clicking on the list icon and making changes in quantity in the detailed operation modal, the updates are not properly reflected. Resolution: ============================ For manufacturing and by-products, add a "quantity" field in the 'detailed operation' view so that whenever the save button is clicked, all fields are updated properly. For batch transfers, save '_parentRecord' instead of 'model.root' when the save button is clicked. Steps to Reproduce: ============================ 1. Install the mrp and stock modules. 2. Navigate to the stock module. 3. For manufacturing, go to the manufacturing menu inside operations. For by-products, go to the by-products tab inside the manufacturing order form view. For batch transfers, go to the batch transfer menu inside operations. 4. In the form view of each, open the modal (Detailed Operations) and modify the quantity. 5. Notice the lack of synchronization between the stock move line and the stock move. Expected Result: ============================= After implementing the solution, changes in quantities should be synchronized between the stock move line and the stock move in manufacturing orders, by-products, and batch transfers. When clicking on the list icon, the quantities should be updated accurately, reflecting any changes made. Task: 3815521 Forward-Port-Of: odoo/odoo#173923 Forward-Port-Of: odoo/odoo#160095
### Current behavior: Auto-trigger reordering rules can be snoozed from the list view. ### Expected behavior: Since the snooze mechanic is here onyl to hide manual reordering rules, a user error should be raised if one tries to snooze an auto-trigger reordering rule. #### + Revert of commit 515a53a opw-3901613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172213 Forward-Port-Of: odoo/odoo#170911
Original PR description
### Current behavior: Auto-trigger reordering rules can be snoozed from the list view. ### Expected behavior: Since the snooze mechanic is here onyl to hide manual reordering rules, a user error should be raised if one tries to snooze an auto-trigger reordering rule. #### + Revert of commit 515a53a opw-3901613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172213 Forward-Port-Of: odoo/odoo#170911
Steps: - Login as portal, and to to a task form, page sub-tasks. - Make Customer column visible. - Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The new record doesn't have a project (it will be given to it on save). Yet this PR odoo#111335 added the condition that it should be invisible if no project. The reason why it caused no issue in 16.3 (where it was merged) was that there was a default project in `child_ids`'s context. Solution
Original PR description
Steps: - Login as portal, and to to a task form, page sub-tasks. - Make Customer column visible. - Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The new record doesn't have a project (it will be given to it on save). Yet this PR odoo#111335 added the condition that it should be invisible if no project. The reason why it caused no issue in 16.3 (where it was merged) was that there was a default project in `child_ids`'s context. Solution: In this case, the condition is not needed. Subtasks always have a project : private tasks can't have subtasks and deleting project field on a non-private task's subtask will actually give it its parent project. So the solution is simple: remove the condition. task-3713729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174323
### Issue: Generated invoices does not appear in the page 'Manage Attachments'. ### Steps to reproduce: - Activate the developer mode - In Accounting > Customers > Invoices create a new one - Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter - Click on the debug icon, then on 'Manage Attachments' - The attachment does not show up ### Cause: The domain used for the 'Manage Attachments' search does not contain restriction on re
Original PR description
### Issue:
Generated invoices does not appear in the page 'Manage Attachments'.
### Steps to reproduce:
- Activate the developer mode
- In Accounting > Customers > Invoices create a new one
- Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter
- Click on the debug icon, then on 'Manage Attachments'
- The attachment does not show up
### Cause:
The domain used for the 'Manage Attachments' search does not contain restriction on res_field and id. So a new condition is added: ('res_field', '=', False). The logic behind this functionality is explained in this commit: https://github.com/odoo/odoo/commit/1bb61c970ed63eabe3821d21f3ed6f99c4b16daa In the case of invoices res_field is equal to invoice_pdf_report_file, so the invoice does not appear.
### Solution:
Add a context to the search request to skip the res_field test. Thus showing all attachments.
opw-3997094
Forward-Port-Of: odoo/odoo#172722Before this commit, if a settings app doesn't have settings (for instance if a setting header is not selected), the no content helper was always shown. The issue with this, is that the settings page is not a multi-record view, it's a customize form view, the content helper, it should only be shown if a search is performed and that no setting is found. This commit, fix this, and allow the no content helper to appear only if a search is performed and no setting is found. opw-4016050 Forward
Original PR description
Before this commit, if a settings app doesn't have settings (for instance if a setting header is not selected), the no content helper was always shown. The issue with this, is that the settings page is not a multi-record view, it's a customize form view, the content helper, it should only be shown if a search is performed and that no setting is found. This commit, fix this, and allow the no content helper to appear only if a search is performed and no setting is found. opw-4016050 Forward-Port-Of: odoo/odoo#174172 Forward-Port-Of: odoo/odoo#174059
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/odoo#164715
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/odoo#164715
Steps to reproduce: - Create a storable product. - Create a picking with it and validate. - Try to change the product type to consumable. Not allowed because there is a move done. - Archive the product. - Try to change the product type. No user error is raised... Excepted behaviour: It should not be possible to change the product type even if the product is archived, as it causes inconsistencies. Task 4058450 --- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
Steps to reproduce: - Create a storable product. - Create a picking with it and validate. - Try to change the product type to consumable. Not allowed because there is a move done. - Archive the product. - Try to change the product type. No user error is raised... Excepted behaviour: It should not be possible to change the product type even if the product is archived, as it causes inconsistencies. Task 4058450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173901 Forward-Port-Of: odoo/odoo#173526
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed
Original PR description
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed for self_party. Fix: Instead of only extracting the partner name for partner (other_party), the code is used in a new function, which can be called for both partner and company (self_party). Then, self_party_name can be used as a value in the template. opw-4053023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174266 Forward-Port-Of: odoo/odoo#173608
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write something in for the Terms & Conditions - In the Accounting app create a new invoice, confirm and preview - At the bottom of the preview, the Terms & Conditions are duplicated ### Cause: The report is trying to print the Arabic and English translation of the Term & Conditions, but only one of th
Original PR description
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write…
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write something in for the Terms & Conditions - In the Accounting app create a new invoice, confirm and preview - At the bottom of the preview, the Terms & Conditions are duplicated ### Cause: The report is trying to print the Arabic and English translation of the Term & Conditions, but only one of the two exists, so they appear duplicated. ### Solution: There is already a way to translate manually the Terms & Conditions (Have the 2 languages installed, and a button appear near the text). So the fix is simply to display only the Arabic language when there is only one translation. A problem is that if the only translation is the English one, it will be printed as if it was written from right to left. But there is no way to know exactly the language of the text, and we can suppose the base language will be Arabic in most cases. opw-4043175 Forward-Port-Of: odoo/odoo#172781
Before this comit, on a production system, it could happen that 'subscription_state': initial_values.get('subscription_state', '1_draft') would return False. Older SQL constraint could prevent the creation of logs without subscription_state value. ```py 112 @api.model 113 def _create_creation_log(self, order, initial_values): 114 -> return self.create({ 115 'order_id': order.id, 116 'event_type': '0_creation',
Original PR description
Before this comit, on a production system, it could happen that 'subscription_state': initial_values.get('subscription_state', '1_draft') would return False. Older SQL constraint could prevent the…
Before this comit, on a production system, it could happen that
'subscription_state': initial_values.get('subscription_state',
'1_draft') would return False.
Older SQL constraint could prevent the creation of logs without
subscription_state value.
```py
112 @api.model
113 def _create_creation_log(self, order, initial_values):
114 -> return self.create({
115 'order_id': order.id,
116 'event_type': '0_creation',
117 'amount_signed': max(order.recurring_monthly, 0),
118 'recurring_monthly': max(order.recurring_monthly, 0),
119 'subscription_state': initial_values.get('subscription_state', '1_draft'),
120 })
[11:22]
initial_values.get('subscription_state', '1_draft') > False
[11:23]
In [7]: so.subscription_state
Out[7]: False (modifié)
[11:23]
In [9]: so.is_subscription
Out[9]: True
In [10]: so.plan_id
Out[10]: sale.subscription.plan(174,)
```
The resulting SO could not be confirmed as the log creation would fail.
How to reproduce:
1) Create a quotation
2) Cancel it
3) Duplicate it
4) Confirm it
```
of22 File "/home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order_log.py", line 114, in _create_creation_log
of22 return self.create({
of22 File "<decorator-gen-12>", line 2, in create
of22 File "/home/odoo/src/odoo/saas-17.2/odoo/api.py", line 420, in _model_create_multi
of22 return create(self, [arg])
of22 File "/home/odoo/src/odoo/saas-17.2/odoo/models.py", line 4679, in create
of22 records = self._create(data_list)
of22 File "/home/odoo/src/odoo/saas-17.2/odoo/models.py", line 4867, in _create
of22 cr.execute(SQL(
of22 File "/home/odoo/src/odoo/saas-17.2/odoo/sql_db.py", line 365, in execute
of22 res = self._obj.execute(query, params)
of22 psycopg2.errors.NotNullViolation: null value in column "subscription_state" of relation "sale_order_log" violates not-null constraint
of22 DETAIL: Failing row contains (2475879, null, 2024-07-17, 7020.00, 1, 2024-07-17 01:22:56.6721, 1, 2024-07-17 01:22:56.6721, 0_creation, 2617260, 209, 7020.00, 35, 17, null, null, null, 4230165, null, 4230165, null).
```
Forward-Port-Of: odoo/enterprise#67170Description of the issue this commit addresses: We do not want the user to be able to create fiscal years on child companies. --- Desired behavior after this commit is merged: A new check in fiscal years raises an error when the user tries to create a fiscal year from a child company. --- no task-feedback Forward-Port-Of: odoo/enterprise#67285 Forward-Port-Of: odoo/enterprise#67121
Original PR description
Description of the issue this commit addresses: We do not want the user to be able to create fiscal years on child companies. --- Desired behavior after this commit is merged: A new check in fiscal years raises an error when the user tries to create a fiscal year from a child company. --- no task-feedback Forward-Port-Of: odoo/enterprise#67285 Forward-Port-Of: odoo/enterprise#67121
Currently it is assumed that all assets we write on belong to the same company. (Any exceptions to this are probably rare in practice.) This commit ensures that writing on assets with different companies works correctly. (no task) Forward-Port-Of: odoo/enterprise#67262 Forward-Port-Of: odoo/enterprise#65795
Original PR description
Currently it is assumed that all assets we write on belong to the same company. (Any exceptions to this are probably rare in practice.) This commit ensures that writing on assets with different companies works correctly. (no task) Forward-Port-Of: odoo/enterprise#67262 Forward-Port-Of: odoo/enterprise#65795
This traceback occurs when the `generate next recurring shifts` scheduled action runs with multiple planning slots of repeat types as `x_times`. To reproduce this issue:- 1) Install `planning` 2) Create two planning slots with `repeat` and repeat type as `Number of Occurrences` 3) For instance, manually run the `generate next recurring shifts` scheduled action Error:- ``` Expected singleton: planning.recurrency(1, 2) ``` When the scheduled action runs with multiple record s
Original PR description
This traceback occurs when the `generate next recurring shifts` scheduled action runs with multiple planning slots of repeat types as `x_times`. To reproduce this issue:- 1) Install `planning` 2)…
This traceback occurs when the `generate next recurring shifts` scheduled action runs with multiple planning slots of repeat types as `x_times`. To reproduce this issue:- 1) Install `planning` 2) Create two planning slots with `repeat` and repeat type as `Number of Occurrences` 3) For instance, manually run the `generate next recurring shifts` scheduled action Error:- ``` Expected singleton: planning.recurrency(1, 2) ``` When the scheduled action runs with multiple record sets, the `get_all_next_starts` method triggers with `self` containing `multiple recordsets`. https://github.com/odoo/enterprise/blob/5db989feb90086d14d5c3c4f8c0d2233f7029f21/planning/models/planning_recurrency.py#L181 This leads to the `ensure one` traceback, when the `id` is fetching through `self`, where `self ` contains multiple recordsets. https://github.com/odoo/enterprise/blob/5db989feb90086d14d5c3c4f8c0d2233f7029f21/planning/models/planning_recurrency.py#L119-L120 After applying this commit will resolve this issue. sentry-5447858210 Forward-Port-Of: odoo/enterprise#63959
Steps: - Install helpdesk_timesheet - In Kanban View > Start the timer of a ticket Issue: - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But for the tickets , if we start a timer, the ticket_id is not set in the timer header with in the new ticket. Cause: - Due to the condition given in the `action_start_new_timesheet_timer`, there is no helpdesk_ticket_id mentioned in that function. Fix: - B
Original PR description
Steps: - Install helpdesk_timesheet - In Kanban View > Start the timer of a ticket Issue: - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But for the tickets , if we start a timer, the ticket_id is not set in the timer header with in the new ticket. Cause: - Due to the condition given in the `action_start_new_timesheet_timer`, there is no helpdesk_ticket_id mentioned in that function. Fix: - By extending the `_get_new_timesheet_timer_vals` to the helpdesk_timesheet module to gave helpdesk_ticket_id the issue will be solved. task-3970176 Forward-Port-Of: odoo/enterprise#67294 Forward-Port-Of: odoo/enterprise#64359
When opening the shopfloor from a specific workcenter, workorder or production order, only the concerned workcenter should be shown. task-4060857 Forward-Port-Of: odoo/enterprise#66923
Original PR description
When opening the shopfloor from a specific workcenter, workorder or production order, only the concerned workcenter should be shown. task-4060857 Forward-Port-Of: odoo/enterprise#66923
Steps: Login as portal, and to to a task form, page sub-tasks. Make Customer column visible. Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The field is invisible if `allow_billable` and `is_fsm` are False. A child task inherits both from its parent, but this one hasn't been created yet. Solution: In this case, the condition is not needed. If we create the child and he has both fields to False, it means its parent too. Yet the `partner_
Original PR description
Steps: Login as portal, and to to a task form, page sub-tasks. Make Customer column visible. Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The field is invisible if `allow_billable` and `is_fsm` are False. A child task inherits both from its parent, but this one hasn't been created yet. Solution: In this case, the condition is not needed. If we create the child and he has both fields to False, it means its parent too. Yet the `partner_id` column is invisible if it is the case. So the solution is simple: remove the condition. related: https://github.com/odoo/odoo/pull/174323 task-3713729 Forward-Port-Of: odoo/enterprise#67252
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and
Original PR description
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and task are in italic font. - The last letter of the project and task name is slightly cut. ### Issue: The last letter of the string is slightly cut in the timesheet grid view. ### Cause: The dedicated space allowed for normal text is not sufficient for the italic. So, the last letter was slightly cut. ### Solution: Provide an extra space to the italic string. task-3888277 Forward-Port-Of: odoo/enterprise#63786
Before this commit, some Markup were missing in some post message which resulted in some html to be displayed in the chatter. task: 4041892 Community: https://github.com/odoo/odoo/pull/173375 Forward-Port-Of: odoo/enterprise#67255 Forward-Port-Of: odoo/enterprise#66767
Original PR description
Before this commit, some Markup were missing in some post message which resulted in some html to be displayed in the chatter. task: 4041892 Community: https://github.com/odoo/odoo/pull/173375 Forward-Port-Of: odoo/enterprise#67255 Forward-Port-Of: odoo/enterprise#66767
In this PR: Hide the `Timesheet Init Amount` and `Timesheet unit Amount` fields from the pivot and graph views. task-3970176 Forward-Port-Of: odoo/enterprise#64649
Original PR description
In this PR: Hide the `Timesheet Init Amount` and `Timesheet unit Amount` fields from the pivot and graph views. task-3970176 Forward-Port-Of: odoo/enterprise#64649