Daily updates from Odoo
Tuesday, August 6, 2024
12 changes · master
Enhancements to existing features
The Barcode app interface has been refreshed across menus, operation lists, and line details to make warehouse work clearer and faster. Users can now delete added lines directly, see product images without opening details, scan continuously with the camera, and avoid disruptive sound playback errors.
Original PR description
## Description This commit heavily rewrites the Barcode app design. Functionally, there is only a few changes: - Added barcode lines can be deleted directly from the barcode lines page, no need to…
## Description This commit heavily rewrites the Barcode app design. Functionally, there is only a few changes: - Added barcode lines can be deleted directly from the barcode lines page, no need to open the form view anymore; - The conditions to display/hide line's buttons changed; - If the product has an image, it's directly visible on the line (no need to open the form view to see it.) If clicked, the image is displayed in fullscreen. ## Comparison Here some pictures to compare both versions: ### Main menu   ### Operations list   ### Client action   ### Form view   ## References Designed-by: @mano-odoo Co-authored-by: @stefanorigano [task-3929927](https://www.odoo.com/odoo/project.task/3929927?cids=1) Community PR: odoo/odoo#167942 Upgrade PR: odoo/upgrade#6249
The option to include e-invoices in GSTR1 filings is now tracked when it is changed. This helps businesses keep a clearer audit trail and maintain consistency during GSTR1 submission activities.
Original PR description
before this commit: `gstr1_include_einvoice` field can be enabled/disabled before/after pushing GSTR1 status after this commit: `gstr1_include_einvoice` is now trackable to maintain consistency and maintain logs while pushing GSTR1
Accounting reports can now be configured so users can adjust several filters before refreshing the report. This helps companies with large databases avoid repeated waiting times while keeping the current instant-refresh behavior as the default for others.
Original PR description
Add a feature that enables companies to select multiple filters in an accounting report before reloading the data of the report. This feature can be activated by selecting the boolean field 'Deferred…
Add a feature that enables companies to select multiple filters in an accounting report before reloading the data of the report. This feature can be activated by selecting the boolean field 'Deferred options reload' in the form view of the accounting report. On any report, as it is now, the whole report gets refreshed when giving a value to a single option filter. It is very nice on small databases, but on bigger ones might sometimes make the flow more painful for the user if she needs to change the value of multiple filters (e.g. select a journal => wait 10 seconds for the reload => select a partner => wait 10 more seconds). For those big databases, we'd like to have the possibility to have a button under the filters triggering the recompute of the report; hence not doing it immediately when an option is checked. However, we don't want that for all the dbs, as it would then add one click for all the users of small databases, who don't have any issue. Therefore, the chosen solution is rather to support both cases, and add a boolean option on the account.report (in the form view) allowing to switch to this "deferred computation mode". By default, it won't be enabled, and the historical behavior will apply. task-3263762
Resolved issues and error corrections
The follow-up report address layout has been adjusted so mailed letters meet Pingen's formatting requirements. This helps ensure customer follow-up letters can be processed correctly by the snail mail service.
Original PR description
Moves the address to fit Pingen requirement by applying the class associated styling. Community PR: https://github.com/odoo/odoo/pull/174635 task-4076930
This change improves how manufacturing work orders record consumed quantities, helping ensure materials are marked and counted correctly when production is completed. It also cleans up related inventory tests and fixes a barcode manufacturing form check to avoid incorrect matches.
Original PR description
# ARCHIVED PR That's pull request was splited in two separate prs `PART 1`: https://github.com/odoo/enterprise/pull/67683 `PART 2`: https://github.com/odoo/enterprise/pull/67684 ## mrp_workorder: fix…
# ARCHIVED PR That's pull request was splited in two separate prs `PART 1`: https://github.com/odoo/enterprise/pull/67683 `PART 2`: https://github.com/odoo/enterprise/pull/67684 ## mrp_workorder: fix quantity consumed operation With the new way of computing the quantity consumed, it is no longer necessary to mark the move_raw_ids in this function, since we call button_finish method right after. In button_finish, we take responsability for marking it as picked and updating the quantity consumed ## clean up _post_inventory tests This commit add 2 simple refactor to our existing tests, they are: -> _post_inventory calling button_mark_done() will call _post_inventory, so, it is not needed to call _post_inventory to test the flow. -> consumed quantities Fixing some tests to make sure that the current flow will not mark the picked as box when we change the quantity produced. ## stock_barcode_mrp: fix misstyping on saveFormView Before the commit, the condition inside saveFormView was returning True, because the same content was fit in two diferents types. The fix for it was just assert the id and the name of the content. task: 3810344
This fixes a mislabeled placeholder in the payroll salary rule setup so it uses the correct quantity field name. It helps prevent confusion or errors when configuring payroll calculations.
Original PR description
result_quantity is actually called result_qty so the placeholder should reflect that.
Miscellaneous changes
After making changes in community PR: https://github.com/odoo/odoo/pull/161705 The datetime widget was not being applied when we dragged and dropped a datetime field from the studio. Steps to reproduce: - Open the Sales module and toggle Studio. - Drag and drop a datetime field into the list view. - Try to tick and untick the Show time option. Observed behavior: When ticking and unticking the show time option, the time part is not hiding before resetting the widget. Expected be
Original PR description
After making changes in community PR: https://github.com/odoo/odoo/pull/161705 The datetime widget was not being applied when we dragged and dropped a datetime field from the studio. Steps to reproduce: - Open the Sales module and toggle Studio. - Drag and drop a datetime field into the list view. - Try to tick and untick the Show time option. Observed behavior: When ticking and unticking the show time option, the time part is not hiding before resetting the widget. Expected behavior: The time part should be hidden when we tick and untick the show time option without resetting the widget. After this commit, the datetime widget will be applied when we drag and drop a datetime field from the studio and untick the show time boolean. Task-3698841 Forward-Port-Of: odoo/enterprise#67843 Forward-Port-Of: odoo/enterprise#67258
Steps ----- [Planning] - Create a shift from 1 July 2024 -> 31 July 2024 and chose the option to repeat it every month. Save it. 1st issue: no shift is created in September. 2nd issue: November shift ends in December and overlaps with December shift. Cause ----- - The 1st issue is caused by the first day of the September shift being on a weekend. In case the first day is not a working day, a shift will only be generated if the first day of the original shift was outside working days.
Original PR description
Steps ----- [Planning] - Create a shift from 1 July 2024 -> 31 July 2024 and chose the option to repeat it every month. Save it. 1st issue: no shift is created in September. 2nd issue: November shift…
Steps ----- [Planning] - Create a shift from 1 July 2024 -> 31 July 2024 and chose the option to repeat it every month. Save it. 1st issue: no shift is created in September. 2nd issue: November shift ends in December and overlaps with December shift. Cause ----- - The 1st issue is caused by the first day of the September shift being on a weekend. In case the first day is not a working day, a shift will only be generated if the first day of the original shift was outside working days. https://github.com/odoo/enterprise/blob/079b0ba241b8b4f7fbd74775e5fc43b27ca3c8fd/planning/models/planning_recurrency.py#L104-L107 - The 2nd issue happens because the length of all the repeated shifts is the same than the original shift. In the case of a longer original month, this will create overlapping generated shifts when we get to shorter months. Introduced by 079b0ba241b8b4f7fbd74775e5fc43b27ca3c8f Fix ----- - Consider a shift with any day (and not just the starting one) outside of working days as being outside working days. - Adapt the length of the generated shifts in case of a monthly recurrence. Take the minimum between the original shift duration in days and the number of days in the month. opw-3996123 Forward-Port-Of: odoo/enterprise#66408
In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828 Forward-Port-Of: odoo/enterprise#67839 Forward-Port-Of: odoo/enterprise#67168
Original PR description
In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828 Forward-Port-Of: odoo/enterprise#67839 Forward-Port-Of: odoo/enterprise#67168
Fix singleton error Steps: - Go to follow-up report - Select 2 partners in the list view - Select "Print Customer Statements" in the action menu -> Singleton error opw-4075655 Forward-Port-Of: odoo/enterprise#67610
Original PR description
Fix singleton error Steps: - Go to follow-up report - Select 2 partners in the list view - Select "Print Customer Statements" in the action menu -> Singleton error opw-4075655 Forward-Port-Of: odoo/enterprise#67610
Currently, log level error message occur when no company is found during scheduled actions run at line [1]. This commit changes 'logger.error' to 'logger.warning' to log a message instead of an error since this is not an actual error in the code base. [1]-https://github.com/odoo/enterprise/blob/ddc81ed35a6738739647db868c13236673695cff/l10n_ke_edi_oscu/models/res_company.py#L437-L438 sentry-5608113473 Forward-Port-Of: odoo/enterprise#66799
Original PR description
Currently, log level error message occur when no company is found during scheduled actions run at line [1]. This commit changes 'logger.error' to 'logger.warning' to log a message instead of an error since this is not an actual error in the code base. [1]-https://github.com/odoo/enterprise/blob/ddc81ed35a6738739647db868c13236673695cff/l10n_ke_edi_oscu/models/res_company.py#L437-L438 sentry-5608113473 Forward-Port-Of: odoo/enterprise#66799
The cancel_shipment method name is incorrect, due to the leading _ which causes it to not be picked up when cancelling a picking. This means that starshipit packages do not get archived automatically when cancelling then in Odoo, as you would expect them to be. Task id # 4074169 Forward-Port-Of: odoo/enterprise#67927
Original PR description
The cancel_shipment method name is incorrect, due to the leading _ which causes it to not be picked up when cancelling a picking. This means that starshipit packages do not get archived automatically when cancelling then in Odoo, as you would expect them to be. Task id # 4074169 Forward-Port-Of: odoo/enterprise#67927