Tuesday, September 10, 2024
9 changes · saas-17.4
Resolved issues and error corrections
Purchase orders using UBL BIS 3 now use the dedicated purchase description instead of the product's internal HTML description. This prevents printing or sending failures caused by invalid formatting in internal product notes.
Original PR description
Issue: When the purchase_edi_ubl_bis3 module is installed, if a product's internal description contains invalid HTML, the purchase order with that product cannot be printed or sent. Steps to reproduce: - Install purchase_edi_ubl_bis3 - In a product, press enter in the internal description field (resulting in the HTML code `<p><br></p>`) - Create a purchase order containing this product - Attempt to print the purchase order - An error will occur, indicating an unclosed `<b>` tag. Fix: After discussing with AELS, we decided to use the description_purchase field instead of description. This makes more sense in this context, and since description_purchase is a text field (while description is an HTML field), it eliminates HTML-related issues. opw-4142522 opw-4142378 opw-4142367 opw-4141322
Users can once again adjust the date of a posted bank transaction from the bank transaction list when the workflow requires it. The change avoids an overly strict readonly protection in this specific case, preventing unnecessary errors while preserving the intended accounting process.
Original PR description
This commit adds a context to skip the readonly check on bank statement line, because it is required for user to be able to modify a posted move's date in the bank transaction list view. Background:…
This commit adds a context to skip the readonly check on bank statement line, because it is required for user to be able to modify a posted move's date in the bank transaction list view. Background: From 17.3+, a check was added on `account.move` write function where if the move field to write has an `readonly` attribute and the move is on "posted" state, it will reject the write with an UserError. This was done so that when 2 or more user are editing the same invoice, if one user posted the invoice, the other can no longer change fields that are supposed to be unchangable. There are however, multiple places in the code where it is required to modify this "unchangable" field. The correct functional flow would be to reset move to draft, change the field, and re-post the move. It is however too resource heavy for something to be done behind the scene. Because of that, a context "skip_readonly_check" is added to bypass this check. [Mentioned commit](https://github.com/odoo/odoo/commit/b5d94f5563641adfd93bf431c139bc2b78d67beb) and [PR](https://github.com/odoo/odoo/pull/160096) task-id: 4149628
Point of Sale search now shows the main product when staff search for one of its variants. This makes products with selectable options easier to find and sell, reducing missed items during checkout.
Original PR description
Before this commit, searching for a product with attributes that create variants in the PoS interface did not display the main product. This occurred because it was designed to hide variants and show a single product representing all variants, requiring the user to select options in a popup. However, this approach prevented the main product from appearing in search results when attempting to find one of its variants. This commit fixes the issue by adjusting the search functionality to ensure that the main product is displayed in the search results, even when searching for its variants, improving the user's ability to locate and select products with variants in the PoS interface. opw-4149878 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Device records now keep a consistent identifier even as underlying device logs are refreshed or cleaned up. This prevents users from seeing misleading “record does not exist” errors when the same device is accessed across different actions or sessions.
Original PR description
Issue: ------ The `res.device` view is a view that deduplicates records from the `res.device.log` model. Records from `res.device.log` are added over time (and removed with garbage collector). The…
Issue: ------ The `res.device` view is a view that deduplicates records from the `res.device.log` model. Records from `res.device.log` are added over time (and removed with garbage collector). The ids of `res.device` records are the ids of the corresponding `res.device.log` records. For a given device (session identifier, platform, browser), when we deduplicate, we find a `res.device.log` record with id `X`. If other operations are performed which update the logs, we will obtain a new result for deduplication and therefore find a `res.device.log` record with id `Y` . If we want to access the information for the device whose id is the same as the associated log (`X`), if the information is not cached, we will re-run the view query (no-materialized). In the resulting table, we won't find the `X` id and this will trigger the error: `"Record does not exist or has been deleted."`. Solution: --------- The `res.device` records must have a unique id that can be shared between logs from the same device (over several transactions). So that in the example, the device has an id which is equal to the result of a deterministic function whose logs X and Y find the same result (and can therefore access the information).
This fix ensures subscription payments correctly save the customer's payment method when the payment amount is sufficient. It prevents small currency rounding differences from blocking tokenization, reducing failed automatic renewals and follow-up payment issues.
Original PR description
Since 71681ae22bd we tokenize subscription payment when amount is sufficient, in some case that test was not true because the sum of order's recurring line was geater by an epsilon. This commit compare the two amounts relative the order's currency (rounding). opw-4176380 opw-4162841 opw-4117553
The scheduled partner commission task now reports its progress while confirming purchase orders, allowing it to resume and keep working instead of waiting until the next weekly or monthly run. This helps prevent draft purchase orders from being delayed for long periods when a scheduled run times out.
Original PR description
…orders The cron _cron_confirm_purchase_orders run only once a week, month and do nothing the rest of the week month The cron may timeout and get delay to it's next execution date before all the po to process are done This leave some draft pos that won't be handle before next month/week and generate unacceptable delay. The cron should notify its progress in order to be able to run as much as needed. In order to have a consistent progress notified, this commit first fech all the pos to process and then process them one by one.
This fix updates Colombian electronic support documents and related credit notes so they follow DIAN validation requirements. It prevents rejected filings by excluding tax details the authority does not want and adding required credit note references and validation constraints.
Original PR description
task-4068657
The barcode app now supports previously printed barcode formats through aliases, so companies do not need to reprint large numbers of labels after migrating. This reduces disruption for warehouse teams and avoids unnecessary printing waste.
Original PR description
commit [1] introduced new barcode structure. However different buisness already have printed their barcode and it could be difficult to adapt on migration. We have this issue. For the sake of the planet, we will add aliases and better alias management instead of printing in color thousands of scaleup The demo data for scale up will be removed in 19.0 [1] commit 073163f1ae3fd2c659653b773d3ed66836eb2cb2
This fixes an error that prevented users from opening consolidated balance reports from the consolidation dashboard. The dashboard now handles reports that do not use date options, avoiding an unexpected crash and keeping consolidation workflows accessible.
Original PR description
Open consolidation dashboard
Try to access any Consolidated Balance
Traceback
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4766, in _get_annotations_domain_date_from if options['date']['filter'] in {'today', 'custom'} and options['date']['mode'] == 'single': ~~~~~~~^^^^^^^^
KeyError: 'date'
This occurs because when opening consolidation reports a custom inizializer will remove the date from options dict https://github.com/odoo/enterprise/blob/67986c6492f38703b0ec4c81199dab1e4d8fc3d6/account_consolidation/report/trial_balance.py#L38
opw-4154017