Daily updates from Odoo
Thursday, November 14, 2024
60 changes · 18.0
Enhancements to existing features
The Point of Sale interface now keeps input fields at a consistent width while users type during opening, cash movement, product search, and partner search flows. Receipt previews also stay the same width regardless of the company logo, making the checkout experience more stable and predictable.
Original PR description
Before this commit: ========== - The width of the input field changes when text is added during the session's opening, cash in/cash out, search products, and search partner processes. - The company logo affects the width of the PoS receipt preview. After this commit: ========== - The input field's width stays fixed while adding text during the session's opening, cash in/cash out, search products, and search partner processes. - The width of the PoS receipt preview remains fixed as well. task-4285446
Several common website landing pages are now treated as read-only when visitors use search or filtering options. This helps avoid unnecessary changes during browsing and can improve reliability and performance across public website areas such as events, forums, eCommerce, courses, profiles, and partner pages.
Original PR description
Some common 'landing pages' used in combination with search parameters can be set as read-only.
Opening invoice and bill forms is now faster on large databases because the duplicate-reference warning uses more targeted searches. This reduces wait time for accounting users while keeping the same duplicate detection behavior.
Original PR description
## Description A warning is shown on the form view of invoices/bills, to warn when a possible duplicate is present in the database. The query searching for those duplicates contained disjonctions for…
## Description A warning is shown on the form view of invoices/bills, to warn when a possible duplicate is present in the database. The query searching for those duplicates contained disjonctions for matching conditions for both 'in' moves and 'out' moves. Postgres doesn't plan well with that disjonction (subplan scan with high-filter rate, non-indexable due to the disjonction). Splitting that disjonction into 2 queries (one for each type of in/out, lazily) leads to better plans and also faster execution, since there is better segragation of the lookup criteria (there is no need to check for a potential duplicate customer invoice in the set of vendor bills for ex.). ## Benchmark On database with millions of invoices, opening an invoice form view, the `_fetch_duplicate_reference` | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 1s | 40ms | 25x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts accounting report tests to match the newer way accounting entries receive their official numbers when they are posted, rather than while still in draft. It helps keep automated checks reliable after the related accounting behavior change, with no direct change expected for business users.
Original PR description
Description of the issue this commit addresses: The community PR linked to this one modified the naming behavior of moves and therefore tests have broken. This PR adapts thoses tests to the new…
Description of the issue this commit addresses: The community PR linked to this one modified the naming behavior of moves and therefore tests have broken. This PR adapts thoses tests to the new behavior. --- Old vs. New naming behavior: Let's consider an empty journal. In this journal three moves are added with decreasing date (move1 is the most recent, move2 is in the middle and move3 is the oldest). now we batch the moves and post them together. Before, the first move of a journal would consume the first sequence number upon its creation even in draft and subsequent moves in would be named "/". When batched and posted afterwards, in the `_compute_name()` method, a `.sorted()` would order the moves by date (account.move(3, 2, 1)) and would use that order to name them. As the first sequence number is burned, move3 will use the second number and move2 will use the third number in the sequence. Resulting names: move1: 1, move2: 3 and move3: 2. With x moves: move1: 1, move2: x, move3: x-1, move4: x-2, ... Now, since no sequence number name is ever assigned to a draft entry, upon their creation, all three moves are named "/". And then, when they are batched and posted. they will be ordered 3,2,1 just like before but when naming move3, the first sequence number isn't consumed anymore so it will be named 1, move2 will be name 2 and move1 will be name 3. Resulting names: move1: 3, move2: 2 and move3: 1. With x moves: move1: x, move2: x-1, move3: x-2, move4: x-3, ... --- Desired behavior after this commit is merged: Tests that were relying on the fact that the first move of a sequence uses the first sequence number upon creation and not when posted are now adapted to take into account that sequence number are consumed when posted. --- Community PR: https://github.com/odoo/odoo/pull/185326 task-4241510
The document sharing panel now opens faster by waiting to load invitee suggestions until a user actually opens the invite menu. This reduces the delay after clicking the share button and improves the day-to-day sharing experience.
Original PR description
In production, there is a delay of around 1 second between the moment the user clicks on the share button and the share/permission panel appears. That is not good UX. To reduce that delay, this commit removes the fetching of partner options (for members' invite) when the permission panel is about to open. The RPC call is now done when users open the select menu to invite new members. task-4309414
Resolved issues and error corrections
Creating a new item from a many-to-many tag field now keeps relevant default information, such as a preselected product, when using Save & New. This prevents users from having to re-enter expected values and reduces mistakes during repeated record creation.
Original PR description
Have a field with many2many_tags widget and a context containing `default_` keys (e.g. `{'default_product_id': 45}`). Type something in the input and click on "Create and edit". In the dialog, the name should be prefilled with the value you typed in the input. Moreover, the product should be set to product 45. Click on "Save & New". Before this commit, all fields were empty, because we removed from the context all `default_` keys.
This is correct to remove the `default_name` key, as we already created that record. However, we must keep the others.
This issue has been introduced with the wowl implementation of the Many2ManyTagsField/FormViewDialog.
task~4331742
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-prFixes an issue in the HTML editor color picker where choosing the radial gradient option that extends to the farthest corner would not stay selected on the first attempt. This makes gradient styling more predictable for users editing text or backgrounds.
Original PR description
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to…
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to select 4th option of size (extend to the farthest corner). - Selected option is deselected and gets switched to first option. - If we try to select it again then it gets selected. The issue happens because `fathest-corner` is the default size parameter for radial gradient. When we apply background-image property for farthest-corner it gets simplified later and rendered without keyword `'farthest-size'`. E.g.` radial-gradient(circle farthest-corner at 50% 50%, rgb(255,..` will be simplified to `radial-gradient(circle at 50% 50%, rgb(255,..` Due to this reason when we get background-image property using `style['background-image']` we get simplified value. As result in `setGradientFromString` method regex fails to extract the value of `'farthest-corner'` and `state.size` is set to `'closest-side'` which is our first option. **Desired behaviour after PR:** Now, default size is set to `'farthest-corner'` and 4th option is selectable. task-4240711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the translation button behavior when editing the base structure of form views. It helps administrators using technical settings access translations reliably after a previous interface structure change.
Original PR description
The html structure translation button is changed in https://github.com/odoo/odoo/pull/184900 This commit fixes the hack for the translation button for ir.ui.view.arch_base reproduce the bug Settings -> Technical -> Views -> open any form view  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
Order lines in Point of Sale and restaurant orders are now only marked as changed when they have actually been edited. This avoids unnecessary follow-up synchronization work and helps keep order status more accurate.
Original PR description
Before this commit, lines was always set as dirty when synchronizing orders. This was due to the fact that the line was marked as dirty in the synchronization process, even if the line was not modified. This commit fixes this issue by only marking the line as dirty if it has been modified. taskId: 4314110
This fixes a timing issue in the payment form by ensuring the system waits for the payment request to complete before continuing. It helps avoid incomplete or inconsistent payment flows for customers during checkout.
The manufacturing work order list now uses clearer compact icons for key actions and better signals when a work order is blocked. This makes daily shop-floor task management easier to scan and reduces layout issues in list views.
Original PR description
Duplicate of https://github.com/odoo/odoo/pull/134187 but without the dirty css hack --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adds a missing dependency so purchase orders can correctly calculate related repair counts. It prevents setup or loading issues when the repair and purchasing features are used together without relying on automatic module installation order.
Original PR description
The field [`purchase.order.repair_count`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_repair/models/purchase_order.py#L8-L13) depends on field `order_line.move_dest_ids.repair_id`, and [`move_dest_ids`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_stock/models/purchase_order_line.py#L28) is defined in module `purchase_stock`, but it is not an explicit dependency and the autoinstall does not guarantee the existence of the module. Fixing the dependency to ensure the field `purchase.order.repair_count` can be computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the background color used in the outstanding credits section of customer invoices when dark mode is enabled. It improves readability and visual consistency for users reviewing invoice credits.
Original PR description
Fix the background color for customer invoices on the outstanding credits section. task-4326841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users when closing a Point of Sale session after recording a negative payment difference. The session can now proceed without showing a technical traceback, improving reliability during register closing.
Original PR description
When the customer tries to close the pos session, a traceback will appear. Steps to reproduce the error: - Go to Point of Sale > Configuration > Payment Methods > Create new > In Journal: Bank > Save…
When the customer tries to close the pos session, a traceback will appear. Steps to reproduce the error: - Go to Point of Sale > Configuration > Payment Methods > Create new > In Journal: Bank > Save - Open a session > Add a product > Payment > select that payment method > validate - Close Register > Now in count, Add such a number so that the difference will become negative > Close Register > Proceed Anyway Error: A traceback appears: ``` "TypeError: cannot unpack non-iterable bool object" ``` When the customer closes the pos session, ``_apply_diff_on_account_payment_move`` method will be called. It will call ``_get_diff_vals`` method. When ``_get_diff_vals`` method returns the ``False``, https://github.com/odoo/odoo/blob/5a390fede312513a5c9b91d2d18d6d0cfdd43750/addons/point_of_sale/models/pos_session.py#L622-L634 So Here, ``source_vals``, ``dest_vals`` will be ``False`` https://github.com/odoo/odoo/blob/5a390fede312513a5c9b91d2d18d6d0cfdd43750/addons/point_of_sale/models/pos_session.py#L1094 So, It will lead to the above Traceback. sentry-5607468115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Discuss app now displays the Threads and Invite People popovers at a stable width, preventing unwanted horizontal scrolling. This makes these actions easier to read and use, especially in constrained panel layouts.
Original PR description
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a…
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a panel, but these panels could also be displayed in popover in which this rule shouldn't apply. This commit fixes the issue by fixing a constant width to these action panels in popover, with similar width as the messaging menu. Task-4292021 Before / After - Threads <img width="400" alt="Screenshot 2024-11-13 at 18 42 41" src="https://github.com/user-attachments/assets/5701333c-9623-4ae8-bc10-0900251d353f"> <img width="593" alt="Screenshot 2024-11-13 at 18 45 41" src="https://github.com/user-attachments/assets/62393043-5a88-468d-acde-7fbee837be2e"> Before / After - Invite People <img width="407" alt="Screenshot 2024-11-13 at 18 42 48" src="https://github.com/user-attachments/assets/03025c09-1e9c-4790-a708-627f0aa731ec"> <img width="691" alt="Screenshot 2024-11-13 at 18 43 10" src="https://github.com/user-attachments/assets/8ef9ad7c-d7b1-4a44-a0b3-f1e4525e0fa4">
This fix speeds up an automated website menu editing test so it is less likely to fail because of timing limits. It helps keep quality checks reliable without changing the customer-facing website experience.
Original PR description
In this commit, we force checkDelay to 100ms (default is 500ms) to make the tour faster and avoid script timeout exceeded error. 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 removes an unnecessary warning from the mail-related logs by correcting how a text replacement option is passed internally. It helps keep system logs cleaner and avoids distracting administrators with a harmless technical warning.
Original PR description
Description of the issue/feature this PR addresses: Passing the regex flags in place of positional argument `count` generates a warning. Pass correct argument to `re.sub()` Current behavior before PR: Warning appears in log about incorrect use of positional parameter `count`. Desired behavior after PR is merged: No warning appears in log by `mail` addon due to usage of `re.sub`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes the spreadsheet component to the latest version and fixes issues affecting chart display and color selection. Users should see more accurate date line charts, improved area chart trend lines, and a cleaner color picker experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/88e1aeeb4 [REL] 18.0.4 Task: 0 https://github.com/odoo/o-spreadsheet/commit/bb046c5db [FIX] chart: date line chart Task: 4268977 https://github.com/odoo/o-spreadsheet/commit/064a7cf84 [FIX] color_picker: conditionally hide reset button Task: 4102704 https://github.com/odoo/o-spreadsheet/commit/2cb20cee6 [FIX] chart: trend line of area chart Task: 4274294 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
A typo in the sale PDF quote builder test was corrected. This helps keep automated checks reliable and prevents false test failures during development.
Original PR description
There was a typo in test_pdf_qoute_builder. This commit corrects it. [broken test](https://runbot.odoo.com/web#id=74907&view_type=form&model=runbot.build.error&menu_id=405&cids=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers paying through Worldline are now sent back to the website where they started checkout, even when the business runs multiple websites. This prevents users from landing on the wrong site after payment and keeps the checkout experience consistent.
Original PR description
In multi-website context, we should return the user to the root of the origin website which is not necessarily the same as the one from `web.base.url` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an installation problem where the Repair module could fail if Inventory was already installed but not yet updated. The change makes the Repair setup compatible with both older and newer Inventory layouts, reducing upgrade and installation interruptions.
Original PR description
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined…
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined in the repair module that reference the changed form in the stock module. However, if stock wasn't upgraded, then the new label / div don't exist yet, leading to an error as the xpaths link to something that doesn't exist yet. This means that this patch needs to work with two possible versions of stock: - The old one, with only <field> in the form - The new one, with <field> and <label> in the form Due to that singular situation, it made the declaration of xpath in repair impossible to have a proper target, as both versions of stock would require different targets and cannot co-exist. To solve that situation, the choice was made to overwrite completely the common ancestor of the two versions (i.e. the locations <group>) and write it back in repair as if every previously declared xpath have been applied to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Belgian reporting where a description could be too short for expected form requirements. It helps keep generated tax/reporting forms compliant and reduces the risk of validation errors during submission.
Original PR description
The aim of this commit is Context: Before the commit: After the commit: Community-PR: Enterprise-PR: Upgrade-PR: task-id:
This fixes a receipt printing problem in Italian point of sale setups when rounding is applied to discounted totals. Cash registers should no longer enter an error state for small rounding adjustments, helping checkout continue smoothly.
Original PR description
When a rounding amount is sent to the cash register, the printer goes into error.
e.g.
```
Product price 1,21
rounding -0,01
total 1,20
```
There is a code in the XML receipt which must be quoted as a string value.
When writing the rounding without it, the printer crashes.
CLA signed here: odoo/odoo#186833Sign request emails now use the recipient-selected language consistently across both the message body and email layout. This avoids mixed-language emails, making signature requests clearer and more professional for recipients.
Original PR description
**Email layout is not translated to targeted sender's language with Sign mails** Impacted versions: - 18.0 Steps to reproduce: 1. Create a partner with language other than the current user's language. 2. Create a sign request and send the request to the created partner. 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This differs from the language in the body. Current behavior: Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. Expected behavior: After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
Code cleanup and technical improvements
This update reorganizes how the HTML editor coordinates toolbar actions, shortcuts, power buttons, and internal editor events. It makes the editor code clearer and easier to maintain, reducing future development and debugging complexity without changing the intended user experience.
Original PR description
# Use delegate There is a common pattern in the editor plugins where we allow other plugins to take over the handling of a command. In order to make it explicit in the code, this commit introduces a…
# Use delegate There is a common pattern in the editor plugins where we allow other plugins to take over the handling of a command. In order to make it explicit in the code, this commit introduces a new utility function called delegate that will be used to call the handlers. # Use trigger In the editor, the pattern to dispatch events from one plugin to other plugins is to use the resource mechanism that aggregates callbacks to a specific resource. In order to make it clear when reading code that we want to dispatch an event, this commit introduces the util function trigger that communicates the intent to the reader. # Remove dispatch Reasons: 1) It is a redundant mechanism, we can achieve the same result though the use of shared and resources. 2) Using the shared or the resources is more explicit. If we need to call a command from a specific plugin, we should depend on the plugin and use the shared. If we need multiple plugins to react to an "event", we should use the resources. 3) We should distinguish between a "user command" and a "system command" or "system event". - A "user command" is anything that a user could configure as a shortcut, toolbar item, powerbox item, or power button. - A "system command" is a shared method. - A "system event" is a resource. 4) When debugging, it was harder to "step into" a dispatched command as we would step into the `handleCommand` of every plugins. For `toolbarItems` and `powerboxItems` now inherit the properties of a user command through the `commandId` property (if specified). The power buttons now use the definition of the user commands instead of the powerbox items. The `toolbarItem` `Component` does not includes dispatch in the props by default anymore, we need to specify the callbacks in the props of the `toolbarItem` explicitly.
Miscellaneous changes
Problem: Account tour was reworked in 17.4, but the markup was lost in the initial `goToAccountMenu` step Solution: Restore the markup to display message as intended opw-4311046 Forward-Port-Of: odoo/odoo#186345
Original PR description
Problem: Account tour was reworked in 17.4, but the markup was lost in the initial `goToAccountMenu` step Solution: Restore the markup to display message as intended opw-4311046 Forward-Port-Of: odoo/odoo#186345
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186958 Forward-Port-Of: odoo/odoo#185620
Original PR description
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186958 Forward-Port-Of: odoo/odoo#185620
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#187074 Forward-Port-Of: odoo/odoo#186814
Original PR description
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#187074 Forward-Port-Of: odoo/odoo#186814
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: re
Original PR description
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: reported during the mobile tests conversion to HOOT in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187110
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the POS configuration Error:- ``` ValueError: Expected singleton: account.journal(14, 18) ``` This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386 In `copy` method, when multiple records are dupli
Original PR description
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the…
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the POS configuration Error:- ``` ValueError: Expected singleton: account.journal(14, 18) ``` This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386 In `copy` method, when multiple records are duplicated it executed the method at multiple times. so `self` should have a single record at a time. From the `saas-17.2`, the `copy` method changes to `copy_data`, So it is executed at a time when the `self` having multiple recordsets. This leads to a traceback as `self.journal_id.type` is used. https://github.com/odoo/odoo/blob/88604332ae37d75c1435a298319a378841abf25a/addons/point_of_sale/models/pos_payment_method.py#L166-L168 sentry-5790593911 Forward-Port-Of: odoo/odoo#187061 Forward-Port-Of: odoo/odoo#179058
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
Original PR description
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified
Original PR description
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue. opw-4272165 Forward-Port-Of: odoo/odoo#186595 Forward-Port-Of: odoo/odoo#186000
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of
Original PR description
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails…
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and formatted emails in various email input. This notably leads to better formatted email computation on partner that generates emails like '"email@example.com" <email@example.com>' when email is used both as name and email. When sending emails to this partner only a single email should be sent and counted. A fix is been done to remove duplicates in that tool, making the returned list unique. In this PR we allow to receive a pre-validated list of emails that restricts emails found by 'extract_rfc2822'. When going through classic flows, we already computed emails using 'email_split' and its subtools, hence we just need the encoding check of 'extract_rfc2822'. Additional emails found by that tool are ignored as we consider those are fake emails. This PR contains tests and fixes related to that issue as well as multi and formatted emails management. Task-3704658 Forward-Port-Of: odoo/odoo#186967 Forward-Port-Of: odoo/odoo#185793
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
Original PR description
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Original PR description
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#187049 Forward-Port-Of: odoo/odoo#180304
Original PR description
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#187049 Forward-Port-Of: odoo/odoo#180304
Version: - saas 17.4 Steps to reproduce: - Install the website_sale module. - Open the pricelist and apply a discount to a product. Issue: - The discount price on the product page appears in a red "danger" color. Solution: - Changed the text class from "text-danger" to "text-muted" to fix the issue. opw-4277128 Forward-Port-Of: odoo/odoo#185038
Original PR description
Version: - saas 17.4 Steps to reproduce: - Install the website_sale module. - Open the pricelist and apply a discount to a product. Issue: - The discount price on the product page appears in a red "danger" color. Solution: - Changed the text class from "text-danger" to "text-muted" to fix the issue. opw-4277128 Forward-Port-Of: odoo/odoo#185038
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve =
Original PR description
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so.…
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve => Post Journal Entries) 6. An error message about missing vendor (res.partner) appears Cause: The field work_contact_id keeps the link between hr.employee and res.partner, and is updated in the function _sync_user. Since work_contact_id=user.partner_id.id, when the user is removed from the hr.employee, work_contact_id is also removed. Fix: The link between hr.employee and res.partner should be kept until the user is assigned to another employee. In this case, the partner associated to the user should also be associated with the second employee, and no longer to the first employee. To do so, _sync_user assigns _origin.user_partner_id to work_contact_id if no user is passed (in case the user is removed). A helper function is called when creating or writing an employee, to unlink the partner and the previous employee in case the user is assigned to another employee. task-4049996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186998 Forward-Port-Of: odoo/odoo#175478
This commit adds a new helper to create a headless model from grid data. This helper is used for a test in enterprise, but should be used in the future. Task: 4277518 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 Forward-Port-Of: odoo/odoo#184826
Original PR description
This commit adds a new helper to create a headless model from grid data. This helper is used for a test in enterprise, but should be used in the future. Task: 4277518 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 Forward-Port-Of: odoo/odoo#184826
Before this commit, the tester did not account for the use of an SQL wrapper inside of the constructor of an other SQL wrapper, This lead to a RecusionError when trying to infer the value of the Call node. This simple fix prevent the check of an other SQL wrapper during the classical call node analysis. This Call node would be analysed anyway during the visit_call function. Forward-Port-Of: odoo/odoo#187071
Original PR description
Before this commit, the tester did not account for the use of an SQL wrapper inside of the constructor of an other SQL wrapper, This lead to a RecusionError when trying to infer the value of the Call node. This simple fix prevent the check of an other SQL wrapper during the classical call node analysis. This Call node would be analysed anyway during the visit_call function. Forward-Port-Of: odoo/odoo#187071
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat n
Original PR description
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat number for a specific country, it means they have a tax report to fill and thus must have installed the related localization either as main CoA or as a foreing fiscal position. 2) This was spotted through a runbot single l10n build error. Nevertheless, it is something that is possible and thus should be working smoothly. runbot-100532 Forward-Port-Of: odoo/odoo#186942
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing missed assignments. To fix this, the parameter `creation_delta_days` is now set to 0 during manual assignment, bypassing the 7-day creation filter. This ensures that all leads, regardless of creation date, are assignable manually. https://github.com/odoo/odoo/blob/saas-17.4/addons/crm/models/crm_t
Original PR description
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing…
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing missed assignments. To fix this, the parameter `creation_delta_days` is now set to 0 during manual assignment, bypassing the 7-day creation filter. This ensures that all leads, regardless of creation date, are assignable manually. https://github.com/odoo/odoo/blob/saas-17.4/addons/crm/models/crm_team.py#L441#L445 Steps to reproduce: 1. Go to CRM settings and activate `Rule-Based Assignment` and `Leads`. 2. Navigate to CRM Configuration > Sales Teams. 3. Create a new sales team with `Leads` active. 4. Add a member to the team, save, and try to assign leads. Expected behavior: All leads, regardless of creation date, should be assignable when manually assigned. opw-4217088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185529
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Fo
Original PR description
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Forward-Port-Of: odoo/odoo#124300
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ t
Original PR description
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ tax to pay Why the fix: ------------ We match the behavior of sales app, and ignore the fixed price taxes when creating the downpayment lines. opw-4163579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183385 Forward-Port-Of: odoo/odoo#182380
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior.
Original PR description
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior. After this commit, we prevnt the browser to apply its behavior. 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 Forward-Port-Of: odoo/odoo#186964 Forward-Port-Of: odoo/odoo#186566
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Original PR description
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the time of the fix, installing PWA apps on iOS had necessarily push notification enabled. However this no longer seems to be the case: PWA apps on iOS must now explicitly asks for enabling push notifications. This is also a necessary step in order for the PWA apps to be shown in iOS Settings > Noti
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the…
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the time of the fix, installing PWA apps on iOS had necessarily push notification enabled. However this no longer seems to be the case: PWA apps on iOS must now explicitly asks for enabling push notifications. This is also a necessary step in order for the PWA apps to be shown in iOS Settings > Notifications. This commit fixes the issue by not showing button to enable push notifications specifically on iOS outside of app. That way there's no persistent notification on Safari while push notifications can still be enabled. Extra notes: - iOS requests for push notifications seem to require HTTPS, otherwise they are necessarily blocked. - iOS 17 does not show the dialog to accept or deny push notifications. This is likely an iOS bug that has apparently been fixed with iOS 18. Forward-Port-Of: odoo/odoo#187038
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#73486 Forward-Port-Of: odoo/enterprise#66901
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#73486 Forward-Port-Of: odoo/enterprise#66901
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de66
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 --- Forward-Port-Of: odoo/enterprise#73473 Forward-Port-Of: odoo/enterprise#72626
Steps to reproduce: - Create a subscription product with two or more plans - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart Current behavior before PR: After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the pl
Original PR description
Steps to reproduce: - Create a subscription product with two or more plans - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart Current behavior before PR: After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the plan_id selected https://github.com/odoo/enterprise/blob/18.0/website_sale_subscription/static/src/js/website_sale_subscription.js#L14 we don't find any element with this path. Desired behavior after PR is merged: We are changing the path that we get the value of the selected plan out of so we can make sure it is getting the right element which will get the right value accordingly. opw-4296527 Forward-Port-Of: odoo/enterprise#73768 Forward-Port-Of: odoo/enterprise#73677
The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582
Original PR description
The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one
Original PR description
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC…
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one of the payments, click 'Force CFDI' Issue: Validation will fail with error Note: This does not occur with other providers (Solucion Factibles) ``` Code : CRP20275 Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado, convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto. ``` This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance opw-4314798 Forward-Port-Of: odoo/enterprise#73696
opw-4272165 community: https://github.com/odoo/odoo/pull/186595 Forward-Port-Of: odoo/enterprise#73715
Original PR description
opw-4272165 community: https://github.com/odoo/odoo/pull/186595 Forward-Port-Of: odoo/enterprise#73715
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Original PR description
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73728 Forward-Port-Of: odoo/enterprise#71512
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73728 Forward-Port-Of: odoo/enterprise#71512
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
Original PR description
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as
Original PR description
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab >…
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure. We can't just set it to 0 though: This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0. This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach. opw-4266880 Forward-Port-Of: odoo/enterprise#73469
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Original PR description
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware. We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation. Validation is done based on the Avalara documentation [2]. [1] As outlined in "Nota Técnica 2021.003 Validação GTIN" https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8OD
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168
Forward-Port-Of: odoo/enterprise#73536
Forward-Port-Of: odoo/enterprise#735172 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73592 Forward-Port-Of: odoo/enterprise#70703
Original PR description
2 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73592 Forward-Port-Of: odoo/enterprise#70703