Monday, November 6, 2023
26 changes · 17.0
Resolved issues and error corrections
This fix removes a misleading lot/serial number placeholder that made copying and pasting lot names confusing. It also opens related stock quantity views with a default focus on items that are actually available, helping users avoid customer-delivered or zero-quantity records.
Original PR description
It's not possible to copy paste in the lot_name directly. It has been remove since the import button. Also add by default a search on hand in the quant view from the stock.move.line. We don't want to show quant already send to customer location or without quantity 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-pr
This fix restores the ability to edit the extra information section during website checkout. Businesses can once again add or adjust fields there while keeping the updated checkout button styling.
Original PR description
The extra_info template was no more editable due to a t-call for the CTAs in the template. To be able to add fields we need to remove the t-call and apply the buttons manually. This is due to the checkout redesign: a5899db8e12af29bd311db75473ce76bfa91d641 This commit applies the previous navigation buttons while adapting the styling to the checkout redesign. task-3582219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale product form will continue showing the Accounting/Invoicing tab for all product types. This ensures users can still configure sales taxes and accounting details for combo products, especially when included items may use different taxes or localization rules.
Original PR description
In this commit https://github.com/odoo/odoo/commit/00dcc575b8af5bee5204c45b80290a8e59fe10f9 they added an invisible condition of the accounting tabs (in the product view). After discussion with the PoS product owner, there is still some doubts on how combos product will be manage for the accounting tab (specially with localisation). But if we remove the Accounting/Invoicing tab, the user will be completely incapable to configure sales and taxes when combo products include products with different taxes. As we have doubts, we prefer keeping the tab by default no matter what the product type is. task: 3581797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where invoices linked to a sales order were not displayed in the customer portal. This helps customers access their invoice information directly from the sales order page, reducing confusion and support requests.
Original PR description
task-3584770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a Stripe checkout issue that could block payment when a customer switched between multiple payment methods before paying. Stripe is now initialized once per payment flow, keeping checkout consistent and reducing failed payment attempts.
Original PR description
Steps to reproduce: 1. Activate Stripe and at least two payment methods 2. Click on the first pm 3. Click on the second pm 3. Select again the first one and try to pay The bug was caused by reinstantiation of stripeJS for each payment method. So that each stripe element was created from different stripeJS object which raised the following error from Stripe: "Invalid value for stripe.confirmPayment(): the 'elements' provided was created by a different Stripe instance. Please use the same Stripe instance to create the 'elements' and call stripe.confirmPayment()" After this commit StripeJS object is instantiated only once.
Restaurant point-of-sale configurations now create the needed default floor and table more reliably when demo data is not installed. This prevents duplicate setup records and helps new restaurant POS setups work as expected; discount products are also handled as special POS products.
Employees will no longer be automatically assigned the office as their default work location, leaving it unset unless specified. The calendar now also allows default work locations to be removed, and a typo fix restores correct handling of work location exceptions.
Original PR description
This commit changes the default worklocation set for the employee from "office" to false. Also, this commit adds the possibility to delete a default worklocation from the calendar view. A typo is also fixed from "exception" to "exceptions" which was causing a bug returning the worklocations. task-3584193 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-pr
PayPal payments through Adyen now receive the correct payment amount in the checkout setup, preventing failures on payment links such as Euro invoices. Related payment form data handling was also adjusted so inline form values remain distinct across supported payment providers.
Original PR description
Steps to reproduce: 1. Create a company with currency as Euros. 2. Set up Adyen on that company with the test credentials and enable paypal. 3. Create an invoice with the currency in Euros. 4. Generate a payment link. 5. Attempt to pay on that payment link with paypal. After this commit the Adyen checkout configuration is correctly set up which allows to pay with PayPal opw-3543970
The attendance menu has been reorganized to make information easier to read and navigate. Added spacing and a cleaner layout reduce clutter, improving the day-to-day user experience for employees and managers.
Original PR description
This PR fixes the layout of the hr attendance menu. Prior to this commit, the layout was a bit cluttered and had a lack of white space, making it difficult for the user to extract the information he needed. To fix these issues, we adapt the design of the menu, mainly by reorganizing the layout and adding more white space. With this commit, we were also able to clean the files, reducing the number of lines needed to achieve a good visual result. task-3577098
Employees will no longer automatically receive “office” as their default work location, leaving it unset unless chosen. Managers can also remove default work locations directly from the calendar, reducing manual cleanup and improving flexibility for hybrid work planning.
Original PR description
This commit changes the default worklocation set for the employee from "office" to false. Also, this commit adds the possibility to delete a default worklocation from the calendar view. task-3584193 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-pr
Loading earlier messages in Discuss no longer reverses their order. This keeps conversation history readable and prevents confusion when users scroll back through past discussions.
Original PR description
Discuss models use relationnal fields. Since [1], the implementation of the `unshift` method changed for `many` fields. The new implementation is incorrect: unshifting several records resultis in an insertion on the inverse order which differs from the native implementation. This issue broke the loading of older messages in discuss: older messages are inserted with the `unshift` method thus in the inverse order. [1]: https://github.com/odoo/odoo/pull/136539
Employees no longer receive “office” as an automatic default work location when no location is set. Users can also remove default work locations from the calendar, and a typo fix restores correct work location retrieval.
Original PR description
This commit changes the default worklocation set for the employee from "office" to false. Also, this commit adds the possibility to delete a default worklocation from the calendar view. A typo is also fixed from "exception" to "exceptions" which was causing a bug returning the worklocations. task-3584193 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-pr
This fix prevents crashes that could occur when users start creating certain new records, such as account groups or contact tags. It makes name display handling safer across several areas, improving reliability when opening new record forms or customized forms.
Original PR description
As of https://github.com/odoo/odoo/pull/114024, `display_name` is implicit in every form view (see the use of addFieldDependencies in the Form controller). Therefore, when you create a new record for…
As of https://github.com/odoo/odoo/pull/114024, `display_name` is implicit in every form view (see the use of addFieldDependencies in the Form controller). Therefore, when you create a new record for this model, it calls the first `onchange`, which will compute display_name for a new record (id without origin). Some `_compute_display_name` don't handle new records correctly and raise a traceback. These models are sometimes directly accessible:
- Accounting > Account Group > New => Traceback
- Contact > Contact Tags > New => Traceback
Other models are inaccessible by default (no view to access or create a new record), but if someone creates a view for them with studio (or modifies an existing one to allow creation):
- `crm.iap.lead.role`
- `crm.iap.lead.seniority`
- `chatbot.script.answer`
- `payment.token`
Change the code of `_compute_display_name` on these models to be more defensive and avoid (potential) tracebacks. Similarly, change the `convert_to_display_name` of `fields.Datetime` to take into account `None` value.
Enterprise: https://github.com/odoo/enterprise/pull/49721
#### Test to find these issues
```python
@tagged('-at_install', 'post_install')
class TestEveryModel(TransactionCase):
def test_display_name_new_record(self):
for model_name in self.registry:
model = self.env[model_name]
if model._abstract or not model._auto or model_name in IGNORE_MODEL_NAMES:
continue
with self.subTest(
msg="`_compute_display_name` doesn't work with new record (first onchange call).",
model=model_name,
):
# Check that the first onchange with display_name works on every models
# OR it will fail anyway when people will use click on New
fields_used = model._fields['display_name'].get_depends(model)[0]
fields_used = [f.split('.', 1)[0] for f in fields_used]
fields_spec = dict.fromkeys(fields_used + ['display_name'], {})
with contextlib.suppress(UserError):
model.onchange({}, [], fields_spec)
```This fix resolves an issue where rental product prices were not updating based on the rental period selected on the product page. The system now properly loads the necessary rental tools and uses cart dates as a fallback when rental dates aren't available, ensuring customers see accurate pricing for their selected rental periods.
Original PR description
Before this commit, some tools of website_sale_renting were broken due to a loading problem of the overrides of the Variant mixin. For instance, the price on the product page was not depending on the rental period anymore. We now force them to be executed by prepending the js files in the manifest. Furthermore, the dates were not always given in the context. In this case, the fallback is on the cart dates, if any task-3570178
This fix prevents error messages from appearing when users create new records in certain product and social media features. The system was trying to display names for incomplete new records, which caused crashes in some cases. The code now handles these situations more gracefully.
Original PR description
As of https://github.com/odoo/odoo/pull/114024, `display_name` is implicit in every form view (see the use of addFieldDependencies in the Form controller). Therefore, when you create a new record for this model, it calls the first `onchange`, which will compute display_name for a new record (id without origin). Some `_compute_display_name` don't handle new records correctly and raise a traceback. One is directly accessible: - Products > Open TaxCloud Category field > New => Traceback Other models are inaccessible by default (no view to access or create a new record), but if someone creates a view for them with studio (or modifies an existing one to allow creation): - `product.avatax.category` - `social.post.template` Change the code of `_compute_display_name` on these models to be more defensive and avoid (potential) tracebacks. Community: https://github.com/odoo/odoo/pull/139592
Fixed an issue where comment markers were appearing in exported or printed articles, creating visual clutter. The fix applies comment styling only to screen displays, ensuring printed documents are clean and professional without unnecessary comment annotations.
Original PR description
This commit fixes a bug where when a user would try to export an article the anchors for comments were still stylized. This led to printing documents with unnecessary noise in the article. Now, we added the media css query `@media screen` for comment anchors so that we apply the style when using a screen. Removing the style from the printed document. task-3572009
This update fixes a bug in how account reports calculate totals below line items, which was incorrectly matching unrelated line IDs that happened to share similar naming patterns. The code has also been improved by replacing hardcoded separators with a named constant, making the system more maintainable and less prone to similar issues in the future.
Original PR description
[FIX] account_reports: totals below To add a total below line, we go through all the lines and check if the current line id does **not** start with the total below parent id line. If it's the case, we add it before adding the line. This makes sense because the total below should be the last child of a line. The problem is that you may have cases where the line id start with the total below parent id even tho they are not related. For example, if the line id is something like x|y-14 and the total below parent id is x|y-1. To fix it, we check if the line id does **not** start with the total below parent id **ending with** the line id hierarchy separator. [REF] account_reports: line id hierarchy delimiter Replaces the line id hierarchy delimiter `|` used in the construction of line ids by a constant named LINE_ID_HIERARCHY_DELIMITER with the same value. Forward-Port-Of: odoo/enterprise#49971 Forward-Port-Of: odoo/enterprise#49804
This fix corrects how invoice totals are calculated in Spain's mod 349 tax report when invoices contain negative line items. Previously, the system was incorrectly summing both positive and negative line amounts, resulting in overstated invoice totals being reported to tax authorities. The fix ensures only the actual invoice total is reported by properly handling negative adjustments.
Original PR description
To reproduce the issue: 1) On a Spanish company, create a customer invoice, so that: - it has a line at 100, and another negative one at -42. - it uses the default Spanish sales tax of 21% on both…
To reproduce the issue:
1) On a Spanish company, create a customer invoice, so that:
- it has a line at 100, and another negative one at -42.
- it uses the default Spanish sales tax of 21% on both lines
- in is made on a non-Spanish European partner
- it defines a value in mod 349 type; E, for example
=> the total of the invoice is hence 70.18€
2) Post the invoice
3) Open mod 349 for the period corresponding to the invoice date.
===> The invoice is reported with an amount of 112.18€, which is wrong.
This happens because the domains of the report line include lines that have debit>0. In our example, two lines are debit:
- 70.18, on the receivable account
- 42, corresponding to the negative line
For these lines, we want to use the total of the invoices/refunds, so instead of just counting on selecting one side of the move (and ignoring the case of the negative lines), we should consider the payable/receivable lines only.
OPW 3559094
Forward-Port-Of: odoo/enterprise#49975
Forward-Port-Of: odoo/enterprise#49622Fixed an issue where the "last updated on" field in helpdesk tickets was not being refreshed when customers sent new messages through the portal. Now when a customer replies to a ticket, the last update timestamp correctly reflects the new message activity, helping support teams see the most recent customer interactions at a glance.
Original PR description
To reproduce ============ - Go to helpdesk tickets in a list view - Add the "last updated on" field - The customer should be a portal user (e.g. Joel Willis) - Answer to the ticket from the portal account of Joel Willis --> the "last update on" field is not updated when it should be Problem ======= - when receiving multiple message from customer we don't modify anything on the record, that's why `write_date` is not updated. Solution ======== when receiving new message, trigger `write` method without values to force updating `write_date` opw-3482215 Forward-Port-Of: odoo/enterprise#49648
This update resolves test failures in the Luxembourg monthly declaration process by moving the account representative field from the payroll module to the reports module, where its required reporting functionality is located. This ensures the field is properly available when needed for monthly declarations.
Original PR description
Issus on several tests in test_monthly_declaration.py due to account_representative_id called in l10n_lu_hr_payroll. This field depends on action report installed with l10n_lu_reports. Forward-Port-Of: odoo/enterprise#49991
This update fixes several issues in the rental sales module including preventing duplicate warehouse rules when using multi-step inventory processes, removing outdated code that no longer works with current system versions, and improving consistency in the settings menu text. These changes ensure the rental feature works smoothly with other inventory modules and provides a better user experience.
Original PR description
- added a check on rule creation in stock_warehouse to avoid duplicates of the push rule when switching between multisteps options this happens when modules which remove the initial pull rule (e.g. mrp, purchase_stock) are installed along with sale_stock_renting - removed _set_quantities_to_reservation because the parent function doesn't exist anymore. - removed write because it doesn't bring anything and a standard SO doesn't do that anyway - Changed text in the Configuration>Settings menu to match rest of UI texts
Fixed how French balance sheets display earnings carried forward and current year results to align with standard accounting practices. The changes ensure that earnings from previous years and current year results are properly categorized and displayed in real-time, making financial reports more accurate for French companies.
Original PR description
In the French balance sheet, there are two lines called Report à Nouveau and Résultat de l'Exercice. The normal accounting practice is to: - at year end, debit the Unaffected Earnings account and…
In the French balance sheet, there are two lines called Report à Nouveau and Résultat de l'Exercice.
The normal accounting practice is to:
- at year end, debit the Unaffected Earnings account and credit the Résultat de l'Exercice account
- at the affectation of earnings (which typically happens 3-4 months after year end), debit the Résultat de l'Exercice account and credit the Reserves, Dividends and Report à Nouveau accounts.
This commit aims to handle those two lines in a sensible way for real-time accounting:
- the Résultat de l'Exercice line always corresponds to the current year's effective Résultat de l'Exercice (thanks to the cross-report to the P&L)
- the Report à Nouveau line is composed of:
- previous years' earnings that were not affected by a closing entry to any equity account,
- the balance of the Résultat de l'Exercice account, which contains earnings from previous years that were closed, but have not been affected to any other Equity account, and
- the balance of the Report à Nouveau account proper.
Task: 3288626
Forward-Port-Of: odoo/enterprise#42351This fix resolves an error that occurred when users copied shifts from a previous week and then used the auto-planning feature. The issue happened because shifts with zero allocated hours were being processed but then removed from the database, causing the system to reference non-existent records. The fix ensures these empty shifts are properly cleaned up during the planning process.
Original PR description
Before this commit, when the user copies the shifts in the previous week and then auto plan, an error occurs because a record is used but it does no longer exist in the database. The reason is the shift unplanned will be used in the auto plan feature to plan it to an available resource but the problem is that shift has allocated_hours equals to 0 and so it is removed in the process since it means we have no longer something to plan for a specific SOL. This commit recomputes the `planning_hours_planned` to be sure the post_process, called in the create method, remove the shifts unplanned with allocated hours equals to 0. Forward-Port-Of: odoo/enterprise#50275
A previous update inadvertently made input field borders nearly invisible when hovering over form fields. This fix restores the proper border color so users can clearly see input field boundaries in all states, improving the overall usability of the interface.
Original PR description
This commit fixes an issue introduced in Commit[1]. Prior to Commit[1], the `border-color` property of our input was overridden in Enterprise to a `$o-gray-200` value. Commit[1] aimed to fix an issue inside list view where the "add item" button would have a grey background on focus state, by setting the background to a light gray color. Unfortunately, this commit didn't take into account the fact that `$o-form-lightsecondary` is also handling the `border-color` of our input in the hover state. By changing it to `$o-gray-100`, it made it barely impossible to notice. This commit reverts that change, ensuring the `border-color` remains visible in every state. Commit[1]: https://github.com/odoo/enterprise/commit/74bc70a35897274d0bd8d8e53abbdbb48174d8f0 task-3575546 Forward-Port-Of: odoo/enterprise#49832
This update corrects how discount products are treated in the Point of Sale system, specifically in the Belgian blackbox and preparation display modules. The fix ensures discount products are properly classified as special items, which improves compliance and system accuracy for businesses using these POS features.
Original PR description
Related to: https://github.com/odoo/odoo/pull/141001
This fix corrects how inventory lots are transferred between company branches when processing inter-company sales and purchases. Due to recent changes in how inventory quantities are tracked, the system now properly replaces inventory records instead of adding to them, ensuring accurate stock levels across your organization.
Original PR description
Following the quantity-pocalypse, the way quantities are counted in the stock moved lines have changed, meaning we can't simply add new move lines to the inter-company reception as it was done before. Instead clears the old move lines and replaces them with ones having values from the original delivery.