Search
Navigate
Branch
Friday, March 1, 2024
120 changes
47 changes
New functionality added to Odoo
This update adds support for Jordanian country states to the Odoo system. Previously, Odoo did not recognize or allow for state-level selection within Jordan. This change ensures users can accurately manage locations within Jordan, improving data accuracy and operational efficiency.
Original PR description
Description of the issue/feature this PR addresses: Add country states for Jordan Current behavior before PR: No country states are imported by default for Jordan Desired behavior after PR is merged: Country states are imported by default for Jordan --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155010
Enhancements to existing features
This update enhances the speed and accuracy of product and partner searches within Point of Sale. The new search algorithm, based on the Smith-Waterman algorithm, reduces irrelevant results and prioritizes exact matches, leading to a better user experience. Additionally, search results are now displayed in the order of the search query, increasing relevance.
Original PR description
Before this commit, the fuzzyLookup function from the web was used, which had some issues when users searched for exact terms to find products or partners with a limited number of characters. It often showed irrelevant items, which was confusing for the users. With this commit, a new fuzzy lookup based on the Smith-Waterman algorithm for local sequence alignment is implemented. Also it improves the search accuracy by giving a bonus when the exact term is found in a text. Additionally, the product search results are now displayed based on the search order, instead of being sorted by the product name. This change makes the search results more relevant to the user's search query. opw-3766742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a previous issue where Point of Sale performance was impacted by large product catalogs. A new setting, 'point_of_sale.limited_product_count', allows administrators to control the number of products initially loaded, optimizing performance for businesses with extensive product lists. This ensures a smoother and faster Point of Sale experience.
Original PR description
This commit re-enables the limited product loading feature that was inadvertently removed in a recent refactor. This feature is essential for databases with a large product catalog. The feature can now be configured using the "point_of_sale.limited_product_count" system parameter. This parameter determines the number of products initially loaded in the Point of Sale. opw-3758356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
35 changes
New functionality added to Odoo
Adds support for Canadian CPA 005 electronic payment files so businesses can submit batch vendor payments to participating banks. The feature includes configurable bank file numbering, payment validations, and guidance to reduce rejected files and manual troubleshooting.
Original PR description
18 changes
New functionality added to Odoo
UK users can now create customer statements by default in Odoo 17. This new feature addresses a frequently requested capability by automatically enabling the customer statements module for UK-based companies, making it easier to generate and manage customer account statements.
Original PR description
UK users often request the option to create customer statements. Now that the customer statements module has been deployed in Odoo 17, UK users can benefit from it by default. Since this is needed in 17.0, this commit creates a bridge module. task-3764637
This update adds ‘lastmod’ attributes to forum post URLs in the website sitemap. This helps search engines like Google efficiently crawl and index our forum content, improving its visibility. While complex date tracking is difficult across the website, this targeted approach focuses on the forum, providing a reliable way to signal content freshness.
Original PR description
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each…
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each one of them in a single go.
The best you can help those crawler, the better. The sitemap `lastmod` attribute, despite not being fully respected and trusted by crawlers, is one of the way you can still try to help them.
For website.pages, it's already done. But for controllers, it's not an easy thing to do as we have no way to automatically figure what are the relevant records/fields to look at to know the last update date. For instance, on the event pages, some pages content are mostly stored inside an `ir.ui.view`, but the title, hours etc are part of the event itself.
We can't just say "we take the last write_date of the record", it's wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get all the elements part of the page rendering and would miss a possible element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable): the `write_date` is often updated for non website related purposes. For instance, on /partners/<partner>, we wouldn't be able to use the write date on odoo.com as the partners shown there (having a grade) are update every weeks in average, because of many fields, for instance: commission_plan_id, partner_weight, grade_id, ...
Still, there is a quick win possible in stable about forum posts which are not impacted by the 2 issues explained above:
- There is a dedicated `last_activity_date` field which is updated only when relevant information are modified. We can ensure to show a date which is not updated too frequently for no reason.
- All the forum.post information displayed on the page are stored inside the forum.post itself.
This commit is thus adding the `lastmod` on forum.post URLs in the sitemap in hope of not making Google waste time on (very) old posts.
Note: the `lastmod` has to be trustworthy and correct, if you set wrong
or outdated info inside it, Google won't trust you/it anymore.
Forward-Port-Of: odoo/odoo#155197This update adds a placeholder to the industry selection field on the website creation process. Previously, users were unsure of what information to enter, leading to potential confusion. This simple addition provides a helpful hint, streamlining the website setup for our customers.
Original PR description
-User might not know what they going to type in, this commit add a placeholder in the input of industry selection to give a hint for user when in website creation 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#155862
This update fixes a previous issue where products within a POS category's child categories weren't visible. Now, all products associated with a category and its children are correctly displayed, improving the user experience for product browsing in the Point of Sale system. This ensures accurate product listings and simplifies the sales process.
Original PR description
Before this commit, if a POS category had children, we didn't show the products in the child categories. This commit fixes this issue by ensuring that products in child categories are also displayed. opw-3754832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where QRIS code generation for countries other than Indonesia didn't display error messages. Now, the system will correctly generate an error if a bank account from a different country is used, ensuring accurate QR code generation and compliance.
Original PR description
At the moment, QRIS is not returning an error message when you try to generate a QR code with a country that is not Indonesia. It will instead skip all checks and return no errors. This fix will ensure that we arise an error if we try to generate the QR code with a bank account from another country. Task id # 3758668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where manually editing follower lists could cause errors when assigning users to records after merging. The change ensures that follower lists are always up-to-date, preventing duplicate entries and improving the reliability of follower management. This primarily impacts users managing leads and contacts.
Original PR description
`_message_auto_subscribe` relies on `_get_subscription_data` to know who is subscribed to what. This method uses a raw SQL query but doesn't flush the relevant records beforehand. This is not an issue in most normal cases, but if followers are edited manually, for example in order to merge existing models, it may cause issues when then assigning someone to the model will attempt adding them to the list of followers, when they already were on it. task-3713472 original issue in opw-3634410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155043 Forward-Port-Of: odoo/odoo#152041
This update resolves an issue where users were unable to save custom background colors for product ribbons on the website. The fix adds an 'important' tag to the ribbon color setting, ensuring changes are applied as intended. This improves the user experience by allowing for personalized product displays.
Original PR description
Before this commit, the `bg-primary` class was overwriting the `bg_color` set by the user after saving changes as it has the `!important` tag. Steps to reproduce the issue: 1. Go to Shop page on website 2. Enable edit mode 3. Pick a product and create a new Badge (ribbon) 4. Change the background color and save changes -> color reverts to `bg-primary` This commit fixes this behavior by adding the `!important` tag to the `bg_color` so that it properly overwrites the `bg-primary` color. opw-3734598 Forward-Port-Of: odoo/odoo#155040
This update resolves an issue where the PoS user's partner information wasn't consistently loaded, potentially causing problems with cash transactions. By always loading the PoS user partner, this fix guarantees accurate cash handling and improves the overall Point of Sale experience. This change is a critical fix for reliable operations.
Original PR description
Prior to this commit, in cases with a large number of customers in the database, we loaded a limited number of customers. This could potentially exclude the PoS user partner, causing issues during cash in/out operations. This commit ensures the PoS user partner is always loaded to prevent such issues. opw-3767023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where cash in/out operations failed when multiple employees were logged into a session. The recent refactoring of a key data field caused this conflict. This change ensures reliable cash management functionality regardless of the number of employees using the system.
Original PR description
Before this commit, if multiple employees were enabled in a session, performing cash in/out operations would cause an error. This was due to a recent refactor where the 'work_contact_id' was changed to an object. opw-3764015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue where loyalty points were being displayed with slight rounding errors due to how the system calculates points. The change ensures that loyalty points are shown accurately, providing a better customer experience. This improves the reliability of the loyalty program's point calculations.
Original PR description
Steps ----- 1. Create a loyalty card program awarding 1 point per $ spent; 2. make sure "Show points Unit" is enabled; 3. give yourself a loyalty card with 267.39 points on it; 4. create a product with a price of $0.89; 5. go to website and add it to your shopping car; 6. go to checkout. Issue ----- > You have 268.28000000000003 Loyalty point(s) Cause ----- The number comes from the `_get_real_points_for_coupon` method, which uses `float_round` by way of `res.currency`. The `float_round` function isn't suited for raw number display, as it can make tiny rounding errors due to floating point arithmetic. Solution -------- Add a `_format_points` method to `loyalty.card` which will return a string using the same format the `points_display` field uses. opw-3705546 Forward-Port-Of: odoo/odoo#155466 Forward-Port-Of: odoo/odoo#153541
This update fixes an issue where pricelists created in new databases caused problems with multi-company sales reporting. The change now ensures pricelists are tied to the current company, simplifying setup and preventing errors, especially for businesses using a single company.
Original PR description
Since 83c52575d0ce3d7deb1737c622c6ce366db8c31b, there is no default pricelist in new database, and a magic pricelist is created for each company when the pricelist setting is enabled. But, since this…
Since 83c52575d0ce3d7deb1737c622c6ce366db8c31b, there is no default pricelist in new database, and a magic pricelist is created for each company when the pricelist setting is enabled. But, since this automatically created pricelist is restricted to a specific company, you couldn't use it as 'Base' for rules of other pricelists, which are, by default, shared between companies, unless you set a specific company on them. This commit changes that default behavior, to restrict pricelists to the current company (unless the field is manually emptied), to avoid those multi-company issues, particularly in single-company databases where multi-company issues are not expected. Also, while testing this task, we discovered that a user could change the company of a pricelist, even if it conflicted with existing rules. To avoid this situation, we now trigger the multi-company check on the pricelist rules when the pricelist company is updated. task-3610823 See odoo/enterprise#55857 Forward-Port-Of: odoo/odoo#147014
This update corrects a bug that limited the number of documents available for scheduling activities after multiple scheduling attempts. The fix ensures that all documents are accessible during the scheduling process, preventing the restriction of available records. This improves the user experience when managing activities.
Original PR description
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to…
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to schedule an activity for the 3rd time. (Only 2 docs are available) **Issue:** Since 7682286, the existing props of activity model are being passed as params while scheduling an activity. Currently, `["activity_ids", "!=", false]` is being pushed to the domain of activity model in order to display only those records on which activities have been set. As a result, after you schedule activities more than once, `["activity_ids", "!=", false]` domain gets applied and the list of documents available for scheduling activity is restricted to only those specific records from the third time onwards. **Fix:** This PR passes the 'searchParams' of activity model as params to the 'load' method while scheduling activity, instead of existing props, to ensure that the existing params are applied, as well as all documents are accessible while scheduling activity in `searchCreateDialog` (i.e. ["activity_ids", "!=", false] condition is not added to its domain). Task: [3721750](https://www.odoo.com/web#id=3721750&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#155700 Forward-Port-Of: odoo/odoo#153606
This update resolves an issue where the 'l10n_ar_withholding' module couldn't be installed correctly when multiple Argentine companies were set up in Odoo. The fix ensures that tax data is properly calculated and linked to each company individually, preventing compatibility errors.
Original PR description
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization…
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization to Argentina (e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Switch to Company B - Go to Accounting settings - Set Fiscal Localization to the same Fiscal Localization than Company A (i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Try to install "l10n_ar_withholding" module Issue: A User Error is raised: "Incompatible companies on records: - 'account.tax.repartition.line,1230' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1232' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1234' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company. - 'account.tax.repartition.line,1236' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company." Cause: When installing "l10n_ar_withholding" module, each Argentine company is updated with some tax data. These data are "generic" (not linked to any company) and used for each company, but some treatment is performed on them by the first Argentine company, linking them to the account ids of that company. The following companies are then updated with data linked to the first company. Solution: Compute the data for each company. opw-3709819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154219
This update fixes an issue where the website's header search field couldn't be accessed using the keyboard. The change ensures all users, including those using assistive technologies, can easily find and use the search function, improving website usability and accessibility. This resolves a previous accessibility concern.
Original PR description
This commit resolves the accessibility issue where the search field located within the header was not navigable (see [1]) via keyboard tabbing, rendering it inaccessible to users relying on keyboard navigation. This fix ensures that users can seamlessly navigate to the search field in the header using the keyboard, thereby enhancing the overall accessibility and usability of the website. [1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822 task-3607481 Forward-Port-Of: odoo/odoo#153197
This update corrects a bug where changing the end date of a shift template would reset the start date. The issue stemmed from how Odoo calculates date values, and this fix ensures that date fields retain their original values when templates are used. This improves data consistency and prevents unexpected behavior when creating shifts.
Original PR description
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and…
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and `start_datetime` have the same compute method - `template_id` depends on `start_datetime` and `end_datetime` - so changing `end_datetime` triggers the compute method of `template_id` that will read `start_datetime` - reading `start_datetime` triggers the compute method of `end_datetime`, that will check if `template_id` is set and if so, will take its values ------- why the compute method of `end_datetime` is triggered ? : ------- - `start_datetime` is not protected from recomputing, at this line : https://github.com/odoo/odoo/blob/83aa46a4ab88c0226b1aa1dc36671d3208a0835a/odoo/models.py#L6746 we only protect the fields sent by frontend (only `end_datetime`) - frontend doesn't send `start_datetime` as it was not changed Solution ======== as ORM fix can't be made in stable, we send `start_datetime` in the `onchange` query even if it's unchanged to make sure both fields are protected opw-3693206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155705 Forward-Port-Of: odoo/odoo#154190
This update resolves an issue where the COA SAT(XML) export generated warnings on newly created databases. The fix corrects incorrect account tags, particularly for 102 accounts, ensuring the report functions correctly out-of-the-box. It also includes a default tag calculation for new accounts.
Original PR description
Steps to reproduce: 1. Install l10n_mx 2. Go to Accounting > Reporting > Trial balance. 3. Click the COA SAT(XML) export button. 4. Warnings are raised. Problem: the report should work out-of-the-box on new databases. Cause: 1. Some tags are missing on auto-generated accounts. 2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit. This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts. opw-3283746 Enterprise: https://github.com/odoo/enterprise/pull/57531 Forward-Port-Of: odoo/odoo#155677 Forward-Port-Of: odoo/odoo#119485
This update clarifies how the `force_price_include=False` context key affects tax calculations within the Odoo accounting module. Previously, it was interpreted inconsistently, leading to potential errors in price calculations. This change ensures accurate tax handling, resolving a client issue related to price unit calculations.
Original PR description
Before this commit, using context key `force_price_include=False` had different interpretations in different methods In `compute_all` its semantic was forcing the "price_include" of taxes to be False In `_compute_amount` it was ignored (as only value "True" was overriding anything) To add to this incoherence, compute_all does use `force_price_include=False` when calling `_compute_amount`. This commits brings semantical coherence to the `account_tax` methods by keeping both interpretations of the context key the same: an override of price_include, whether its value True or False. This fixes a ticket in which the client uses that override to inverse the computation of `price_unit` from a tax-excluded counterpart. owp-3770871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155769
A warning was appearing during internal transfers when tracked products had existing serial numbers. This update prevents the warning from triggering, ensuring smoother internal transfers and avoiding potential disruptions to inventory management. The fix addresses a technical issue related to serial number verification.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by “SN”
- Update the qty to 1 in “WH/stock” with “SN1”
- Create an internal transfer:
- Location: wh/Stock
- Dest location: wh2/stock
- Mark as todo
- Try to select SN1 in the `stock.move`
Problem:
A warning is triggered:
`Existing Serial numbers. Please correct the serial numbers encoded: (001) exists in location WH/Stock`
We do a search to find all the quants in every location to verify if the same serial number is not being used, but we do not exclude the source location.
opw-3734300
Forward-Port-Of: odoo/odoo#155651
Forward-Port-Of: odoo/odoo#154626This update fixes a potential issue where channel subscriptions weren't reliably updating, leading to test failures. The change simplifies the subscription process using 'onAdd/onDelete' events, ensuring accurate channel tracking. This improves the overall stability and performance of the messaging system.
Original PR description
Before this PR, the `bus subscription is refreshed when channel is left` test was sometimes failing. This actually reveals a real issue: if a channel is joined a leave very quickly, the bus subscription is not updated. This occurs because we rely on the last subscription made and the one that should be made to detect if channels differ. Since the `updateBusSubscription` method is debounced, we can miss information. This PR replaces the complicated `updateBusSubscription` method by a `onAdd/onDelete`. This is much more reliable and more efficient since there is no need to walk through every channel to detect changes. This PR also remove a test that was redundant that the failing one. fixes runbot-55292,57645,56232 Forward-Port-Of: odoo/odoo#155720
This update resolves an issue where clicking on a color code in the colorpicker would reset the text field instead of updating the color. The fix ensures that color selections from the colorpicker now correctly update the note's color, improving usability.
Original PR description
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create…
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create a note , type anything and apply custom color - When clicking on the hex color code , the cursor is alwyas set back to the text. Origin of the issue: ==================== The behavior was introduced by https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3 In the click listener, we always reset the comuted selection wich reselects the original text. When clicking on empty space on the dropdown menu, it happens too but it doesn't matter since the menu closes anyway, but clicking on text input fields that you want to update will be a problem since the menu doesn't close but the text get reselected. Solution: ========= To overcome the problem of resetting when clicking on the dropdown, we first check if the click is on the colorpicker or not, if Yes do nothing and skip this. task-3648629 Forward-Port-Of: odoo/odoo#149480
This update fixes an issue where the live chat element was sometimes hidden behind other content on certain websites. The change ensures the live chat consistently appears on top, improving the user experience and preventing interruptions. This was achieved by setting a high z-index value.
Original PR description
The live chat should always be on top of other elements: some sites that embeds it use z-index for various purpose. Currently, the live chat does not uses z-index, thus is it can be hidden by other elements. This PR sets the z-index to the largest value of a signed integer on a 32 bit system which is the theorical maximum value for this property. opw-3732033 e.g. on squarespace (before)  (after)  Forward-Port-Of: odoo/odoo#155903
This update clarifies the analytic widget by replacing a confusing floppy disk button with a 'New model' link. This change simplifies the process of creating analytic distribution templates, reducing user confusion and improving the overall user experience. The update also automatically populates relevant fields for easier setup.
Original PR description
On the analytic widget, when putting an Analytic Account, a floppy disk appear on top of the wizard. This button is used to create a new analytic distribution template. It is confusing for users that thinks that the purpose of the button is to save the analytic distribution. This PR will replace the button to be a link called "New model". Also, this pr will fill some field (partner_id, account_prefix and product_id) if there are populated. task: 3736786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155611 Forward-Port-Of: odoo/odoo#153588
This update fixes an issue where the Kanban view incorrectly displayed overdue statuses for activities, even when no overdue activities existed. The fix ensures the Kanban column header accurately reflects the status of activities, improving the user experience and data consistency. This resolves a visual inconsistency impacting lead management.
Original PR description
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state)…
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state) - On a lead of that column, add an activity of the type chosen above with a deadline in the past - When going back to the kanban view, that column has the overdue status (red) - Mark that activity as done - Reload the kanban view The kanban column has still the status overdue (red) while there are no more overdue activity in that state. With this fix, after reloading the kanban view, the header displays the correct status summary. In the example above, the kanban column header is green. Technical note: archived activities were returned when grouping by activity_state because that part was done in SQL and not taking into account the recently added active field. While adding it in the "_read_group_groupby" method, we also add it in "_search_activity_state" to avoid the same problem when searching on activity_state. Note that we don't add flush in those methods using raw SQL so flush is needed in the added test. Task-3732333 Forward-Port-Of: odoo/odoo#153274
This update simplifies the process for international partners by removing unnecessary state validation within the l10n_in_edi module. Now, state requirements are only enforced for e-invoicing specifically for partners in India. This streamlines operations and reduces complexity for our overseas clients.
Original PR description
This commits removes the state validation for `l10n_in_edi` for overseas partner and now state will be only required for e-invoicing for partner having country `India` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154118
This update resolves an issue where SelectionFields within draggable kanban views couldn't be edited. The fix prevents a technical restriction that blocked the opening of the SelectionField's edit options. This ensures users can now correctly modify SelectionFields within the kanban interface, improving usability.
Original PR description
Before this commit, if a SelectionField was used in a kanban view alongside the HandleField (enabling re-sequencing, i.e. drag&drop), the "select" element couldn't be edited. This is because the d&d feature calls preventDefault on almost all "pointerdown" events occuring in the card, and the "pointerdown" event is the one that opens the select. There's no usecase in 17.0, but there's one in master, in the product document kanban view. We fix this in 17.0 which is the version that introduced the kanban version of the SelectionField. 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#155827
The iOS app check-in feature was broken due to issues with location access. This update resolves the problem by skipping the location request process specifically for iOS users, ensuring the check-in functionality works correctly. This improves the user experience for iOS users.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use iOS app; 2. click on red dot on top; 3. click check in. Issue ----- Nothing happens. Cause ----- The iOS app cannot request the user's location. Commit 1acd0b6c5d7ce292f670882f6ff48a2ff9db05f0 attempted to fix this by first checking whether `navigator.geolocation` exists, but the cause is likely with its `getCurrentPosition` method instead of its existence. Solution -------- Instead of checking for `navigator.geolocation`, use `isIosApp` to skip the geolocation part when using the iOS app. opw-3734385 Forward-Port-Of: odoo/odoo#155588
This update simplifies the process of generating UBL invoices by removing a redundant check for the 'Bronnoysund' field. Previously, a constraint ensured this field was populated, but now that 'peppol_endpoint' and 'peppol_eas' fields are used, this check is no longer needed. This streamlines the system and improves efficiency.
Original PR description
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node. Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field. Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled. [1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119 opw-3763725 Forward-Port-Of: odoo/odoo#155604
This update resolves an issue where the Contact widget on Odoo.com would crash when a partner's display name was blank. Approximately 3,000 partners had a null display name, causing this error. This fix ensures the widget functions correctly even with missing display name data.
Original PR description
In case where display_name is null, the widget contact crash - AttributeError: 'bool' object has no attribute 'split' On odoo.com we have around 3K of partners that have name with null value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155735
This update fixes an issue where employees with flexible hours and removed calendars displayed 0 remaining holiday leave on their dashboards. The change prioritizes the employee's contract calendar to ensure accurate leave balances are shown, improving the employee experience and reporting accuracy.
Original PR description
Steps to reproduce the issue: - have an employee with an allocation with an end date - remove the employee's calendar - go on his dashboard - his remaining leaves amount is 0 This commit implements a new method on the resource mixin to fetch a calendar for the record even though it might not have one. The default behaviour is to fall back on the company's calendar to ensure a value. This is overrided in the `hr_contract` module so that the calendar of the contract is prioritized. task-3609738 Forward-Port-Of: odoo/odoo#155753 Forward-Port-Of: odoo/odoo#144418
This update fixes a visual issue where the 'Apply' button in the daterange picker appeared flattened and misaligned. The change centers the button vertically and adds a 'close' button, mirroring the behavior of pressing ESC or clicking outside the picker, for a more polished user experience.
Original PR description
Current behaviour - when we access the daterange picker, it was observed that the `apply` button appeared flatter and was not vertically centered. Expected behaviour - add h-100 on buttons container to ensure they are vertically centered and no longer appear flatter - add cancel button in which action is similar to pressing ESC or clicking outside the popover Task-3624556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148812
This update streamlines how the Odoo website identifies event booths. Previously, the system repeatedly checked for booth existence, which was inefficient. Now, the website automatically discovers booths through crawling, ensuring accurate event listings without unnecessary manual checks.
Original PR description
If booth exists for this event, bot will discover it via crawling. Don't need to ask to crawler to check for each event if a booth exists. 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#156022
This update fixes a layout issue in the Point of Sale interface that occurred after printing receipts. Previously, the receipt's placement caused scrolling, but this change uses a 'fixed' positioning to prevent overflow and maintain a clean, non-scrollable POS experience for users.
Original PR description
Before this commit, the POS receipt was added to the bottom of the page after printing. In some browsers, this caused overflow and made the POS interface scrollable. With this commit, we fix this issue by changing the position of the receipt container to 'fixed'. This prevents the receipt from affecting the layout of the page after printing, thus avoiding the overflow issue and keeping the POS interface non-scrollable. opw-3775808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156025
This update resolves an issue where selling consumable products through Point of Sale (POS) automatically generated an unnecessary expense entry in the accounting system. The fix ensures that consumable products are no longer tracked for Cost of Goods Sold (COGS), streamlining the accounting process and improving accuracy. This change was made to address a reported bug and improve the overall POS experience.
Original PR description
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156 Forward-Port-Of: odoo/odoo#153657
This update resolves a problem where adding new tabs within a 'Tabs' block in website pages would create a disorganized and confusing layout. The fix restricts tab selectors to only the parent tab, ensuring a cleaner and more predictable clone experience. This improves the overall usability of our website templates.
Original PR description
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone.…
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone. Commit [2] introduced a new MultipleItems abstract option, and with it, added a selector which could cause the same issue as above. This commit fixes this by properly restricting the selectors to the direct children. Steps to reproduce: - Create a new web page - Add a "Tabs" block - Put some text in each tab in other to identify which text belongs to which tab - In the first tab, add a new "Tabs" block, so that you will have tabs and sub-tabs - Put some text in sub tabs in order to identify which text belongs to which sub tab - try to add a new tab in your main tab block => look at the beautiful mess it creates. [1]: https://github.com/odoo/odoo/commit/7572cc150d5469af92138533a024cffbd57d878e [2]: https://github.com/odoo/odoo/commit/ebfa28638b47a7be45b96d561bdf144c3487f366 opw-3730155 Forward-Port-Of: odoo/odoo#154695
This update fixes a technical issue related to how tax closing accounts are configured for Odoo's international localizations (l10n_xx). Previously, the port from version 16.2 didn't correctly implement the new requirement to define these accounts on the tax group level. This ensures accurate tax reporting across various countries.
Original PR description
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts for localizations that were so far missing them. However, the mechanism for specifying the default tax closing accounts changed in 16.2: they must now be specified on the tax groups. This was not correctly done in the fw-port, so we fix this in this commit. taskid: 3524378 Forward-Port-Of: odoo/odoo#155911 Forward-Port-Of: odoo/odoo#155074
This update ensures our cyclic inventory tests accurately reflect how Odoo handles annual inventory days, specifically considering leap years. Previously, the tests didn't account for the safeguards that automatically select the latest possible month day. This fix improves the reliability of our inventory testing process.
Original PR description
When a company's annual inventory day is selected which is higher than the number of days in that month, there are already safeguards in the feature to ensure the latest day possible for that month is selected. Unfortunately the related test forgot to take this into account for leap years, so this commit modifies it to test for this expected safeguard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155841
This update addresses a minor issue in the automated testing of Odoo's email functionality. A temporary problem with how test steps were being handled was causing intermittent failures. The team has applied a standard fix to ensure the tests run reliably, though the original issue wasn't consistently reproducible.
Original PR description
Not a guaranteed fix (not reproducible 1500 attempts), but applying standard fix for `step` failing to use the new step helper. runbot-54560 Forward-Port-Of: odoo/odoo#155925
This update fixes an issue where the default selected value for form selection fields was not being saved after page updates. The change restores this functionality, ensuring users consistently see their preferred selections when editing website forms. This improves the user experience and data consistency.
Original PR description
Since the PR [1] changed the rendering engine of qweb, the default "selected" value set on selects field on the form snippet were lost once the page is saved. This commit builds upon the changes made in [this commit] by reinstating the default "selected" value. Steps to replicate: - Go to Website -> Edit. - Drop a Form snippet onto the page. - Click on the 'Company' field. - In Field > Type, opt for "Selection". - Choose option 3 from the options list to establish it as the default. - Save the modifications. Issue: The expected default value for the selection field is not retained after saving. [1]: https://github.com/odoo/odoo/pull/130467 [this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b task-3767819 Forward-Port-Of: odoo/odoo#155838
This update fixes a problem where the Mexican localization module prevented users from creating new accounts in the chart of accounts. The issue stemmed from a mismatch in how Odoo handles method calls through RPC, specifically regarding the required arguments for the 'create' method. This fix ensures proper account creation functionality is restored.
Original PR description
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new…
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new account in the chart of accounts You should be met with a traceback: `TypeError: AccountAccount.create() missing 1 required positional argument: 'vals_list'` ### Cause The `@api.model` and `@api.model_create_multi` decorators in indicate that a method is intended to operate at the model level rather than on specific record instances. Without these decorators, the system defaults to treating methods as if they are meant to be executed on the record level. This distinction significantly impacts how methods are invoked through RPC. In RPC scenarios, Odoo's default expectation for record-level methods is that the RPC call will include the IDs of the records to which the method applies, alongside any actual method arguments necessary for the operation. Here, `create()` is called through RPC, as a model-level method (i.e, without record IDs). This makes sense because `create()` is always a model-level method. However, in our case, create is a record-level method, so the system expects the RPC call to contain record IDs. This mismatch produces a traceback. Issue introduced by 858bf9efdd9fcc29a73336863a51227c15cc19f0 opw-3772520 opw-3772469 opw-3772287 opw-3771854 opw-3771361 Forward-Port-Of: odoo/odoo#155848
This update corrects a bug where restricted users weren't consistently displaying branding on website pages due to a caching issue. The fix ensures that branding is correctly applied to all user types, regardless of their access level, improving the user experience. This resolves a discrepancy in how cached QWeb templates handled branding.
Original PR description
When QWeb templates became cached and compiled in [1], the list of default cache key elements did not contain `inherit_branding_auto` (but it included the old `inherit_branding`). Because of this the cache was shared between restricted editors and public users, which could lead to problems such as missing the branding on edited fields. Steps to reproduce: - Use a single browser instance and do not log any user out. - Start with `website_sale`. - Make "demo" user a restricted editor and a sales administrator. - Connect on 127.0.0.1 as "demo" and go to a product website page. - Go to 127.0.0.2 as a visitor and go to the same product page. => The product name field of the visitor page was branded. If you swap the last two steps, the "demo" user's page lacks the branding. [1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284 task-3482439 Forward-Port-Of: odoo/odoo#155264
This change reverts a recent update that restricted how taxes were managed in transactions, which was causing users to duplicate and modify taxes unnecessarily. By removing these restrictions, users can now easily adjust tax settings, and logging has been optimized to reduce unnecessary notifications.
Original PR description
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that…
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that would like to modify a tax would have to duplicate it, update the duplicated version and modify the tax usage where necessary. For such reason, this process is being reverted (we keep the tracking of the modification). The tracking of repartition lines now also includes the sequence of the lines since it is not restricted anymore. Furthermore, `_message_log_repartition_lines` has been updated to log messages when new repartition lines are added or repartition lines are removed. It also has been update to track changes of lines by comparing their position in the tax (rel. sequence) and not their IDs. Doing so allows to remove unnecessary logging when, for example, users remove a repartition line and immediately add a new one similar to the one deleted. It also allows to not log reordering event of two similar lines. original-commit: 8d77045b46a1b4a9d7fffd1111e53749d51d81e2 task-3450002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155055
This update fixes issues with how product categories are displayed in the Point of Sale system. Previously, long category names caused overlapping and incorrect ordering, especially when categories had multiple parent levels. This change ensures a cleaner and more organized category display for users.
Original PR description
Before this commit, there were issues with the display and ordering of categories. Long category names would overflow their containers and overlap with other categories. Additionally, the order of parent categories was incorrect when a selected category had many parents. This was due to the `getAllChildren` function not returning all children correctly, which in turn affected the display of the parent sequence. opw-3776740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a recurring issue where tour scheduling tests were failing intermittently due to timing differences in the Odoo system. The fix adds a verification step to ensure the activity type input is fully loaded before proceeding, improving test reliability and preventing scheduling errors. This ensures tours are scheduled correctly.
Original PR description
Since PR #154105, `mail_activity_schedule_from_chatter` test was failing on some runbot builds. The problem is, the `timeout` to make sure the activity type input is ready (has its data) to click again, is not enough for all builds. Instead of using timeout (which is not same for different builds), we can add an extra step to check if the activity id input has its data after clicking on dropdown, to proceed to the next steps. fixes runbot-57738 Forward-Port-Of: odoo/odoo#156030
This update fixes a minor typo in the Belgian accounting module. The incorrect reference to the Office National de Sécurité Sociale (ONNS) has been corrected to the correct ONSS designation. This ensures accurate reporting for Belgian businesses using the Odoo accounting system.
Original PR description
Office National de Sécurité Sociale (ONNS) should be (ONSS). Forward-Port-Of: odoo/odoo#155828
A bug was causing an error when adding timesheet entries for certain users. This update corrects a technical issue related to how the employee selection field in the Timesheets module handles user permissions, ensuring correct functionality for all employees. This fix improves the user experience for all users.
Original PR description
Steps to reproduce ================== - Install Timesheets - Login as Admin - Edit the access rights of Mark Demo: * Timesheets: "User: all timesheets" * Employees: "None" - Logout and login as Demo…
Steps to reproduce ================== - Install Timesheets - Login as Admin - Edit the access rights of Mark Demo: * Timesheets: "User: all timesheets" * Employees: "None" - Logout and login as Demo - Go to a project task - Switch to the Timesheets notebook - Add a new line - Click on the employee field > Search More => An error occurred Cause of the issue ================== The hr.employee.public model is an SQL view of the hr.employee table with differents permissions. Since the user doesn't have the hr.group_hr_user group, the model hr.employee.public should be used and not hr.employee. Since [0], the model is switched depending on whether the user has the appropriate group. The EmployeeFieldRelationMixin is used and defines a getter for the relation. That relation was not propagated to the Many2OneField. Solution ======== Pass the relation to the many2OneProps. --- [0]: https://github.com/odoo/odoo/pull/136786 opw-3765393 Forward-Port-Of: odoo/odoo#155743
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar…
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar to l10n_us_payment_nacha, which implements a similar file format for the US.
CPA005 files consist of logical records with a fixed length [1]. A logical record corresponds to a line in the file and has a type, denoted by a letter. For our purposes we only support 3 types: header ("A"), deposit data ("C") and footer ("Z").
The header record contains metadata about the batch payment, which includes the currency. CPA005 allows one file to have either CAD or USD payments, but not both. Of interest here is the the File Creation Number (FCN). This is the 4 digit identifier of the file. We made defining this field as flexible as possible because different banks have different requirements. We know of at least the following requirements made by different banks:
- FCN must be different from the previous 9 FCNs submitted [4],
- FCN must be TEST for test files [4],
- Subsequent FCNs should increment by 1 [5][6],
Because of these differences the FCN is overridable on the batch payment (for e.g. specifying TEST). When not overridden, numbers are generated based on a sequence linked to the journal so the step can be adjusted to match what the bank requests.
To adhere to industry standards we deviate from the official specification in two ways. First of all, we don't encode the files in EBCDIC [2], instead we use the standard UTF-8 encoding. Secondly, we only add one payment per "C" record. The format allows for up to 6 payments in the same "C" record [3], but this seems uncommon nowadays.
From our experience with NACHA we know that banks don't always provide good errors to customers. To minimize trial and error we provide as much help as we can to users with tooltips and validations.
Contrary to NACHA, no good validators exist. This implementation has been tested in two ways. The output was compared to the output of known good software, and generated files were tested in production with a real bank (CIBC).
[1] https://www.payments.ca/sites/default/files/standard005eng.pdf
[2] p6 in [1]
[3] p13 in [1]
[4] p6 in https://www.rbcroyalbank.com/ach/file-451770.pdf
[5] https://help.treasurysoftware.com/hc/en-us/articles/360046359093-TD-Toronto-Dominion-80-byte-and-1464-byte-EFT-file-formats
[6] p129 in https://www.atb.com/siteassets/pdf/resources/support/atb-business/atb-business-eft-user-guide-0422.pdf
task-3639094Enhancements to existing features
Recurring shift planning now skips dates when employees or the company are unavailable, such as holidays, leave days, weekends, conflicts, or contract end dates. This helps avoid scheduling people when they should not be working and makes repeated shift generation more reliable.
Original PR description
…rrency This commit introduces unavailabilities when planning recurrent shifts in the planning app. Unavailabilities include company closing days, public holidays, employee leaves, shifts in conflicts, fixed contract endings, etc. Prior to this change, when recurrent shifts were planned and generated, no unavailability information was taken into account. For example, if we planned a shift to repeat every month on the 15th, and it landed on a weekend (a company closing day), it would be normally generated. After this commit, it would not be, as no resource is supposed to be working at that time. task-2918840
Salary offers can now be refused directly from the salary configurator, with feedback sent to HR. HR managers can record a structured refusal reason in the backend, making follow-up easier and enabling future reporting on why offers are declined.
Original PR description
An offer is often refused. Currently, they need to be tracked somewhere else, and managed manually. It should be made easier, so that the user can give feedback about the offer to the hr manager. The HR manager can then refuse the offer on the backend and select a refusal reason. Having defined refuse reasons will allow to make dashboards. task-3619658
The appraisal smart button is now easier to understand and better positioned when an appraisal is in progress. It is also visible through the full management hierarchy, helping managers quickly access relevant current appraisals while demo data is cleaned up for a clearer experience.
Original PR description
Improve the appraisal request visibility by adjusting the smart-button text to "Current Appraisal" and adjust its position when an appraisal is ongoing. Also remove appraisal for Mitchel Admin from demo data. Also ensure the button appears recursively for all the managers in the hierarchical structure. Task-3499125
The spreadsheet engine used in Odoo has been updated to a newer alpha version, bringing improvements to spreadsheet-related features. This affects areas such as document spreadsheets, charts, and global filters, helping keep reporting and analysis tools current and more reliable.
Original PR description
…-alpha.6
Resolved issues and error corrections
The Sendcloud product selection screen has been fixed after a recent change caused it to stop working correctly. This helps users choose the right delivery product again when preparing Sendcloud shipments, reducing disruption in shipping workflows.
Original PR description
The product selection widget view has been broken by recent changes. This update aims to rectify that and bring it back to goodness.
This fix restores correct budget-related totals when users group budget data in the interface. It ensures fields such as theoretical amounts remain available for grouped reporting, preventing missing or incorrect business figures in budget analysis.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, we do a dryrun to see if a field is aggregable (_descrition_aggregator()). We use `_read_group_select` to do so, and it doesn't work the field doesn't have an aggregator for the webclient, and then it is not ask when we groupby. Because of this every direct override of _read_group for these fields won't be use by the webclient anymore. Fix them by overriding `_read_group_select` (and `_read_group_postprocess_aggregate` for some cases). https://github.com/odoo/odoo/pull/155585
This fixes a small issue that caused unnecessary warning messages in server logs when field service worksheet templates were looked up. The change helps keep logs cleaner and avoids misleading operational noise without changing user-facing behavior.
Original PR description
Before this commit, a warning is logged in the server logs because `=` operator is used with an array as right leaf in a domain used in a search in `_compute_worksheet_template_id` defined in `project.project` model. The operator used should be `in` instead of `=`, that's why we got that warning. This commit fixes the issue by changing the operator used inside that domain to use `in` instead of `=`. runbot-58374 X-original-commit: 2b12d5e8
Code cleanup and technical improvements
This update changes how automated guided tour tests identify page elements, moving from an older method to a newer internal testing approach. It helps keep quality checks reliable across many business apps without changing the day-to-day user experience.
Original PR description
Before this commit, triggers (extra_triggers, alt_triggers and skip_triggers) defined in steps of tours were found in the DOM with $() jQuery function. In this commit, these steps are now found with Hoot queryAll() function. Triggers of steps have so been adapted to satisfy this adaptation. task~3600484 https://github.com/odoo/odoo/pull/155605
Miscellaneous changes
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that referenc
Original PR description
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that references the `planning.slot` model to set the field to NULL or trigger the SQL `ON DELETE` constrains. ## Fix Add the missing indexes. Partial on nulls because it's a sparse relationship. ## Reference task-3747131 Forward-Port-Of: odoo/enterprise#56681
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added whe
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the cod
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the i
Original PR description
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the issue:** The filter's domain includes these aforementioned un-managed employees. **Fix:** Remove that part of the domain. This commit is a partial revision to one of the changes made by https://github.com/odoo/enterprise/commit/60dc8c38519b75b5383a54e923135d557e3737e0 (see log chatter on Odoo for associated ticket for justification) opw-3708825 Forward-Port-Of: odoo/enterprise#57049
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
Original PR description
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file,
Original PR description
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file, they get marked as "obsolete". This happens during the merge function that is called within tools/translate.py. In order to avoid this, the pot and po files have been re-generated and restructured in order to make future additions easier to merge. Forward-Port-Of: odoo/enterprise#57718 Forward-Port-Of: odoo/enterprise#56590
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if ne
Original PR description
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if necessary when generating the query with a domain using the `IN` operator (relation). opw-3759882 Forward-Port-Of: odoo/enterprise#57798 Forward-Port-Of: odoo/enterprise#57502
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Original PR description
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
Original PR description
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
Original PR description
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id
Original PR description
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57657 Forward-Port-Of: odoo/enterprise#55010
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
Original PR description
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, res
Original PR description
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, resolving the rendering issue. This modification ensures that the TimesheetValidationPivotController now extends PivotRenderer, allowing it to access the necessary methods and resolve the rendering issue for the validate button. **Task**-3623493 Forward-Port-Of: odoo/enterprise#57656 Forward-Port-Of: odoo/enterprise#53165
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix.
Original PR description
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3:…
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix. Validate 0: 1 and 2 receives an activity Validate 1: activity of 1 is removed validate 2: activity of 2 is removed, 3 receives an activity (<=====) Before this commit, 3 did not receive an activity. This was because, in this flow the rule 3 is evaluated for validation because every rule before it had been validated. However, in that part of the code, we ensure that no rule below it in notification order is not validated, but we do it in the context of the current user. So, when validating rule 3, we couldn't see the validations for at least of previous rule that another part of the code had seen before. After this commit, the rule 3 receives an activity, and the whole flow works as expected. opw-3752133 Forward-Port-Of: odoo/enterprise#57644 Forward-Port-Of: odoo/enterprise#57604
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns th
Original PR description
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns the appropriate recordset. related commit: 05a1080a66cefc1b0724e23c72dd2bf06343e4e3 Task-3765016 Forward-Port-Of: odoo/enterprise#57374
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR
Original PR description
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR is merged:** We search first for the users that are matching the search key in 'res.users' using 'sudo()' then get their ids and search in 'helpdesk.ticket' using those ids opw-3719387 Forward-Port-Of: odoo/enterprise#56716
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
Original PR description
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
Original PR description
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Original PR description
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - Cit
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Original PR description
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
Original PR description
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months.
Original PR description
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months. To have a more flexible system, we will now compute the start date by taking into account the set frequency. The end date of the statement will always be the day before the sending date, while the start date will be the end date minus the frequency (so minus two weeks if set to bi-weekly). Task id # 3713352 Forward-Port-Of: odoo/enterprise#56893
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forwar
Original PR description
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forward-Port-Of: odoo/enterprise#56817 Forward-Port-Of: odoo/enterprise#55218
This update adds Bank Negara Malaysia as a live exchange rate service option for Malaysian users. This enables businesses in Malaysia to automatically fetch current exchange rates directly from the country's central bank, which is the standard practice for accurate and reliable currency conversions in the region.
Original PR description
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
A new payment method integration for Razorpay has been added to Odoo's Point of Sale system. This allows businesses using Razorpay as their payment processor to accept payments directly through their POS terminals, expanding payment options for retail operations.
Original PR description
This commit adds the module pos_razorpay to add a new payment method of razorpay to point_of_sale. Task: 3691186
Enhancements to existing features
This update improves the performance of deleting planning shifts in the system. When deleting shifts, especially recurring ones, the system was performing slow database scans. We've added database indexes to speed up these deletions, which is particularly beneficial for companies with large timesheet and work entry records.
Original PR description
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that references the `planning.slot` model to set the field to NULL or trigger the SQL `ON DELETE` constrains. ## Fix Add the missing indexes. Partial on nulls because it's a sparse relationship. ## Reference task-3747131
This update removes restrictions that previously prevented users from modifying taxes that were already used in transactions. Instead of having to duplicate a tax to make changes, users can now edit taxes directly. The system maintains a detailed audit trail of all modifications, and the change tracking has been improved to focus on the position of tax components rather than their IDs, reducing unnecessary notifications.
Original PR description
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that…
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that would like to modify a tax would have to duplicate it, update the duplicated version and modify the tax usage where necessary. For such reason, this process is being reverted (we keep the tracking of the modification). The tracking of repartition lines now also includes the sequence of the lines since it is not restricted anymore. Furthermore, `_message_log_repartition_lines` has been updated to log messages when new repartition lines are added or repartition lines are removed. It also has been update to track changes of lines by comparing their position in the tax (rel. sequence) and not their IDs. Doing so allows to remove unnecessary logging when, for example, users remove a repartition line and immediately add a new one similar to the one deleted. It also allows to not log reordering event of two similar lines. original-commit: 8d77045b46a1b4a9d7fffd1111e53749d51d81e2 task-3450002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix resolves an issue where job applicants were unable to upload documents in the recruitment module. The problem was caused by an incorrect model configuration that prevented uploaded documents from being properly stored and displayed. With this fix, applicants can now successfully upload and manage their documents.
Original PR description
**Description of the issue/feature this PR addresses:** In the kanban view of all applicants within the recruitment module, an issue arises when applicants attempt to upload documents, this functionality is currently malfunctioning. --- **Current behavior before PR:** Document uploads by applicants are failing. --- **Desired behavior after PR is merged:** Applicants should be able to successfully upload documents. ___ **Fix:** The PR addresses the problem by modifying the default_res_model in the context. This adjustment is crucial as the current setting results in an incorrect model name, preventing the display of uploaded documents in this model. task-3579833 Forward-Port-Of: odoo/enterprise#57717 Forward-Port-Of: odoo/enterprise#52029
A recent update to journal options in account reports inadvertently caused journal groups to be incorrectly selected as individual journals. This fix ensures that only actual journals are selected, not journal groups, restoring the correct behavior for financial reporting.
Original PR description
In #25518, the journal options were reworked to better use journal groups and multi-company reports. However, this caused a regression where _get_options_journals would select journal groups as journals This change uses the 'model' key in the journal options to only select the 'account.journal' ids --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#56730
This fix removes an incorrectly added country_code field from the Mexico EDI module that was accidentally included during a merge conflict resolution. The field should not have been present and its removal ensures the module functions as intended without unnecessary data duplication.
Original PR description
Erroneously added (https://github.com/odoo/enterprise/commit/0695afece962ad1c5d3dafc930b00c0e16d30b25) coutry_code field when reselving merge conflict. Forward-Port-Of: odoo/enterprise#57774
This fix resolves an issue where purchase orders and delivery quantities were being doubled when adding storable products to subscription upsells. The problem occurred because stock rules were being triggered twice—once from the parent subscription and once from the upsell. The fix ensures stock rules are only triggered from the upsell, preventing duplicate orders and quantities.
Original PR description
Steps to reproduce: - Create a storable product invoice on delivered qty MTO enabled - Create a subscription for a service product and invoice it - Create an upsell and add on it the storable product Bug: PO line and delivery quantities are doubled Fix: only trigger stock rules on the upsell not from the parent SO opw-3696134 Forward-Port-Of: odoo/enterprise#57590
This fix corrects a critical issue where UPS return labels were being generated with reversed addresses—showing the customer as the receiver and seller as the sender, when it should be the opposite. Return labels are used to ship items back from customers to sellers, so the addresses must be correct for the return process to work properly.
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
This update makes the Task Gantt View component available for developers to reuse and customize more easily. Previously, developers had to access the component through a technical registry, but now it can be imported directly. This improves the development experience and makes it simpler to create custom Gantt-based views for project management.
Original PR description
Before this commit, the taskGanttView object was not exported and so if someone would like to override that object, he will have to get that object in the views registry. This commit allows to export taskGanttView from that file to easily use it to create another Gantt JS based on that one instead of getting the object from the registry. task-3776786
This fix improves how non-UK companies using UK tax positions submit VAT reports to HMRC. The system now automatically handles foreign VAT numbers correctly and removes the need for users to manually strip the 'GB' or 'XI' prefix from VAT numbers before submission, making the process simpler and less error-prone.
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
This update synchronizes the intrastat code lists with 2024 regulatory standards by adding new codes and removing outdated ones. The changes include setting effective dates for new codes and expiry dates for removed codes to ensure accurate international trade reporting and compliance with current regulations.
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This update fixes a technical issue where video calls could experience problems if a channel was removed while the call was still loading. The fix prevents these timing conflicts, ensuring calls remain stable and don't encounter unexpected errors when channels are closed during the loading process.
Original PR description
Before this commit, there could be race conditions in which a channel could be removed while the call was still loading, this commit prevents this issue. task-3660964
This fix prevents the Point of Sale system from incorrectly creating expense entries when selling consumable products. Previously, when a consumable product was sold in a POS session without an invoice and the session was closed, an unwanted expense entry would be added to the accounting records. This fix ensures consumable products are properly excluded from cost of goods sold (COGS) calculations.
Original PR description
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156
This update fixes an issue where product attributes with multiple selection options were not appearing in the product configurator popup when using Point of Sale on mobile devices. Customers can now properly select from all available product options when adding items to their order on mobile, improving the checkout experience.
Original PR description
Current behavior: When adding a product with a multi selection attribute, the attribute is not displayed in the product configurator popup. This only happens when opening it on a mobile device. Steps to reproduce: - Add a product with a multi selection attribute - Open PoS - Add the product to the order - The attribute is not shown on the product configurator popup opw-3711164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where dropdown menus (like user menu and language selection) were not visible when clicking on them in website headers with the "Fixed" scroll effect. The fix ensures dropdowns appear properly by adjusting how the header behaves during scrolling and automatically scrolling to the top when users interact with dropdowns.
Original PR description
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling…
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling the page until it completely disappears. To reduce the height of this element without leaving its contents fully visible (because they maintain their height), we added an "overflow: hidden" property on it. However, this "overflow: hidden" introduced a bug fixed by this commit. Due to this, the dropdowns within the "o_header_hide_on_scroll" element, like "user menu" dropdown or "language selection" dropdown, became invisible. Steps to reproduce the bug: - Go to Website edit mode. - Click on the header. - Choose the "Menu - Sales 2" template from the options. - Select the "Fixed" Scroll Effect from the options. - Click on the "User Menu" dropdown in the header. - Bug: The dropdown menu does not appear. The same issue occurs if you type something in the search bar; the dropdown with the results does not appear either. To fix this, we don't apply "overflow: hidden" on the "o_header_hide_on_scroll" element when the page hasn't been scrolled yet. And if the page has been scrolled just a bit and the user clicks on a dropdown or the search bar, we scroll the page to the top first, and then display the dropdown menu. This commit also add a test tour to prevent the bug from reappearing. [1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb opw-3698887
This fix resolves an issue where QR codes were not appearing on automatically printed receipts at the point of sale. The problem occurred because the QR code image was being fetched after the receipt was already sent to the printer. The fix ensures the QR code image loads completely before printing, so customers receive complete receipts with the QR code included.
Original PR description
Prior to this commit, enabling auto receipt printing resulted in the QR code not being printed on the receipt. This was due to the QR image being fetched post printing. This commit addresses the issue by first loading the QR code image, then sending it to the printer, ensuring its presence on the printed receipt. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr