Friday, September 27, 2024
19 changes · 17.0
Resolved issues and error corrections
The Polish localization now allows credit notes to be entered for amounts higher than the original invoice total when required by law and user input. This restores compliant handling for Polish accounting cases where larger credit notes are valid.
Original PR description
[REV] l10n_pl: Credit note can be more than the invoice total amount This is a revert for PR https://github.com/odoo/odoo/pull/168252 Reason: The law allow the credit note to be more than the invoice total amount according to the user input task-3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website text replacement requests now wait up to 45 seconds instead of 20 seconds before timing out. This gives users a better chance of seeing requested text updates applied immediately, rather than only benefiting later visitors through cached results.
Original PR description
When asking for website text replacements to IAP, a timeout of 20 seconds was set. Meaning that after 20 seconds, the user waited for no reason as texts won't be replaced for him (but will be for the next user, using the cache, if still valid). This commit increases that 20 seconds value to 45 seconds. While testing, this 20 seconds timeout is really annoying and from a functional point of view, waiting an extra 25 seconds (at worst) for a much greater chance of having text replacements seems acceptable. This will be even more true with the 18.0 new waiting screen which is nicer. Also, it might just be needed to increase that timeout as we may increase the overall delay a bit in future updates to have better quality text replacements.
This fixes a UK accounting setup issue during system upgrades by loading tax data only after all required components are available. It helps prevent upgrade failures for UK-localized databases and reduces disruption during migrations.
Original PR description
Load taxes in an end script when all modules are loaded ``` Traceback (most recent call last): File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries registry =…
Load taxes in an end script when all modules are loaded
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/migrations/1.1/post-migrate.py", line 7, in migrate
env['account.chart.template'].try_loading('uk', company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 153, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 212, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/models/template_uk.py", line 38, in _post_load_data
result = super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 31, in _post_load_data
company._get_and_update_tax_closing_moves(fields.Date.today(), include_domestic=True)
File "/home/odoo/src/enterprise/17.0/account_reports/models/res_company.py", line 163, in _get_and_update_tax_closing_moves
report, tax_closing_options = tax_closing_move._get_report_options_from_tax_closing_entry()
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_move.py", line 264, in _get_report_options_from_tax_closing_entry
report_options = tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1670, in get_options
initializer(options, previous_options=previous_options)
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1619, in _init_options_custom
self.env[custom_handler_model]._custom_options_initializer(self, options, previous_options)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 534, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 213, in __getitem__
return self.models[model_name]
KeyError: 'l10n_uk.tax.report.handler'
```
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-prThis fixes a setup issue where companies that had been archived could prevent administrators from creating a new email alias domain. The first alias domain now applies to all companies, including archived ones, so email alias configuration can be completed without temporarily reactivating old companies.
Original PR description
# Context: The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of…
# Context: The `create` method in the `mail.alias.domain` model currently tries to make the created alias domain record the default for all companies and `mail.alias` records if it's the first of it's kind to be created. But in it's current form it fails to accound for grandfathered databases (pre 17.0) or miss confgurations by a user, where we have archived companies attached to `mail.alias` where the `alias_domain_id` field is False. In such a edge case, it is impossible to create a alias domain record, because during the save (create), the user is faced with a Validation Error produce by the checks in the `_check_alias_domain_id_mc` in the `mail.alias` model. Example error message: ``` "We could not create alias archived-company-alias@example.com because domain example.com belongs to company ActiveCompany while the owner document belongs to company ArchivedCompany." ``` It follow that the user is blocked from setting up an alias domain unless they temporarily unarchive a company. # Proposed solution: Assuming that the objective is to initialize all current mail aliases in the DB with the "first" alias domain record to be created, we should force the `company_ids` field in the just created `mail_alias_domain` record to contain ALL companies (active or not). # Reproduction steps: One way to reproduce the issue on a fresh DB is: - install mail - define a domain alias in the general settings - create a second company - install Accounting - make sure a localization pack is loaded for each company (the idea is to create default sale and purchase accounting journals with their email alias) - archive second company - in Technical > Aliases menu, clear alias domain from aliases (set `alias_domain_id` = False) - delete alias domain - create a new alias domain --> Validation Error OPW-3955936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes inaccurate purchase price calculations when discounts and currency exchange rates are involved for automatically valued inventory. This helps keep inventory valuation and supplier bill amounts aligned, reducing accounting discrepancies after receipts and invoices are posted.
Original PR description
**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate…
**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate fashion. **Expected behavior:** The price_unit should be accurate. **Steps to reproduce:** 1. Enable another currency, set an exchange rate on it that is very small (like < 0.01) 2. Enable automatic valuation, create a product with both average costing method and real time valuation on its category, give it some initial cost e.g., 500 3. Create a new purchase order, add a line like: - product_id: from step 2 - quantity: 13 - discount: 1% 4. Set the currency on the purchase order to be the one from step 1, so it is different from the active company's 5. Confirm the purchase order and validate the receipt, look at the SVL generated and note its remaining value 6. Create a bill for the purchase order, post the invoice, then look at the SVL's remaining value again -> it changed **Cause of the issue:** The price unit being converted between currencies and rounded causes some discrepancy with the final value, also the calculation for gross price unit on AML model is somewhat primitive. **Fix:** Stop rounding base and update the formula used when calculating gross price unit. opw-4103167
Users editing reports in Studio can now change text size and have that size appear correctly in exported or printed PDFs. This fixes a mismatch where the preview looked right but the final PDF ignored the selected font size due to PDF rendering limitations.
Original PR description
Steps:
- Install `web_studio`
- Open studio
- Go to Reports
- Create or edit an existing report
- Add some text and try to change its size
- Preview will display the right size but printed
pdf ignores it
`wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4).
```css
.display-2-fs {
font-size: calc(1.575rem + 3.9vw);
}
```
The problem with this class is the 'calc', which is not supported by the old Webkit version.
see https://github.com/odoo/odoo/issues/136360
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4092
One solution would be to use the old (hardcoded) bootstrap 4 values in the reports.
opw-3894005This fix prevents manufacturing reservations from being deducted twice when mass producing serial-numbered products in a two-step manufacturing flow. It keeps pre-production stock reservations accurate, avoiding negative reserved quantities and reducing inventory confusion for warehouse and production teams.
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…
### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's) #### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be - validate one of the 7 MO #### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be ### Cause of the issue: By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice opw-4145680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Merging duplicated helpdesk tickets now avoids repeated SLA entries and handles shared followers correctly. This prevents merge failures and keeps the resulting ticket's SLA information clearer by retaining the most relevant deadlines.
Original PR description
Coupled with [77d53029986b5120500aef6dc25094588e315143](https://github.com/odoo/enterprise/pull/69352/commits/77d53029986b5120500aef6dc25094588e315143) Steps to reproduce: - Helpdesk > Configuration…
Coupled with [77d53029986b5120500aef6dc25094588e315143](https://github.com/odoo/enterprise/pull/69352/commits/77d53029986b5120500aef6dc25094588e315143) Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen: 1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set. 2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well. 3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities. opw-4037262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix allows tasks to be automatically created when adding non-recurring service products to subscription upsells. Previously, task creation was blocked for all upsell products due to pricing proration limitations. Since non-recurring products are not prorated, they can now safely create tasks without technical issues.
Original PR description
Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be…
Steps to reproduce: - Download 'Project' and 'Subscription' - Create a product with: -- Product type: 'Service' -- Create on order: 'Task' -- Project: Pick any -- Recurring checkbox must not be ticked - Subscription > New > Add any recurring product > Confirm - Create invoice > Confirm invoice > Back to subscription - Upsell > Add your task creation product > Confirm - The project is linked but no task is created The ability to create tasks from upsell orders was disabled in cbbc70f73e6fe9e29e27dea4415e20a262bbdf82. According to the commit message, this was done because upsell orders prorate the price of subscriptions accoding to the time until next invoice relative to the subscription's recurrence (i.e. if the upsell is created halfway through the recurrence it is discounted by 50% etc...). Since we do not have a way to prorate tasks it is marked as a technical limitation. This however does not need to extend to non-recurring products on subscription sale orders as they are not prorated. opw-4114049
This fix addresses two issues with appraisal feedback deadlines. First, employees can now no longer submit feedback after the deadline has passed. Second, managers can continue to view submitted feedback even after the deadline has expired. These changes ensure that feedback deadlines are properly enforced while still allowing managers to access and review the feedback they've received.
Original PR description
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method…
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call the original method `_check_validity` in the override, to make sure all the checks are done, then if the original method returns `validity_code = answer_wrong_user` we can do our specific checks. Issue 2: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - manager can't see the answers after the deadline Problem: -------- - to display answer in appraisal module we rely on the url of the survey that contains the tokens for suervey/answer - the deadline handling is done in the survey module where the url is dead after the deadline which is not suitable for the appraisal module Solution: --------- - override the method `_get_access_data` and bypass the deadline check in case of appraisal feedback for manager. opw-4128638
Fixed an issue where the expiration date field was incorrectly disabled when receiving lot-tracked products in the barcode app. The date picker now works properly when either "Use Existing" or "Create New" options are enabled for lot/serial number configuration, allowing warehouse staff to accurately record product expiration dates during inventory receipts.
Original PR description
The problem was that the date picker was disabled when we have Use Existing ones only enabled, but it should be enabled when "Use Existing ones" is checked or "Create New" in the config of "Lots/Serial Numbers". Steps to reproduce: - add a product tracked by lots and have also enabled expiration dates - inventory Receipts configuration - in general, check both options "Use Existing ones" and "Create New" under "Lots/Serial Numbers" - now if you receive product in barcode app, you will see expiration date of the lots disbaled opw-4086325 Forward-Port-Of: odoo/enterprise#68008
This update fixes problems that occur when helpdesk tickets are merged together. Previously, merging tickets would create duplicate SLA policy entries and lose follower information. The fix ensures that duplicate SLA policies are removed, followers are properly preserved, and only the most urgent deadline is kept for each policy type when tickets are combined.
Original PR description
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements -…
Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen: 1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set. 2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well. 3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities. opw-4037262
This fix prevents an application error that occurred when users tried to send WhatsApp messages after deleting a contact. The system was attempting to access information about a contact that no longer existed, causing the messaging feature to crash. With this fix, the WhatsApp messaging feature now handles deleted contacts gracefully without interrupting the user experience.
Original PR description
Steps to reproduce the error: - Install "contacts" and "whatsapp" module - Configure WhatsApp Business Account and create a whatsapp template - Go to Contacts > Create a new contact > add mobile…
Steps to reproduce the error:
- Install "contacts" and "whatsapp" module
- Configure WhatsApp Business Account and create a whatsapp template
- Go to Contacts > Create a new contact > add mobile number >
click on whatsapp button > select template > send message
- reply to message from mobile number
- Delete contact
- Go to Discuss > open channel of contact > send message
Traceback:
```
IndexError: tuple index out of range
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/saas-17.2/whatsapp/controller/main.py", line 41, in webhookpost
request.env['whatsapp.message']._process_statuses(value)
File "home/odoo/src/enterprise/saas-17.2/whatsapp/models/whatsapp_message.py", line 413, in _process_statuses
whatsapp_message_id._update_message_fetched_seen()
File "home/odoo/src/enterprise/saas-17.2/whatsapp/models/whatsapp_message.py", line 426, in _update_message_fetched_seen
channel_member = channel.channel_member_ids.filtered(lambda cm: cm.partner_id == channel.whatsapp_partner_id)[0]
File "odoo/models.py", line 6580, in __getitem__
return self.browse((self._ids[key],))
```
https://github.com/odoo/enterprise/blob/a134bea9c6fa1a0806c5501046e358c82d7a3fe5/whatsapp/models/whatsapp_message.py#L428
Here, when user deletes the contact, channel.whatsapp_partner_id will be False,
and channel_member will become an empty tuple,
So when it tries to access the index of an empty tuple,
It will lead to the above traceback.
sentry-5314291061This fix resolves an issue where Kenyan companies using subcontracting workflows encountered validation errors when processing purchase orders. The system was incorrectly preventing negative stock quantities in subcontracting locations, which are internal locations without warehouses and should allow negative quantities. The fix ensures that stock validation only applies to locations with actual warehouses, allowing subcontracting operations to complete successfully.
Original PR description
Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior -…
Steps to reproduce the bug:
- Log in as a Kenyan company
- Create a storable product “P1” with the following Bill of Materials (BoM):
- Type: Subcontracting
- Subcontractor: Azure Interior
- Component:
- C1: - Routes: “Resupply Subcontractor on Order”
- Create a purchase order for one unit of “P1”
- Confirm the PO
- Create a second PO for one unit of “C1” and receive it
- Confirm the resupply picking of C1
- Confirm the receipt of P1
**Problem:**
A validation error is triggered: “You cannot end up with a negative stock quantity.”
We added a constraint to prevent negative stock quantities in internal locations for a company in Kenya. However, the location linked to subcontracting is internal but has no warehouse, so we don’t care if its quantity is negative, and it should be ignored. This could also happen with other internal locations that don’t have a warehouse.
Additionally, when reporting stock quantities, we only consider
quantities in locations that have a warehouse:
https://github.com/odoo/enterprise/blob/9dea0f2696084235ee1192b0a14adfa43eb732ef/l10n_ke_edi_oscu_stock/models/product.py#L47
opw-4184857A technical issue was causing the tax closing entries report to crash with an error. The problem occurred when the system tried to access company information while processing multiple companies' data. This fix ensures the report generates successfully without interruption, improving the reliability of tax reporting functionality.
Original PR description
The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line: ```py if from_post and move == closing_moves_by_company[self.env.company]: ``` triggered the insertion of a new key when `self.env.company` was not already present, leading to the runtime error. This commit changes the access method to use `.get()` instead of directly accessing the key allowing, safe retrieval of the value without modifying the dictionary. opw-4089738
This fix resolves an issue where timesheet overtime warnings and formatting would randomly change appearance due to floating-point rounding errors in calculations. The system now uses a small tolerance level when comparing time values instead of exact matches, ensuring consistent and reliable display of timesheet status regardless of working schedule configurations.
Original PR description
Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error margin was chosen to be much lower than what a difference of 1min could cause (Since the rounding errors are in the vicinity of 1e-16). opw-4123649
This fix resolves an access issue where assigned users couldn't view tasks in projects with restricted visibility settings. The problem occurred because the system was incorrectly blocking access to task information for users who were assigned to the task but not project followers. The fix ensures assigned users can properly access their assigned tasks regardless of project visibility restrictions.
Original PR description
Steps to reproduce: - Project > New > Create Project - Project > ':' menu > Settings > Settings tab - Set 'Visibility' to 'Invited Internal Users' - Create a task and assign it to Marc Demo - General…
Steps to reproduce: - Project > New > Create Project - Project > ':' menu > Settings > Settings tab - Set 'Visibility' to 'Invited Internal Users' - Create a task and assign it to Marc Demo - General Settings > Users & Companies > Users - Edit Marc Demo to have 'User' access rights in 'Project' - As Marc Demo: Project > Tasks > My Tasks > Click your task Access is denied because Marc is not a follower of the project, and therefore cannot read the task's 'is_fsm' field (which is computed from the project). Due to the specifications of the visibility mode, the task should however be accessible to him. A fix was previously made for a similar issue in Field Service 5fc4f7d15e56d2b4335aa70e896fdfbd901d6076, where we changed the _search_is_fsm function to sudo the project for the same reason as here (accessing project_id.is_fsm) so this should not raise any additional security concerns. In that same fix we switched from a related field to a compute, compute_sudo was however defaulting to False since is_fsm is not stored, hence the access error. opw-4176243
This update fixes three important issues with Uruguay's electronic invoice system (l10n_uy_edi). Users can now correct invoices that fail validation by resetting them to draft without encountering document number errors. The send and print feature now works correctly by running after invoices are posted rather than before. Additionally, the account setup instructions have been simplified and updated.
Original PR description
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **[FIX] l10n_uy_edi: Create Uruware account help** Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly. **[FIX] l10n_uy_edi: Send and Print after Post** Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted.
This fix corrects an issue where Amazon orders containing multiple items were incorrectly creating a separate shipping line for each item. Now, shipping is properly consolidated into a single line per order, ensuring accurate order records and preventing billing confusion.
Original PR description
If an Amazon order has more than one item it was creating for each item an own shipping line. Info: @wt-io-it