Daily updates from Odoo
Friday, July 26, 2024
3 changes
2 changes
Enhancements to existing features
Warehouse users can now keep the device camera open while scanning multiple barcodes, instead of reopening it after every scan. The Barcode app also gets a refreshed layout with easier line deletion, visible product images, and manual barcode entry moved into the actions menu.
Original PR description
**[IMP] stock_barcode: continuous scanner** > Before this commit, when the user uses the device camera to scan a barcode, the camera video was opened in a dialog and once a barcode was scanned, the dialog was closed, making the process laborious for the user if they want to scan multiple barcodes one after the other. With this commit, the camera stay opened in the app, letting the user to scan barcodes until they close the camera. > > The system parameter `stock_barcode.delay_between_scan` let the user configure the delay between each scan. If not set, 2000 ms will be used by default. > > The input to manually entered barcode was moved in the operation's actions menu. Community PR: odoo/odoo#174236 [task-4058325](https://www.odoo.com/odoo/project.task/4058325?cids=1)
The offer generation step is simplified by removing the separate wizard and opening the editable offer form directly. HR users can now adjust key offer details in the form, see relevant warnings there, track who created offers in the list, and have salary configurator links save changes before opening.
Original PR description
The information in the `generate offer wizard` is the same as the information in the offer form view (in which you can also edit the offer similar to the wizard) that is shown after the offer is…
The information in the `generate offer wizard` is the same as the information in the offer form view (in which you can also edit the offer similar to the wizard) that is shown after the offer is generated. Thus, the wizard doesn't provide any value. Also, Studio is disallowed to add fields on wizard. So it's a hindrance to the flow.
1. These changes remove the `generate offer wizard`, move any warning that was generated on the wizard to the offer form view and make `Generate Offer` button lead directly to that form view.
2. They also update the offer views:
1. In offer form view:
1. 'Title' is now editable and the default title doesn't include the offer creation date or the employer budget.
2. `Contract Template`, `Employee Job` and `Department` are now editable.
3. `Refual Reason` and `Refusal Date` now only appear if they aren't empty.
2. In offer list view:
1. A new field `created by` is added to the list view and choose the creator of the offer.
2. The fields are reordered.
3. In addition to that, the changes adapt tours to the new flow after removing the salary wizard.
task-40084371 change
Resolved issues and error corrections
This fix resolves a critical issue where successfully processed Mexican invoices were being rolled back when errors occurred during batch processing. Previously, transaction commits only happened at the end of the entire batch, causing successfully sent invoices to be reverted if any invoice in the batch failed. Now, each invoice is committed immediately after successful processing, preventing duplicate signatures and data loss.
Original PR description
- Create 4 invoices: A, B, C, D with a correct MX setup - Make sure C will fail by removing the SAT code on the product for example - Run the send and print wizard on all invoices and check…
- Create 4 invoices: A, B, C, D with a correct MX setup
- Make sure C will fail by removing the SAT code on the product for example
- Run the send and print wizard on all invoices and check 'Download' (to force a synchronous run).
After each call to the web-service, the code does:
```
# Check for success.
if invoice.l10n_mx_edi_cfdi_state == 'sent':
continue
```
However, the `cr.commit` is at the end of the loop. So the transaction is not committed except in case of error!
When running the send and print synchronously, the error is raised to the user that will rollback the whole
transaction.
In case of the setup above, A, B and C are well commit but D is sent and has been rollback.
Then, the user will sign again D making the invoice signed twice.
To solve the issue, let's commit right after each web-service call.
That way, whatever the way we use to call the web-services, the transaction is commit immediately.
opw-4003043
opw-3985376
opw-4059666
opw-3955553
...and many others!