Tuesday, April 16, 2024
15 changes · master
Enhancements to existing features
This update adds broader automated checks to make sure the timesheet leaderboard behaves correctly across timer, grid, list, kanban, and holiday-related scenarios. It helps reduce the risk of ranking or display issues reaching users, improving confidence in timesheet reporting.
Original PR description
This commit will add a certain number of tests to ensure that the timesheets leaderboard works properly. task-3570306
Features or functions removed from Odoo
The subscription-specific warning for archived products was removed because this check is now handled in the main Sales app. This avoids duplicate warnings and keeps the subscription workflow aligned with the broader sales process.
Original PR description
The feature has been moved to the `sale` module. task-3757933
Miscellaneous changes
Issue --> When creating a POS order via any pos config, any active preparation display that has any of the product categories used in the order will cause the customer display to reload. This happens regardless of the `pos_config_ids` set on the preparation display record. Therefore, an order from a `pos.config` **not** on the preparation display will still cause the display to reload Solution --> Edit the search domain on `pos_preparation_display.display` to check the origin of the ord
Original PR description
Issue --> When creating a POS order via any pos config, any active preparation display that has any of the product categories used in the order will cause the customer display to reload. This happens regardless of the `pos_config_ids` set on the preparation display record. Therefore, an order from a `pos.config` **not** on the preparation display will still cause the display to reload Solution --> Edit the search domain on `pos_preparation_display.display` to check the origin of the order to keep the display from reloading unnecessarily. opw-3838879 Forward-Port-Of: odoo/enterprise#60575
Commit 2740da2701557da09566aa25f064fe3cac7a881a modified a mail template's subject, which is translatable. Update the .pot file to reflect the change. opw-3748509 Forward-Port-Of: odoo/enterprise#60820
Original PR description
Commit 2740da2701557da09566aa25f064fe3cac7a881a modified a mail template's subject, which is translatable. Update the .pot file to reflect the change. opw-3748509 Forward-Port-Of: odoo/enterprise#60820
It is not working because some issues with AFIP test envrionment that added new restrictions that need to adapt- In this case we depend on AFIP to solve it and we do not know when we will have a solution. After everything is ok we will re add the test. Forward-Port-Of: odoo/enterprise#60577
Original PR description
It is not working because some issues with AFIP test envrionment that added new restrictions that need to adapt- In this case we depend on AFIP to solve it and we do not know when we will have a solution. After everything is ok we will re add the test. Forward-Port-Of: odoo/enterprise#60577
Follow-up of 0fd53102589e2bdc4d4a257f367a37eca88604c8 The mail template 'Helpdesk: Ticket Received' should also use the `name` instead of the `display_name` for emails all emails to be properly grouped. opw-3748509 Forward-Port-Of: odoo/enterprise#60242
Original PR description
Follow-up of 0fd53102589e2bdc4d4a257f367a37eca88604c8 The mail template 'Helpdesk: Ticket Received' should also use the `name` instead of the `display_name` for emails all emails to be properly grouped. opw-3748509 Forward-Port-Of: odoo/enterprise#60242
Work order can be start by employee, in scenario when creating new company there is no employees added by default, hence the work order can't be started. This commit is added an error message informing about it. ### [Reproduce] - Install: mrp,account - Create a new company, Select it - Update Settings: - Enable "work orders" (Settings/Manufacturing/Operations) - Set "Generic Chart Template" (Accounting/ Settings/ Fiscal Localization) - Create a new Manufacturing Order (Manufacturing/
Original PR description
Work order can be start by employee, in scenario when creating new company there is no employees added by default, hence the work order can't be started. This commit is added an error message informing about it. ### [Reproduce] - Install: mrp,account - Create a new company, Select it - Update Settings: - Enable "work orders" (Settings/Manufacturing/Operations) - Set "Generic Chart Template" (Accounting/ Settings/ Fiscal Localization) - Create a new Manufacturing Order (Manufacturing/ Operations/ Manufacturing Orders) - Select any product - Create a work order line - Confirm Manufacturing Order - Click on the start button in the operation line - BUG: Timer not timing opw-3770873 Forward-Port-Of: odoo/enterprise#60551 Forward-Port-Of: odoo/enterprise#59969
**Current behavior:** Adding a product to a POS order then zero-ing out the quantity of the line will result in an instance of division with this qty (now zero) in the denominator. **Expected behavior:** Don't allow a scenario to occur where 0 can appear in the denominator of a division operation. **Steps to reproduce:** 1. Switch to the demo German company installed with `l10n_de_pos_res_cert` 2. Enable Fiskaly in the company settings for the German company 3. Add
Original PR description
**Current behavior:** Adding a product to a POS order then zero-ing out the quantity of the line will result in an instance of division with this qty (now zero) in the denominator. **Expected…
**Current behavior:**
Adding a product to a POS order then zero-ing out the quantity
of the line will result in an instance of division with this qty
(now zero) in the denominator.
**Expected behavior:**
Don't allow a scenario to occur where 0 can appear in the
denominator of a division operation.
**Steps to reproduce:**
1. Switch to the demo German company installed with
`l10n_de_pos_res_cert`
2. Enable Fiskaly in the company settings for the German
company
3. Add a payment method in the POS config
3. Add a POS of type Restaurant and enable the TSS toggle
setting (comment out the `_l10n_de_fiskaly_iap_rpc()` call
in `l10n_de_pos_cert/models/pos_config.py` to save)
4. Add a floor and a table to the restaurant
5. Start a POS session and start an order, add some product
then select the order line and zero out the quantity with
the digital numpad
6. Go to payment -> register payment -> validate
7. Observe the error dialog
**Cause of the issue:**
In `l10n_de_pos_res_cert/models/pos_order.py`, the
`remove_from_ui` method calls `_line_differences()` if fiskaly
is setup for our German company which makes the call to
`_merge_order_lines()` where the following operation:
`str(group[0]['price_subtotal_incl']/group[0]['qty'])` may have
a denominator equal to 0.
**Fix:**
Do not call `_merge_order_lines()` on order lines which have a
quantity of zero.
opw-3751492
Forward-Port-Of: odoo/enterprise#60097Purpose ======= Since a recent update, the number of caracters for rule parameter Canton (ZG) - Church _tax (N) - Tax Scale (B) - Children (0) is exceeding the default buffer size, leading to a traceback on file import. Forward-Port-Of: odoo/enterprise#60716
Original PR description
Purpose ======= Since a recent update, the number of caracters for rule parameter Canton (ZG) - Church _tax (N) - Tax Scale (B) - Children (0) is exceeding the default buffer size, leading to a traceback on file import. Forward-Port-Of: odoo/enterprise#60716
**Before this commit** At the start of a pill resize sequence, if you go fast and your pointer enters an adjacent pill right before the sequence starts you may end up resizing the wrong record. **After this commit** The draggable_hook_builder has been improved in order to inform us when a drag sequence will start. We take advantage of this in order to fix the above issue. Forward-Port-Of: odoo/enterprise#60662 Forward-Port-Of: odoo/enterprise#60328
Original PR description
**Before this commit** At the start of a pill resize sequence, if you go fast and your pointer enters an adjacent pill right before the sequence starts you may end up resizing the wrong record. **After this commit** The draggable_hook_builder has been improved in order to inform us when a drag sequence will start. We take advantage of this in order to fix the above issue. Forward-Port-Of: odoo/enterprise#60662 Forward-Port-Of: odoo/enterprise#60328
Purpose ======= Add unit tests for the document activity view Test the fix of document archiving in the activity view PR: odoo/odoo/pull/151741 Task: 3704340 Load the services in a utils function to remove code redundancy. Task-3714544 Forward-Port-Of: odoo/enterprise#60614 Forward-Port-Of: odoo/enterprise#60140
Original PR description
Purpose ======= Add unit tests for the document activity view Test the fix of document archiving in the activity view PR: odoo/odoo/pull/151741 Task: 3704340 Load the services in a utils function to remove code redundancy. Task-3714544 Forward-Port-Of: odoo/enterprise#60614 Forward-Port-Of: odoo/enterprise#60140
The NHIF and AHL computation were not correct because they were based on the gross salary instead of the basic salary. task-3827167 Forward-Port-Of: odoo/enterprise#59518
Original PR description
The NHIF and AHL computation were not correct because they were based on the gross salary instead of the basic salary. task-3827167 Forward-Port-Of: odoo/enterprise#59518
Currently when auditing entries in the deferred report, you get a list of AMLs (journal items), but can't change the view. It is useful though to use other views, like the pivot view e.g. For this reason we let the user choose to switch between any view available in the generic Journal Items list. (Feedback from TSB) Forward-Port-Of: odoo/enterprise#53079
Original PR description
Currently when auditing entries in the deferred report, you get a list of AMLs (journal items), but can't change the view. It is useful though to use other views, like the pivot view e.g. For this reason we let the user choose to switch between any view available in the generic Journal Items list. (Feedback from TSB) Forward-Port-Of: odoo/enterprise#53079
Before this commit, the timesheets created inside `test_timesheet_ticket_consistency_when_helpdesk_team_change` and `test_timesheet_check_warning_when_helpdesk_team_change` tests could be unvalidated even after calling `action_timesheet_validate`. The reason is because the timesheets are created by the current user (OdooBot) is our case and his timezone could be different than the user who validates the timesheets and so the timesheets date could be tomorrow for the timesheet approver used
Original PR description
Before this commit, the timesheets created inside `test_timesheet_ticket_consistency_when_helpdesk_team_change` and `test_timesheet_check_warning_when_helpdesk_team_change` tests could be unvalidated even after calling `action_timesheet_validate`. The reason is because the timesheets are created by the current user (OdooBot) is our case and his timezone could be different than the user who validates the timesheets and so the timesheets date could be tomorrow for the timesheet approver used inside that test becaue of the timezone is not the same for the both users. To avoid timezone issue, this commit makes sure the same user creates and validates those timesheets since the goal of that test is to check the `project_id` field is unchanged for validated timesheets even if the ticket changed. runbot-61592 Forward-Port-Of: odoo/enterprise#60502
Steps to reproduce: ----------------- - install project module - create new project - click on project,and click on see examples button - click on use this for my project - create tasks and click on list view - unhide the start date and end date - give start date and end date for more than 1 records Issue: - Bug when mass editing the task's date_deadline (always showing the wrong date for one of the records) Cause: - this is because the for single record it is not accepting work
Original PR description
Steps to reproduce: ----------------- - install project module - create new project - click on project,and click on see examples button - click on use this for my project - create tasks and click on list view - unhide the start date and end date - give start date and end date for more than 1 records Issue: - Bug when mass editing the task's date_deadline (always showing the wrong date for one of the records) Cause: - this is because the for single record it is not accepting work intervals Solution: - by giving condition using len then issue will be solved task-3561946 Forward-Port-Of: odoo/enterprise#60748 Forward-Port-Of: odoo/enterprise#53164