Thursday, September 5, 2024
17 changes · 17.0
Resolved issues and error corrections
Odoo can now import UBL files even when required namespace information is declared inside individual elements instead of only at the top of the file. This prevents import errors and helps businesses process electronic invoices from more suppliers without manual correction.
Original PR description
When importing a UBL file, we get an error `SyntaxError: prefix 'cac' not found in prefix map` When importing a UBL file Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. We fix it by using the ubl namespace as nsmap (see https://github.com/odoo-dev/odoo/commit/1e24b151c6ad0023769b5a561690cb62bcda1d8a) opw-4142421
Fixed an issue where certain loyalty discount rules using yes/no product conditions could prevent the Point of Sale from opening. Businesses can now use targeted loyalty discounts without risking checkout disruption.
Original PR description
Loyalty programs discount could be applied on specific products through a domain. When putting a domain with a True or False as a third operand (e.g. ('is_available_in_pos', '=', True)), the PoS was crashing at launch because the domain goes through a json.dumps that changes the Boolean to lower case and then through ast.literal_eval that doesn't accept lower case Boolean.
The change is to replace lower case Boolean to upper case Boolean in the domain before the ast.literal_eval.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Point of Sale now blocks archiving an accounting journal if it is still linked to a POS payment method. This prevents checkout and session-closing errors that could disrupt store operations.
Original PR description
You shouldn't be able to archive a journal that is used in a payment method. Steps to reproduce: ------------------- * Open a payment method and archive the journal used in it * Open PoS and make an order using this payment method > Observation: Close the PoS session, you will have an error saying you cannot close the session. Why the fix: ------------ We override the `action_archive` function to make sure no payment method is using the journal being archived. opw-4070620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where changing the quantity of a loyalty reward product in Point of Sale did not update the related discount line. This prevents orders from receiving excessive deductions and potentially showing an incorrect negative total.
Original PR description
Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the…
Currently, when adding product rewards to an order, you are rewarded with the maximum amount of products you can get with you current points. If you change the quantity of the reward product, the reward lines does not update. Steps to reproduce: ------------------- * Go to the **Point of sale** App * Open Shop session * Select a customer that has plenty of loyalty points * Put any product in the order * Add the reward `Simple pen` (you'll havelike 230 of them) * Try changing the reward quantity to 1 > Observation: The quantity of the simple pen changes to 1 but the negative reward line still shows 230. Thus, the order can have a negative amount since 229 pens are still being deducted from the order even though they are not present. Why the fix: ------------ This commit https://github.com/odoo/odoo/commit/de45ff3c9f23decdab176bc1511b3356d19844a8 passes the quantity and cost (in points) to the `_applyReward` function. This was done because when recomputing reward lines, if two lines came from the same reward, the quantity would be merged even though they would not apply on the same product. In our case, this causes problems as we are using the function `_getRewardLineValuesProduct` to update the reward quantity but the quantity (230) is given as an argument and is then used as the quantity to set. https://github.com/odoo/odoo/blob/775827b8f7fa95f2afd77a9b42d6cd8e436ea690/addons/pos_loyalty/static/src/overrides/models/loyalty.js#L1548-L1566 `args["quantity"] || freeQuantity` will always use `args["quantity"]` if given, bypassing the maximum quantity that is available to give. `freeQuantity || args["quantity"]` will never use `args["quantity"]`. Since we do not want to reward more than what is available, we add the arguments inside the `Math.min` function. opw-4103833
This fix prevents work entries from being created for holiday hours when an hourly employee has no attendance recorded. It improves payroll accuracy for attendance-based contracts by ensuring public holidays overlapping planned working hours are handled correctly.
Original PR description
1. Create an employee and assign them to an attendance-based contract with a non-empty calendar(i.e., working hours during specific days). 2. Create a public holiday where the start and end times overlap with the selected employee's calendar. 3. Do not create any attendance records. 4. Generate the Work Entries for the period that includes the public holiday. The Work Entry is incorrectly created for the hours in the calendar that overlap with the holiday hours. To resolve this issue, we need to filter the entry under these specific conditions. opw-3975435 enterprise-pr : https://github.com/odoo/enterprise/pull/67551
Users assigned to planning work can now download or print their planning report without hitting an access error tied to the related sales order line. This prevents a disruptive crash in the planning workflow while keeping normal access rights in place.
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_planning app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form view. - Print planning. ### Issue: - Traceback occurs of access right. ### Cause: - While downloading the report, it goes to access the "display_name" field of sale order line that is computed in the _compute_display_name, but the user does not have access to "sale.order.line". ### Solution: - Give access to the record by using sudo(). task-3978552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Hourly employees on attendance-based contracts no longer receive incorrect work entries when a public holiday overlaps with their scheduled working hours but no attendance was recorded. This helps payroll reflect the actual holiday situation more accurately and reduces manual corrections.
Original PR description
1. Create an employee and assign them to an attendance-based contract with a non-empty calendar(i.e., working hours during specific days). 2. Create a public holiday where the start and end times overlap with the selected employee's calendar. 3. Do not create any attendance records. 4. Generate the Work Entries for the period that includes the public holiday. The Work Entry is incorrectly created for the hours in the calendar that overlap with the holiday hours. To resolve this issue, we need to filter the entry under these specific conditions. opw-3975435 odoo pr : https://github.com/odoo/odoo/pull/174883
Fixed an issue that could block invoice confirmation when an inter-company invoice line used multiple analytic accounts together. The system now keeps valid shared account distributions when possible and safely splits them when needed, reducing errors in synchronized company billing.
Original PR description
…e analytic account distribution
Steps to reproduce:
- Activate Inter-Company Transactions - Synchronize invoices/bills for both companies
- With Company A, create an invoice with Product A; analytic distribution with one account from two plans on the same line such as `{'1,2': 100}`
- Confirm the invoice
Issue:
Stack Trace
Solution:
If, for a key, all the accounts are available for Company B, we set the distribution as it. Else, we set one available account per line with the associated distribution.This fix resolves an issue where exporting and re-importing automation rules in Web Studio would fail due to missing required fields. Users can now successfully export automation rules from their projects and import them back without errors.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Go to project - Open studio > Automations - Create a new rule - Click on the top left icon to go back to the home menu - Customizations > Export - Go back to project and delete the newly create automation - Click on the top left icon to go back to the home menu - Import > Upload the generated zip => It fails because a few required fields are missing opw-4073631
This update resolves an issue where the system would fail when trying to remove a database constraint that no longer exists. The fix adds a safety check to verify the constraint is present before attempting to remove it, preventing errors during system updates and maintenance operations.
Original PR description
Issue: An issue can arises when attempting to drop the constraint "account_move_line_check_amount_currency_balance_sign" if it does not exist. This problem was triggered since the following fix: https://github.com/odoo/enterprise/pull/67953. Fix: Ensure that the constraint exists before attempting to drop it. opw-4107760 opw-4133787 opw-4122219 Forward-Port-Of: odoo/enterprise#69191
This fix corrects a bug in the approval workflow system where higher-level approvers were being notified prematurely before all lower-level approvals were completed. Now, notifications for higher approval levels are only sent once all approvals at the previous level have been fully approved, ensuring a proper sequential approval process.
Original PR description
… entries Have a studio approvals with minimum 3 rules: - 2 on level 1 - 1 on level 2 Before this commit, if one of level 1 was refused, when approving the other one, the level 2 rule created an activity for the responsible. As we don't want a level to be notified if the lower level is not fully approved, there was a bug. After this commit, we only trigger activity notification on higher level rules if the below level has been fully approved.
This fix adds a warning message when users try to reserve a serial number that is already out of stock in a rental order. Previously, the system would allow users to select unavailable serial numbers without any notification, which could lead to fulfillment issues. Now the system alerts users when a selected lot is unavailable.
Original PR description
Steps to reproduce: ------------------- - create a storable product tracked by serial number; - create a serial number for this product; - add 1 quantity on hand for it; - create a rental order with the product; - add the created serial number in "Reserved lot"; - confirm and pickup; - create an other rental order; - add the product and the same "Reserved lot"; Issue: ------ There is no warning even if the serial number of the product is already out of stock. Solution: --------- Add a check when the `reserved_lot_ids` field is modified using an onchange method. opw-3839116
This update fixes an issue where subscription invoices were being skipped due to a pending transaction flag that wasn't being cleared after renewal. The system now properly removes this flag when an invoice is posted, ensuring subscriptions continue to be billed correctly even after renewal cycles.
Original PR description
…nvoice Before this commit, subscriptions automatic invoices are skipped when the flag pending transactions is set. it is correct to avoid double payment for the same period but there is a problem if the flag stays while the subscription has been renewed since. This commit aimes to remove that flag when an invoice is posted for this subscruption. taskid: 4107185
Fixed a crash that occurred when users tried to add conditional visibility rules to columns in grouped reports (like the Inventory Valuation report). The issue was that Studio was incorrectly trying to access fields that only exist within grouped sections, not in the main data model. This fix ensures Studio properly filters out these grouped fields when editing conditional rules.
Original PR description
Steps to reproduce
==================
- Open inventory > Reporting > Valuation
- Open studio
- Select a column
- Click on "Conditionnal" next to "Invisible", "Required" or "Readonly"
=> crash
Cause of the issue
==================
Fields declared inside a groupby node are not part of the main model
```xml
<groupby name="product_id">
<field name="cost_method" invisible="1" />
<field name="quantity_svl" invisible="1" />
<button name="action_revaluation" icon="fa-plus" title="Add Manual Valuation" type="object" invisible="cost_method == 'standard' or quantity_svl <= 0" />
</groupby>
```
opw-4147138This fix resolves an application crash that occurred when users cancelled a report discard action in Studio. Previously, the system would throw an error when clicking cancel after initiating a discard. Now the cancellation is handled properly, allowing users to safely abandon their discard action without the application crashing.
Original PR description
Steps to reproduce ================== - Open studio - Edit any report - Make some changes - Click on discard - Click on cancel => UncaughtPromiseError Cause of the issue ================== When clicking on cancel, the promise is rejected https://github.com/odoo/odoo/blob/1ffcea337ba463c383483ca53ff57aa6b725b5a2/addons/web_editor/static/src/js/wysiwyg/wysiwyg.js#L1112 Solution ======== Instead of rejecting the promise, resolve it with the confirmation status opw-4141192
Fixed an issue where invoices from customers in Monaco were not appearing in the EC Sales List Report. Monaco is now properly recognized as part of the European Community list for companies outside of France, allowing these invoices to be correctly displayed in the report.
Original PR description
Steps to reproduce: [l10n_* nl/be/etc - Europe] - create a customer form Monaco with a valid TVA number `FR53000004605` - create an invoice with this customer with an intra-eu tax - Open the EC Sales List Report Issue: The invoice will not be displayed Cause: Monaco is not part of the list Solution: We add it if the company.country_id is not France. Because for any other european country we want Monaco's invoices to be displayed opw-4075452 Forward-Port-Of: odoo/enterprise#68560
This fix corrects how rental equipment returns are processed in the inventory system. Previously, a recent change to prevent double-counting returned items inadvertently affected rental returns, which are handled differently. This update ensures rental returns are properly tracked without affecting the delivered quantity calculations on sales orders.
Original PR description
In sale_stock, when making returns, we fix a bug where the delivered quantity on an SO is affected twice by returns in the case of 2-step routes, by not linking moves generated by push rules to the SO. (https://github.com/odoo/odoo/pull/178392) But in the case of `sale_stock_renting`, it is a push rule that generates the return at the end of the renting period, so we have to make an exception. opw-4129497