Thursday, November 7, 2024
45 changes
6 changes
Resolved issues and error corrections
This fixes an issue in Odoo Studio exports where built-in system fields could be handled incorrectly. Exports should now use the proper field names, making exported data more reliable for users.
Original PR description
Use the name instead of the field instance.
Belgian payroll now shows the eco voucher action only for the relevant holiday termination payslip batches. When used, the wizard creates or updates the correct monthly payslip structure so eco vouchers are included accurately without disrupting payslip presentation.
Original PR description
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all…
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all payslips have the wrong structure : CP200HOLN. The eco voucher button should generate or regenerate a monthly payslip with the eco voucher inside. Objective ---------- - Display the button for the good structures. - Change the filtered employee in the eco-voucher wizard to match the structs - Use the good struct for payslips generated from eco-voucher wizard : CP200MONTHLY - Add new rule in the structure to display a line in the payslip if an eco-voucher is add as "other fields". (But hide it in the payslip) Solution ---------- - Condition on structure code changed from CP200HOLN and CP200HOLN1 for the visibility of the eco voucher button. - Employees filter changed for the eco-voucher action - Payslip structure changed for payslips generated from the eco-voucher wizard. - New record added in the CP200MONTHLY structure. Test ---------- Python test added to test if an eco-vouchers line is added to payslips in the batch when the user validate the payslip generation from the eco-vouchers wizard. 3 cases are covered : - generated payslips - existing payslips - edited existing payslips (edited with the edit payslip wizard in cogmenu) task-3598939
This fix improves the wording of an error shown when users scan a barcode that is not found during receipt operations. It makes the message clearer and more professional, reducing confusion for warehouse staff.
Original PR description
Barcode --> Operations --> Receipts --> NEW Scan a barcode that doesn't exist in the DB ie: "5449000000996" The current error message's spelling and grammar are off. opw-4307102
Installing the Payroll Accounting module on a new database will now also install the required Accounting app. This prevents setup gaps and ensures payroll accounting features work as expected from the start.
Original PR description
When installing hr_payroll_account on an empty DB, we expect the Accounting app to be installed. But that is not the case. hr_payroll_account should depend on the accountant app.
The commission plan form now uses the standard date range selector, making start and end date selection work better on mobile devices. This reduces friction for users managing commission plans from phones or tablets.
Original PR description
before this commit, commission plan form date field selector seems broken in mobiles devices because we did not directly used widget available. after this commit, use daterange widget.
The sale commission plan list view no longer shows the status field twice. This removes duplicate information from the screen, making the list cleaner and easier for users to read.
Original PR description
in this PR, fixed an issue where the status of the sale commission plan was being displayed twice. This fix ensures that the status information is shown only once.
30 changes
Resolved issues and error corrections
Timesheets linked to a sales order line now fall back to the project’s analytic account when the sales line does not include the required project account. This prevents errors when recording time on sales-created projects with other analytic plans configured.
Original PR description
9 changes
Resolved issues and error corrections
This update ensures Odoo supports the new Brazilian tax regulations requiring a barcode on each line item. This change is being implemented for Odoo 17 and later versions, focusing on EDI processing. It's based on Avalara documentation to ensure accurate tax calculations for Brazilian transactions.
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168Steps to reproduce: ------------------- 1. Install Timesheets and Sales app 2. Create an SO, add an SOL with a service product that creates a project/task (e.g. Junior Architect), confirm the SO 3.…
Steps to reproduce: ------------------- 1. Install Timesheets and Sales app 2. Create an SO, add an SOL with a service product that creates a project/task (e.g. Junior Architect), confirm the SO 3. Remove the analytic account of the 'Project' plan from the SOL's analytic distribution 4. Add an analytic account for another plan such as 'Departments' (Basically, the 'Project' plan shouldn't be set but the distribution shouldn't be empty either) 5. Add a timesheet and link it to the project of the SO and to the SOL that we've just created 6. Error because the SOL doesn't have an account for the 'Project' plan Fix: ------------------- Before this commit, when the timesheet was given an SOL, we were only relying on its distribution to give its analytic accounts to the timesheet at timesheet creation/update (see _timesheet_preprocess_get_accounts()). We now take into account the project's account_id if no account_id was found in the SOL's distribution (see _timesheet_postprocess()). task-4221106 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now ignores certificate subject parsing errors caused by special characters in newer cryptography libraries. This prevents affected customers, such as those with certain Mexico EDI configurations, from being blocked even though the certificates are otherwise valid.
Original PR description
In version 42.0.0+ of the `cryptography` library, which we now use, certain special characters in the subject/issuer fields of certificates may cause parsing errors. While the certificates are recognized correctly, attempting to access a subject or issuer attribute with special characters sometimes throws an exception due to parsing issues. ### Fix This issue appears to be specific to recent versions of `cryptography`, as the same certificate values can be successfully retrieved using `openssl`. Currently, we only access the `commonName` attribute from the subject field, which is not used in any critical way in our application. Given this, and due to the blocking nature of this issue for customers requiring specific EDI setups (e.g., in Mexico), we have opted to bypass such cases for now by ignoring these parsing errors. opw-4295754 opw-4293293
Duplicating a project from the kanban view no longer keeps the original project's stage. New copies now start in the expected default stage, helping teams avoid misplaced projects and workflow confusion.
Original PR description
Steps to reproduce: - Settings > Enable 'Project Stages' - Projects app > New Project > Drag it into 'In Progress' stage - From Project Kanban view duplicate that project The duplicated project is created directly in 'In Progress' stage when it should have defaulted to the lowest sequence stage 'To Do'. Other duplication actions notably do not have this same issue. The kanban action specifically fetches default_stage_id from the context instead of using the dedicated default function of the sage_id field, but more generally we never want to copy the stage (as indicated by copy=False) so this fix covers for other possible mistakes. opw-4291455 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an accounting test that was failing after a recent change in how journal entries are created. It helps keep payment discount behavior properly verified in the community edition, reducing the risk of regressions in accounting workflows.
Original PR description
The test_payments_epd_eligible_on_move_with_payment is no longer passing in community since this commit https://github.com/odoo/odoo/commit/0c2810df991b5ac48483f03d4cd0f5d281ece4b8. This is because a journal entry is now always generated in community edition, whether an outstanding account is provided or not. runbot issue: 105488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase order PDFs now show tax labels as clean text instead of displaying raw HTML tags. This makes printed purchase documents clearer and more professional for users, especially when using localized tax descriptions.
Original PR description
When printing the purchase order, the tax values were displayed with HTML tags because the field is an HTML field, and it was passed to the `join` function, which treated it as plain text. ```<span t-esc="', '.join(map(lambda x: x.description or x.name, line.taxes_id))"/>``` To fix this, the tax values are now converted to plain text before being passed to the `join` function. Steps to reproduce: 1. Create a purchase order PDF using taxes from a localization (e.g., Belgium). 2. Print the purchase order and observe the tax values displaying with HTML tags. opw-4260595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Embedded components in the HTML editor now share the same underlying lifecycle as the main page instead of running separately. This prevents unpredictable crashes when embedded content opens interface elements like popovers, making editing more stable for users.
Original PR description
Context: Every Embedded Component was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to…
Context: Every Embedded Component was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile its template. Issue: Now all pieces together in a problematic example case: Creating a new popover from a Embedded Component involves the `main_components` registry: - Create a OverlayItem (position logic (wrapper)). It is created within the main App through the registry, and its lifecycle is managed by the main App Scheduler. - Fill it with a Custom Component (business logic). It is created within the Embedded Component App, and its lifecycle is managed by the Embedded Component App Scheduler. Issue: Now all pieces together in a problematic example case: A component rendered within the Embedded Component App, and therefore handled by the scheduler of the Embedded Component app is added within a popover through the service, and that popover component is rendered within the main App, and therefore handled by the scheduler of the main App. Both schedulers lifecycle handling are not synchronized, and at some indeterministic point one of the Apps will crash during the manipulation of that popover. Solution: Use the new "subroots" OWL feature instead of using sub-apps, so that all templates are created from the same App, and the scheduler is the same for all components. This also has the advantage of not having to re-compile all templates for every Embedded Component. task-4300215
Manufacturing labour costs now remain on the appropriate work center expense accounts instead of being moved back during final product valuation. This gives businesses clearer and more accurate production cost reporting by preserving where labour expenses were actually incurred.
Original PR description
Since https://github.com/odoo/odoo/pull/169257, we've created separate valuation journal items for MO employee and workcenter costs with items on expense accounts that can be set on a per-workcenter…
Since https://github.com/odoo/odoo/pull/169257, we've created separate valuation journal items for MO employee and workcenter costs with items on expense accounts that can be set on a per-workcenter basis. However, in the final product account move, we move these amounts back to the Cost of Production account as to not have a net impact on the expense accounts after production. This PR leaves the labor costs on the WC expense accounts instead of putting them back on the COP account in the final product account move. **To reproduce:** - Enable automatic accounting with FIFO for all products - Create storable products F and C - Purchase 100 C with unit price 50 and receive the products - Create a BOM for F with component 1 C and 1 WO (60 min, assembly 1) - Create, confirm and produce MO for 1 F - Open accounting and view the newly created journal entries **Current behavior:** - On the entry for F, an expense item is created with a credit value equal to the labor cost. - On the labor entry, an expense item is created with a debit value equal to the labor cost, and a Cost of Production item with matching credit. **Expected behavior:** - The entry for the final product should have no expense entries for labor, only the COP credit and SV debit (final product value). - The entry for labor should have a credit value on the expense item, and a matching debit value on the Cost of Production item. task-4267713
Recruitment officers can now use the “Load Sample data” option without running into an access error. This helps teams set up or test recruitment workflows without needing administrator assistance.
Original PR description
Currently an error was generated when the user with access right `Officer: Manage all applicants` tries to load recruitment data by clicking `Load Sample data` from recruitment. error: `ParseError: while parsing /home/odoo/src/odoo/18.0/addons/hr_rec...` This is because when the user tries to load recruitment data, it tries to create a `Mail Tracking Value` that requires admin rights. This commit allows non-admin users to load the recruitment scenerio and make the `Load Sample data` button visible to the recruitment users. sentry-6042340046
Adds a dedicated accounting entry for Chilean businesses that factor receivable invoices. This supports better handling of invoice transfers to third parties, helping improve cash flow tracking and compliance with Chilean electronic tax requirements.
Original PR description
Description of the issue/feature this PR addresses: This adds a new account for factoring invoices (related to: https://github.com/odoo/enterprise/pull/70696) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects several documentation links that still sent users to version 17 pages. Users working with Point of Sale, Spanish localization, US accounting localization, and POS box setup will now be directed to the appropriate version 18.0 documentation.
Original PR description
* = point_of_sale, l10n_es, l10n_us_account, hw_posbox_homepage 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
Purchase order documents now display the tax name instead of the tax description. This prevents visible HTML tags from appearing in the Taxes column, making printed purchase orders clearer and more professional.
Original PR description
Version: 18.0+ Issue: Currently we are using the `description` of the tax to place on the report. This will cause the `<p>` tags to show on the report because `description` is a HTML field. Purpose of this PR: To only use the tax name to show on the purchase order document by changing to a list comprehension. Steps to reproduce on runbot: install purchase create an purchase order assign a tax print purchase order `<p>` tags will show under the Taxes column. Notes: In previous versions `invoice_label` was being used for this report. opw-4292687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The translation button for text and character fields is now positioned within its field instead of floating over nearby data. This improves readability and usability in forms with related records, especially when editing translated content.
Original PR description
In x2many form field, the translation feature appears at the end of the row and hovers some data. This commit: 1. Fixes the issue by ensuring that the element is positioned relatively to its container (cf. the translatable field). 2. Refactors the css related to the char_field and text_field translation buttons to avoid negative margins but also to simplify the css. task-4273364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an ecommerce issue where shop pages could fail to load when products used custom tax formulas based on product fields. Customers can now browse affected products normally, reducing disruption during online shopping.
Original PR description
Have a tax with Tax Computation set to 'Custom Formula', depending on a product.<product_field> (i.e. product.list_price)
Add that tax to a product shown in website shop
Access Ecommerce
Error
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
ValueError: Expected singleton: product.template(17, 18, 23, 8)
Template: website_sale.products_item
Path: /t/form/div[2]/div[2]/div[2]/span[1]
Node: <span class="h6 mb-0" t-if="template_price_vals[\'price_reduce\'] or not website.prevent_zero_price_sale" t-out="template_price_vals[\'price_reduce\']" t-options="{\'widget\': \'monetary\', \'display_currency\': website.currency_id}"/>
Compiled code:
code = None
template = 'website_sale.products_item'
```
This occurs because we call `compute_all` with multiple product templates
opw-4295796This update fixes and improves Hoot, Odoo’s internal browser-based testing framework, along with related unit tests across several apps. It makes test reporting clearer, reduces stale failed-test results, improves mocked browser behavior, and helps developers catch issues more reliably before they affect users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 26 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 26 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 Part 25: https://github.com/odoo/odoo/pull/183358 Enterprise: https://github.com/odoo/enterprise/pull/73361 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The invoice portal now handles invoices without a due date without crashing. This prevents customers from seeing an error when opening their invoice list and keeps portal access reliable even when payment due dates are left blank.
Original PR description
Currently, an error occurs when opening a portal view of invoices and any invoice has no 'Due Date' Step to produce: - Install the ```account``` module. - Create a new invoice, add a customer name…
Currently, an error occurs when opening a portal view of invoices and any invoice has no 'Due Date' Step to produce: - Install the ```account``` module. - Create a new invoice, add a customer name and an invoice line, then save the record. - After that, remove the 'Payment terms' and confirm the invoice. - Then Remove a 'Due Date' and save a record. - Go to portal view and try to open 'Your Invoices', ```TypeError: '<' not supported between instances of 'bool' and 'datetime.date'``` An error occurs when the system tries to compare an invoice's due date with today's date at [1], but the due date is missing. Link [1]: https://github.com/odoo/odoo/blob/1615bdb7e52e5ad501922568a1baaee4fd07a4b7/addons/account/views/account_portal_templates.xml#L72 To resolve this issue, add a condition to skip the comparison between the invoice's due date and today's date, if the due date of invoice is unavailable. Sentry-6016842018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where frozen and shared spreadsheets could lose formatting and styles on secondary sheets after applying a global filter. This ensures shared spreadsheet links preserve the intended presentation for viewers.
Original PR description
steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - add a global filter - leave the spreadsheet and open it again (to force a snapshot, until bug fix 4299935 is merged - set a value in the global filter - hit the "Freeze & share" button - open the sharing link in an incognito window => formats and style in the second sheet are missing Task: 4300401 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
Frozen and shared spreadsheets now preserve the formatting of Odoo pivot data, such as numbers or values. This prevents shared spreadsheet links from showing raw or incorrectly formatted data, improving readability for recipients.
Original PR description
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - leave the spreadsheet and open it again (to force a snapshot, until bug fix 4299935 is merged - hit the "Freeze & share" button - open the sharing link in an incognito window => formats on values are missing. Bug introduced with https://github.com/odoo/o-spreadsheet/commit/c3c0b45ed1eae582f5ad Task: 4300026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where users could not properly use the attachment popout from accounting move lines after a related mail service change. It restores the expected workflow for viewing attachments without disrupting accounting tasks.
Original PR description
Before this commit, the attachment_view_move_line component was not adapted to the new changes done in the mail_popout_service. This commit solves this problem. task-4275364
Warning messages shown during shift swaps, time off conflicts, and shift conflicts now take up less unnecessary space. This makes the planning screen easier to read and reduces visual clutter for managers and employees.
Original PR description
Prior to this commit, the alert displayed in planning for shifts-switch, time off conflict and shifts conflict was too big, leaving a lot of empty space within the div. This commit sets some bootstrap classes to fix the issue. Task: 4224786
Fixes an error that could prevent UK tax returns from being sent to HMRC. This helps accounting users complete the tax return submission flow reliably after a recent internal field-name change.
Original PR description
Install "l10n_uk"
Accounting / Reporting / Statement Reports / Tax Return
Actions / Send to HMRC
Issue: Traceback will raise
```
ValueError: Invalid field l10n_uk.vat.obligation.currency_table_period_key in leaf ('currency_table_period_key', '=', '18A1')
```
It occurs after e598fcb48b5e4f0126406a4008f175a88528ba85 replaced occurrences of `period_key` with `currency_table_period_key`
opw-4283511Company administrators can now open the Documents app without access errors when documents belong to companies they cannot access. The update also corrects how shared and company document filters determine visibility, improving consistency for multi-company setups.
Original PR description
Reproduce: 1/ Create documents and assign a company an admin (`group_erp_manager`) doesn't have access to 2/ As that admin, open the Documents app 3/ Go to "Home" and expect an Access Error There was a mismatch between `user_permission`'s search and compute methods for admins. We also take the opportunity to fix the SHARED (and clean COMPANY) search panel `CategoryDomain`s as odoobot's ownership wasn't used to make documents visible in COMPANY (therefore not in SHARED) on its own. A test is added. Task-4241620
This fixes an error in recruitment document processing caused by using the wrong candidate reference. It also improves skill detection so skills are recognized when they appear at the very start or end of a text, making extracted candidate information more reliable.
Original PR description
Traceback due to typo: applicant_id -> candidate_id \+ fix regexp to also match skills at the start and end of the text \+ make tests fail without the fix task-4207776
This fixes an automated Web Studio test so it checks approval behavior on apps that are already installed, matching the real upgrade workflow. It helps ensure approval rules are properly validated when users upgrade installed apps, without changing day-to-day functionality.
Original PR description
The trigger in the tour that filter apps was wrongly set to "Not Installed", instead of "Installed". Indeed, that tour puts approval on ir.module's updgrade button, so on already installed apps, and check whether approval rules are triggered when clicking on the "upgrade" button. So we need to filter only installed apps in the ir.module kanban.
This fixes an error that could prevent users with Mexican company setups from sending payment receipts by email. The payment process now includes the missing information needed for Mexican electronic invoicing attachments, avoiding an unexpected crash.
Original PR description
With an MX company setup Create a Payment Action > Send receipt by email Traceback will raise ``` KeyError: 'l10n_mx_edi_cfdi_attachment_id' ``` It occurs because the field is not defined on the payment model opw-4298457
Users can no longer drag documents while viewing the Trash folder. This prevents errors and confusing notifications by clearly explaining why the action is not allowed.
Original PR description
**Before this PR:** Dragging and dropping documents from the TRASH to another folder will result in a traceback or user error. Dragging and dropping documents within the TRASH will trigger an unusual notification. **After this PR:** Disable dragging in the TRASH folder and inform the user with a valid reason. Task-4231709
Fixed an issue where frozen shared spreadsheets created from pivot views could open as a blank page. The copy process now avoids carrying over outdated edit history when fresh frozen spreadsheet data is used, improving reliability for shared spreadsheet links.
Original PR description
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - hit the "Freeze & share" button - open the sharing link in an incognito window => blank page When the document is copied (using the `copy` method), the frozen data is given as a new value for `spreadsheet_data`. But revisions are still copied even though new data is provided on which the revisions should not apply. Task: 4299935
This update fixes two appointment booking issues that could confuse customers: HTML tags no longer appear in appointment descriptions, and available time slots now stay aligned with the month shown on the calendar. This helps prevent users from accidentally booking a slot for a date outside the calendar view.
Original PR description
1. Hide tags in description when changing appointments in the appointment selection dropdown 2. Make sure slots of previous date shown are in the current month when changing resource / user / tz in the dropdowns. Otherwise, display no slots. Task-4169513
This fixes an automated walkthrough used to verify field service report behavior by removing unnecessary click actions from check-only steps. The change helps keep internal validation reliable without changing day-to-day user functionality.
Original PR description
In this commit, we remove useless run: "click" on steps that are just a check.
Dragging a folder to the trash now refreshes the Documents side panel correctly, so the removed folder disappears immediately. This prevents confusion by keeping the folder list in sync with the user's action without extra manual refreshes.
Original PR description
Purpose ======= Fix the left panel which wasn't updated when dragging a folder to trash. Specification ============= When dragging a document of type 'folder' to the trash, the model is correctly being notified but the search model isn't, the folder is thus still visible in the left panel. Fixing that by also reloading the search model when archiving a document. Moving the reloading methods calls from toggleArchive to onDropDocuments as it is the only method where we don't reload the model and search model after archiving. Keeping the reload calls in toggleArchive caused redundant reloads of the models. Task-4260645
Closing a subscription now also stops any related recurring project tasks. This prevents new tasks from being created after the customer subscription has ended, keeping work lists aligned with active billing.
Original PR description
Steps: Create a product of type service that creates a task. Create a subscription with that product, and confirm. Note that if you set the task's state to done, it creates another one. Close the subscription. Issue: If you set the task's state to done, it still creates another one, whereas it would make sense that the task's recurrence ends with the "invoice recurrence". Cause: Actually, it was first designed that way, and `_set_closed_state` was overridden to unlink the recurrence. But then that method and `set_close` were rethought and the override wasn't called anymore. Solution: Just do the same thing, but in `set_close` i/o `_set_closed_state`. task-4259561
This update corrects a bug in the Spanish tax reporting module (l10n_es_reports) that prevented the 'Type for mod 347' field from automatically setting to the correct default value ('Regular operation'). This ensures invoices comply with Spanish tax regulations, resolving a potential reporting issue for Spanish customers.
Original PR description
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **Solution:** There were a function for the default (_default_mod_349_invoice_type) and an onchange on partner (_onchange_partner_id_set_347_invoice_type). Both of them were checking different conditions. The fix is merging these 2 methods by converting the field into a computed stored field where both conditions are handled. opw-4194030 Forward-Port-Of: odoo/enterprise#72958
This update corrects broken links within the Helpdesk Team form view, ensuring users can easily access relevant documentation. The fix resolves inaccuracies in links to E-learning, Visibility, Email Alias, and Community Forum resources. This improves the user experience and facilitates proper Helpdesk setup and usage.
Original PR description
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660
This update resolves a test failure in the Amazon integration (sale_amazon) caused by a dependency on data that isn't available in the no-demo testing environment. The fix ensures that tests run correctly without relying on this unavailable data, maintaining the stability of the integration.
Original PR description
test_sync_pickings depends on street value, which does not exist in no-demo mode, thus breaking tests. This commit fixes the issue. [broken test](https://runbot.odoo.com/web#id=73283&view_type=form&model=runbot.build.error&menu_id=405&cids=1)
This update fixes an issue where the app logo wasn't immediately updated after a user changed its icon or image. Now, the logo updates dynamically when a user confirms the change, providing a more consistent and user-friendly experience. This ensures users always see the correct branding.
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545
This update fixes an issue where tax closing with fiscal positions wasn't working correctly in Odoo reports. The system now correctly handles all fiscal positions when generating reports, and the closing mechanism has been adjusted to align with intended functionality, particularly for versions prior to 18.0. This ensures accurate tax reporting.
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388
This update resolves a bug where the 'packaging' button wasn't visible when adding products via the barcode app during inventory adjustments. This prevented users from efficiently adding quantities of 15 units, impacting the speed and accuracy of stock management. The fix ensures the button appears correctly, streamlining the inventory adjustment process.
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 ---
This update resolves a bug where subscriptions weren't always creating all expected deliveries due to an error in how invoices were processed. Specifically, the system was incorrectly calling a hook function on empty data, leading to incomplete delivery creation. This fix ensures all subscriptions are correctly processed, preventing missed deliveries.
Original PR description
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook…
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled.
However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron.
This often resulted in a situation where only the first subscription was ready for the hook, while the others are not, resulting in only the first delivery created.
---
Test result before fix:
```
2024-11-06 15:41:52,210 35880 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_cron_product_multiple_delivery_creation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 501, in test_cron_product_multiple_delivery_creation
self.assertTrue(bool(move_1))
AssertionError: False is not true
```
OPW-4166852This update resolves an issue where the barcode app incorrectly displayed a single unit count (1/1) after editing a delivery order. The fix ensures that the system accurately reflects the remaining quantity (0/4) when returning to the record, maintaining data consistency for barcode scanning.
Original PR description
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by…
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by clicking the external link arrow next to the location). - Come back to the record #### > The line now displayed a 1/1 but does not records what remains: 0/4. ### Cause of the Issue: Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update its quantity. However, when you leave the barcode, even thought it will save these change, it will not split the move in 2 for the barcode app to be able to rely on the backend data to generate a correct sate of the record. Threfore, when you come back to the record, the main component will be regenerated from the backend values of the `get_barcode_data`: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L76-L80 And will onlydisplay the "1/1" line that was reported fromt he back end. ### Fix: The `split_uncompleted_moves` method taking care of splitting the moves for barcode data compatibility: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/models/stock_move.py#L9-L11 is already called when you exit the barcode via the exit button: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L228-L231 https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/models/barcode_picking_model.js#L762-L765 These were added by commit 2eb6465e4f18c701efdf28ea4b8f95f3119d3db8 However, it should IMO be called every time you leave the app that is just before destroying the component. Furthermore, note that it will only split the moves if a save happend (which is the expacted behavior). opw-4232106 ---