Wednesday, July 13, 2022
30 changes · master
Enhancements to existing features
The purchase dashboard has been updated from an older table layout to a cleaner, more modern grid layout. This improves the visual presentation and removes unnecessary styling code, making the interface easier to maintain.
Original PR description
Prior to this commit, the dashboard was a table and there was unnecessary scss. This commit changes the table into the new bs5 grids and clean the scss files. task-2906527 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web interface now restores an option that lets users edit domain filters in a dedicated dialog instead of directly in the field. This makes complex filter setup easier and aligns the newer interface with behavior available in the older version.
Original PR description
In legacy, the domain field had an `in_dialog` option that was used to display a button that opens a dialog to edit the value. This commit reimplements the `DomainSelectorDialog` in owl and adds the option the new domain field.
Adds a new task button that shows how many planned hours still need scheduling and opens Planning with helpful filters. This makes it easier for teams to complete task planning without leaving the task workflow.
Original PR description
…k form view This commit updates the "hours planned" stat button, which can be be found in the task form view when the planning app has been installed. Specifically, a new "hours to plan" stat button…
…k form view This commit updates the "hours planned" stat button, which can be be found in the task form view when the planning app has been installed. Specifically, a new "hours to plan" stat button is added, which displays the hours that have been initially planned for the task completion minus the hours that have been forecasted from the planning app. Clicking the button redirects the user to the planning app, but instead of the gantt to be filtered by the task, it is filtered by the assignee so that the remaining hours are planned. If the task doesn't have an assignee, but it is generated through a sale order, the gantt will be filtered by the employees with the planning role indicated in the product form view. Finally, if the task is not generated through a sale order, the button will just redirect to the unfiltered planning gantt. The improvements that this task introduces aim at making planning more straightforward from the task view. Now, the user is able to see exactly the hours that still need to be planned, which ensures that no task is finished without all its allocated hours being planned. Additionally, the redirection and filterring from the new stat button ensures a simple and intuitive flow for the user, who will be able to complete the task's planning without needing to navigate to the planning app from the home screen. In order to implement these improvements, we had to modify the project_views.xml file as well as the project.py file in the project_forecast module. In the former, we added code in order for the new stat button to be displayed next to the original "hours planned" one. In the latter, we added code to compute the remaining hours that have not been yet planned (in order for them to be displayed on the button) and code for executing the redirection action and chosing which filtering to apply. We use two different ways to test the new improvements. First, we check the value reported on the stat button from the "test_remaining_forecast_hours()" test in the test_forecast.py file. Second, we use a tour to test the flow of switching between the task view and the planning gantt view. We defined the tour inside project_planning_tour.js and created a new test file test_forecast_ui.py from which we execute and test the tour.
Resolved issues and error corrections
The Settings screen now keeps the Save and Discard actions visually aligned when they appear inside a mobile dropdown. This makes the mobile settings experience cleaner and reduces confusion when users manage configuration changes on smaller screens.
Original PR description
In the settings view, on mobile the save and the discard button are wrapped in a dropdown. As the save button is primary and the discard is secondary when there are wrapped in the dropdown there are miss aligned as there padding are not the same. This commit, avoid to change the padding on mobile of these elements. Steps to reproduce: * Open Odoo (on Mobile) * Go in Settings * Open the dropdown => BUG -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
This change removes leftover website editor code that no longer served a useful purpose. Cleaning it up prevents it from interfering with ongoing improvements in the editor while keeping current behavior unchanged.
Original PR description
Commit [1] introduced some lines of code which added/removed the d-none class on the overlay handles in some context. Commit [2] later reviewed that code and removed the addition of the d-none class... but kept the removal part by mistake. It of course did not hurt at the time but now impacts new task being developed in master. [1]: https://github.com/odoo/odoo/commit/9bbe5be3fb0d995374a369851df3641979d8e553 [2]: https://github.com/odoo/odoo/commit/50cb0f3276819e22a6014bdb7895c7cbc0315ca8 Related to task-2825241
Miscellaneous changes
When in point_of_sale, the screen when getting out of the TicketScreen is the current order's screen. However, when all the orders are deleted, no new order is created, thus, pos crashes when clicking back button without manually creating a new order. With this fix, when the TicketScreen is closed (either by clicking an order, or clicking the TicketButton or clicking Back button), a new order is automatically created when there are no more orders. The sequence of the orders is also properl
Original PR description
When in point_of_sale, the screen when getting out of the TicketScreen is the current order's screen. However, when all the orders are deleted, no new order is created, thus, pos crashes when clicking back button without manually creating a new order. With this fix, when the TicketScreen is closed (either by clicking an order, or clicking the TicketButton or clicking Back button), a new order is automatically created when there are no more orders. The sequence of the orders is also properly tracked which is important in the fiscal data modules. TASK-ID: 2886099 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95649
This update adjusts the layout of the media selection dialog so fields line up more cleanly when several inputs appear on the same row. It helps make the editor interface easier to read and use, with no expected impact on business workflows.
Original PR description
Add some classes to improve the alignment. Quite difficult to deal with as we have a lot of inputs on the same line. Follow of odoo/odoo#95725 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an internal sales module test that could fail when the Sales app is installed by itself. It ensures the test user has the right access to update units of measure, helping keep automated quality checks reliable without changing customer-facing behavior.
Original PR description
When `sale` is installed alone,
the test fails because it changes the field `product_uom`
which is invisible in the view because the user executing the test
doesn't have the appropriate group.
```
FAIL: TestSaleOrder.test_fiscalposition_application
Traceback (most recent call last):
File "/data/build/odoo/addons/sale/tests/test_sale_pricelist.py", line 292, in test_fiscalposition_application
line.product_uom = uom
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field product_uom
```This update adjusts an internal test so it works correctly when only the accounting accountant module is installed. It helps keep automated checks reliable and prevents false failures during development or upgrades.
Original PR description
This is about the same than
d6ad39abba12d8da302e0ecc9c24e064b1768300
but with account_accountant installed
```
FAIL: TestFormCreate.test_create_res_partner
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_form_create.py", line 35, in test_create_res_partner
partner_form.property_account_payable_id = property_account_payable_id
File "/data/build/odoo/odoo/tests/common.py", line 2179, in __setattr__
assert not self._get_modifier(field, 'invisible'), \
AssertionError: can't write on invisible field property_account_payable_id
```A bug in expense splitting prevented users from selecting all eligible purchase taxes in some cases. This fix removes that limitation so split expense lines follow the same tax handling as regular expenses.
Original PR description
Task 2850882 modified the behaviour of expenses to support working with all purchase taxes, regardless of their 'price included' configuration. We missed a domain on the split lines though, so it was impossible to use 'all taxes' when splitting an expense. This commit resolves that limitation/oversight.
The web interface now better recognizes filter operators when displaying domain selector rules. This prevents confusing placeholders from appearing, so users see clear filter descriptions such as "Name like M" instead of an unknown operator.
Original PR description
Before this commit, it happened that the domain selector couldn't find the operator linked to the field. This commit adds a fallback on the existing operators to find an operator that matches. for example the domain `[["name", "like", "M"]]` gave `Name ? "M"`, now it correctly gives `Name like "M"`.
This fix restores the intended visual styling for the accounting journal dashboard after a previous change caused the custom layout to stop applying correctly. It helps users see the dashboard as designed, improving consistency and readability without changing business workflows.
Original PR description
Since 4f984568e139d8da448018af12ef79005e317cf6, the specific css style was not applied correctly to the journal dashboard.
Fixes an invoicing issue where orders containing note or section lines could fail if no account was specified for those non-financial lines. This helps users create invoices from such orders more reliably without requiring extra hidden accounting values.
Original PR description
When an invoice line has a display_type, account addon is expecting account_id=False in vals. Replacing the normal dict access with a `get` will fix the error when invoicing with note/section lines without explicitly specifying the `account_id` to be false. **Old description which is still relevant:** When an orderline has a note, invoicing fails because of missing account_id key in the invoice line vals. For notes and section lines to work, we need to explicitly specify that the account_id is false. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The account setup screens now show the account type selector correctly again after recent changes to account type handling. This helps accounting users choose valid account categories without confusion or broken interface behavior.
Original PR description
Task 2917456 After the change in the account_type field in the account.account, the old selection widget didn't work. Fixing the selection widget and adding it back to the account_type field. As account types cannot be custom anymore, the account types within the hierarchy can be hardcoded. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores a payroll processing method that was accidentally removed from Belgian payroll. It prevents issues in the related attendance payroll module that depends on this behavior.
Original PR description
…method PR https://github.com/odoo/enterprise/pull/25998 inadvertenly removed the _preprocess_work_hours_data_split_half method in the hr_contract model in l10n_be_hr_payroll. The method is overriden in l10n_be_hr_payroll_attendance and thus required
The payment matching screen has been corrected to use the updated account type names introduced by recent accounting changes. This prevents the matching view from breaking when users reconcile receivable or payable payments.
Original PR description
Task 2916588 Due to the recent account types refactoring, the payment matching view was breaking, as now receivable should be asset_receivable, payable -> liability_payable Fix to correct values
Description of the issue/feature this PR addresses: When the user opens a document from the chat channel, the system opened the document, but the chat window is still there and covers the document. Current behavior before PR: Will hide all chat window when open document Desired behavior after PR is merged: https://user-images.githubusercontent.com/55737816/177705066-1a5e82f9-98bd-4866-b4dd-aeaa67ed1b6d.mov -- I confirm I have signed the CLA and read the PR guidelines at www.
Original PR description
Description of the issue/feature this PR addresses: When the user opens a document from the chat channel, the system opened the document, but the chat window is still there and covers the document. Current behavior before PR: Will hide all chat window when open document Desired behavior after PR is merged: https://user-images.githubusercontent.com/55737816/177705066-1a5e82f9-98bd-4866-b4dd-aeaa67ed1b6d.mov -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95873 Forward-Port-Of: odoo/odoo#95485
Actually it is not possible to add manually a printer. With this commit we loop into all printer recorded in cups to check if a printer is not automatically added. If a printer does not match with a identifier automaticcaly generated, it is added to the list of usable printer. 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/su
Original PR description
Actually it is not possible to add manually a printer. With this commit we loop into all printer recorded in cups to check if a printer is not automatically added. If a printer does not match with a identifier automaticcaly generated, it is added to the list of usable printer. 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#82964
Steps to reproduce the bug: - Install `”purchase_product_matrix”` - Go to the purchase settings and enable “Product Packagings” option - Create a storable product “P1” with attributes: - Configure a package in each of the variants - Create a PO: - Select the product “P1”: - on the grid product configurator: Add quantity set on Package - Confirm Problem: The chosen quantity must be automatically put in a package, but as we are in the case of a grid, the `_onch
Original PR description
Steps to reproduce the bug:
- Install `”purchase_product_matrix”`
- Go to the purchase settings and enable “Product Packagings” option
- Create a storable product “P1” with attributes:
- Configure a package in each of the variants
- Create a PO:
- Select the product “P1”:
- on the grid product configurator: Add quantity set on Package
- Confirm
Problem:
The chosen quantity must be automatically put in a package,
but as we are in the case of a grid, the `_onchange_suggest_packaging`
is not triggered automatically, and therefore the package is not set.
Solution:
We have to trigger the onchange manually in the grid case
opw-2896050
https://user-images.githubusercontent.com/78867936/177765933-9d989f8b-be14-4880-87cc-702f3df6ed20.mp4
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#95530Before this commit, patching a getter of a class made it enumerable (`Object.keys({ a: 1 })` -> `["a"]`). In javascript, getters of a class are not enumerable but getters of an object are enumerable. When patching, the system replaced the descriptor of the old class member by the member of the object. Now, it replaces some info of the old descriptor by the new descriptor but not the entire descriptor. Forward-Port-Of: odoo/odoo#95766
Original PR description
Before this commit, patching a getter of a class made it enumerable
(`Object.keys({ a: 1 })` -> `["a"]`).
In javascript, getters of a class are not enumerable but
getters of an object are enumerable.
When patching, the system replaced the descriptor of the old class
member by the member of the object.
Now, it replaces some info of the old descriptor by the new descriptor
but not the entire descriptor.
Forward-Port-Of: odoo/odoo#95766Reproduction: 1. Create an invoice, then save and confirm it 2. Print the invoice 3. The CSS spacing does not work in the PDF report Reason: V13 uses Bootstrap 3 but Odoo V14 uses Bootstrap 4. In Bootstrap 4, the margin class is defined in a different way. To fix the missing issue of mt32 (margin-top:32px), a customized class named mt32 is created in report.scss opw-2654880 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o
Original PR description
Reproduction: 1. Create an invoice, then save and confirm it 2. Print the invoice 3. The CSS spacing does not work in the PDF report Reason: V13 uses Bootstrap 3 but Odoo V14 uses Bootstrap 4. In Bootstrap 4, the margin class is defined in a different way. To fix the missing issue of mt32 (margin-top:32px), a customized class named mt32 is created in report.scss opw-2654880 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#95791 Forward-Port-Of: odoo/odoo#83860
Manual FW of 0f096edaa597b1125388437feb9c68f7ba985d39 (The FW has been disturbed because of the interruption of saas-15.1 #95478) Forward-Port-Of: odoo/odoo#95753
Original PR description
Manual FW of 0f096edaa597b1125388437feb9c68f7ba985d39 (The FW has been disturbed because of the interruption of saas-15.1 #95478) Forward-Port-Of: odoo/odoo#95753
Filter the cancelled entries when displaying unreconciled entries in manual reconciliation widget. Steps: - Create an invoice, confirm and register payment - Go to the journal entry JE related to the payment - Reset to draft and cancel JE - Go to Accounting->Reconciliation->Check all unreconciled entries -> The journal item related to JE is displayed, it should not be We add a filter to the context in order to filter draft and cancelled entries in the view. opw-2742085 Forward
Original PR description
Filter the cancelled entries when displaying unreconciled entries in manual reconciliation widget. Steps: - Create an invoice, confirm and register payment - Go to the journal entry JE related to the payment - Reset to draft and cancel JE - Go to Accounting->Reconciliation->Check all unreconciled entries -> The journal item related to JE is displayed, it should not be We add a filter to the context in order to filter draft and cancelled entries in the view. opw-2742085 Forward-Port-Of: odoo/enterprise#29415
Have an invoice with total 258.50 Create a bank statement for a higher amount Open reconciliation widget Add the invoice Click the pencil icon on the invoice line, input 258.49 The amount will be unchanged(258.50) This occurs because the _amountCompare js function will detect the amouts as equal, because 258.49 - 258.5 = -0.00999999999... As result, the check Math.abs(delta) < epsilon (with epsilon 0.01) will succeed (not ok) This commit add a `toFixed` step to increase the accur
Original PR description
Have an invoice with total 258.50 Create a bank statement for a higher amount Open reconciliation widget Add the invoice Click the pencil icon on the invoice line, input 258.49 The amount will be unchanged(258.50) This occurs because the _amountCompare js function will detect the amouts as equal, because 258.49 - 258.5 = -0.00999999999... As result, the check Math.abs(delta) < epsilon (with epsilon 0.01) will succeed (not ok) This commit add a `toFixed` step to increase the accuracy of the method opw-2853050 Forward-Port-Of: odoo/enterprise#29258 Forward-Port-Of: odoo/enterprise#29179
see https://developer-docs.amazon.com/sp-api/docs/orders-api-v0-reference#orderitemlist  ### OPW: 2916767 Forward-Port-Of: odoo/enterprise#29416 Forward-Port-Of: odoo/enterprise#29340
Original PR description
see https://developer-docs.amazon.com/sp-api/docs/orders-api-v0-reference#orderitemlist  ### OPW: 2916767 Forward-Port-Of: odoo/enterprise#29416 Forward-Port-Of: odoo/enterprise#29340
The test api key is no longer active. The new one was created on 2022-07-05 (july 5). Also, `TestEasypostRequest` needs to be tagged as external since it uses `setUp` from its parent `EasypostTestCommon`, which calls the API. Forward-Port-Of: odoo/enterprise#29355
Original PR description
The test api key is no longer active. The new one was created on 2022-07-05 (july 5). Also, `TestEasypostRequest` needs to be tagged as external since it uses `setUp` from its parent `EasypostTestCommon`, which calls the API. Forward-Port-Of: odoo/enterprise#29355
When multilocation is active, a barcode operation can have multiple pages: one for each location. Before this commit, these pages were sorted by their location's id which isn't the more convenient way for the user who suspects the page to be sorted by location's name. How to reproduce: - Enable "Storage Locations" (inventory settings); - Create the following locations in this order, as children of your stock location: - Room B; - Room C; - Room A. - Create a new produ
Original PR description
When multilocation is active, a barcode operation can have multiple pages: one for each location.
Before this commit, these pages were sorted by their location's id which isn't the more convenient way for the user who suspects the page to be sorted by location's name.
How to reproduce:
- Enable "Storage Locations" (inventory settings);
- Create the following locations in this order, as children of your stock location:
- Room B;
- Room C;
- Room A.
- Create a new product and for this product, add 1 qty. in each of those newly creaed locations;
- Create a delivery for 3 of this product, confirm and reserve;
- Open the delivery is the Barcode App
-> The pages' order is Room B -> Room C -> Room A.
The expected order is Room A -> Room B -> Room C.
task-2816768
Forward-Port-Of: odoo/enterprise#29347
Forward-Port-Of: odoo/enterprise#25897Currently, if you change the language and then go to Accounting > Reporting > General Ledger and click on one entry > Annotate, the dialog box that appears is not translated. This happens because _t() is not called on the appropriate strings. This commit fixes the issue by adding _t() calls where needed. opw-2831616 Forward-Port-Of: odoo/enterprise#29372
Original PR description
Currently, if you change the language and then go to Accounting > Reporting > General Ledger and click on one entry > Annotate, the dialog box that appears is not translated. This happens because _t() is not called on the appropriate strings. This commit fixes the issue by adding _t() calls where needed. opw-2831616 Forward-Port-Of: odoo/enterprise#29372
When removing the emoji of an article, the emoji is removed from the article display name in the sidebar, which makes it difficult to select a new one (small button showed on hover). When reloading or selecting another article, the default file icon reappears. Now, when removing an emoji, the emoji is directly set to the default file icon in the sidebar to avoid having this small hidden button. Task-2905851 Forward-Port-Of: odoo/enterprise#29354
Original PR description
When removing the emoji of an article, the emoji is removed from the article display name in the sidebar, which makes it difficult to select a new one (small button showed on hover). When reloading or selecting another article, the default file icon reappears. Now, when removing an emoji, the emoji is directly set to the default file icon in the sidebar to avoid having this small hidden button. Task-2905851 Forward-Port-Of: odoo/enterprise#29354
Reuse an empty order that doesn't belong to any partner or belongs to the selected partner when settling partner's due. TASK-ID: 2886099 Forward-Port-Of: odoo/enterprise#29275
Original PR description
Reuse an empty order that doesn't belong to any partner or belongs to the selected partner when settling partner's due. TASK-ID: 2886099 Forward-Port-Of: odoo/enterprise#29275