Daily updates from Odoo
Monday, March 10, 2025
44 changes · 18.0
New functionality added to Odoo
This adds new Bulgarian purchase and sales ledger tax reports, helping companies meet local reporting requirements more directly in Odoo. It also adds related fields on journals and invoices/bills so the new reports can capture the needed ledger details.
Original PR description
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/enterprise/pull/74258
The point of sale customer display now shows the customer name and, on the ticket screen, the amount per guest. Refunded items are separated into their own refunds section, making the display easier for customers and staff to understand.
Original PR description
In this commit : - Show customer name on the customer Display - Show amount / guest if we are on ticketscreen - Refunded lines should be separately segregated under refunds subsection 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
Adds new purchase and sales ledger tax reports for Bulgarian localization, helping companies meet local reporting requirements more directly in Odoo. It also adds supporting company, journal, and invoice data fields so the reports can capture the required ledger information accurately.
Original PR description
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/odoo/pull/187779
Enhancements to existing features
This update lets Odoo recognize point-of-sale categories by their full hierarchy, so products can be imported into nested POS categories without errors. It improves data import reliability for businesses using multi-level POS category structures.
Original PR description
Description of the issue/feature this PR addresses: Adding new field for `_rec_name` (`complete_name`) which will be computed by hierarchy Current behavior before PR: Currently we cannot import product's POS category if it's nested. Odoo will show error because the POS category is not found Desired behavior after PR is merged: Will be able to import nested POS category --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bills are now checked more broadly for potential duplicates, including when dates are missing or only the same year matches. Suspected duplicates stay visible, are highlighted in list views, and prevent automatic posting so teams can review them before payment or accounting actions proceed.
Original PR description
See commits :) Entreprise PR: https://github.com/odoo/enterprise/pull/79471
Mexican localization now recognizes received vendor bills when checking SAT status, so users can see the SAT validation field on vendor bill forms. This brings vendor bill visibility closer to the existing invoice workflow and helps accounting teams verify compliance status more easily.
Original PR description
Adding 'invoice_received' as an accepted state in l10n_mx_edi_document.py -> _update_document_sat_state and account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment appears to be enough to enable the SAT functionality that is already present for invoices. With account_move SAT state no longer remaining None, the SAT field on the form view shows up by itself. Concern: adding 'invoice_received' state in l10n_mx_edi_document.py -> _create_update_invoice_document_from_invoice might also be needed to keep up the consistency, but I am not certain since that appears to go farther into CFDI-side logic. task-4368532
Potential duplicate vendor bills are now kept visible even after posting, including in list views. Automatic posting is stopped when a possible duplicate is detected, helping businesses avoid accidental duplicate payments.
Original PR description
Purpose ======= Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important…
Purpose ======= Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important than ever in the modern electronic invoicing world, where bills are more and more handled automatically. We want to make sure that: - Potential duplicates remain visible at all time, including in list view - Automated actions like auto posting are not done when a potential duplicate is detected. Specs ===== 1. Do not hide the warning on potential bill duplicate for posted invoices. The information remains pertinent. 2. When a move should be posted automatically (by the Auto-post feature on account.move or by the OCR auto-post), but a potential duplicate is found, prevent the auto-post from happening. Log the information in the chatter: "Auto-post was disabled on this invoice because a potential duplicate was detected." 3. In list view put the reference in red background when a potential duplicate on that invoice is detected. task-4578751 Community PR: https://github.com/odoo/odoo/pull/197891
Resolved issues and error corrections
Fixes a display issue where banner content was not properly aligned with the banner icon in the HTML editor. This improves the visual consistency of inserted banners and helps users create cleaner page content.
Original PR description
**Current behavior before PR:** When inserting a banner, div base container inside banner is not properly aligned to banner icon. **Desired behavior after PR is merged:** Now div base container inside banner is properly aligned to banner icon. task-4591824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates the web tour service to handle automated tour steps more reliably. It helps guided walkthroughs and onboarding flows behave as expected, reducing confusion during product demos, training, or testing.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes spreadsheet pivots so they no longer keep a sort order based on a measure that is no longer selected or available. Users avoid confusing or incorrect pivot results when changing measures or opening views with predefined sorting.
Original PR description
Steps: Go to a pivot view with: - either a predefined sort on the action/filter. - sort by a measure then uncheck the measure. We can't keep the sorting because the sorting is done client-side. If the field is not part of the measures, we don't have the data to sort... Task: 4467262 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
Internal users with Survey access can now print surveys that are limited to invited participants. This prevents them from being sent to a blank page and keeps survey administration workflows running smoothly.
Original PR description
Steps to reproduce: - Let's consider an internal user U with acces rights to Survey - Let's consider a survey S with access mode set to 'Invited People only' - Try to print survey S with U Bug: U is redirected to a blank page When a survey is set to 'Invited People only', internal users could not print the survey. opw:4576125
This fixes a crash that could happen when users created a private or public key from a certificate without attaching the required key file. The certificate form now prevents that incomplete key creation path, helping users avoid confusing save errors.
Original PR description
Currently, an error occurs when while adding a private/public key in the certificate and key has no 'content' (Key file). Step to produce: - Install the ```certificate``` module. - Go to Settings,…
Currently, an error occurs when while adding a private/public key in the certificate and key has no 'content' (Key file). Step to produce: - Install the ```certificate``` module. - Go to Settings, Click on 'certificates' which is in the Certificates and Keys section - Create a new certificate, add a name and valid certificate file. - Create a ```Private Key``` or ```Public Key``` from the certificate form view and try to save the record. ```TypeError: argument should be a bytes-like object or ASCII string, not 'bool'``` An error occurs because a user can directly create a certificate's private/public key from the certificate form view without adding any content that is required true in ```certificate.key``` model, so an error occurs when the system tries to decode the content of private/public key at [1], but it is not available. Link [1]: https://github.com/odoo/odoo/blob/2be7f413493a6ad43980eb031b8383deb3a706c0/addons/certificate/models/key.py#L157-L160 To resolve this issue, remove the 'create' option for private/public keys from certificate form view Sentry-5993525387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Tasks created from sales orders that use quotation templates will now show the product name as the task title instead of the line description. This makes project tasks easier to identify and keeps the quotation description available in the task details.
Original PR description
### Steps to reproduce: - create a new quotation with configured quotation template - the descriptions are added by default (thanks to the template) - confirm the SO - the task is created, but it shows the description in the title (instead of the name of the product) and the description tab is empty ### Cause: In 'Quotation Templates' the description of each line is being stored under the name of 'name' so when using this quotation template in an SO the SO line name will be the template line name not the product name + the description and so when creating the task we use the name of the SO line which in that case will be the description. ### Fix: We are checking if we have a quotation template or not and if we don't we use the name of the SO line to get the name and the description of the task if we have a quotation template we use the product name for the name of the task and the name of the template line as a description. opw-4482867
Public shoppers could encounter an access error when viewing product pages that include published combo items with tax-included prices. This fix allows the page to load correctly by safely reading the needed combo product tax information.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set website to display prices tax included; 2. have a combo item published; 3. open product's eCommerce page as public user. Issue ----- Access Error. Cause ----- Commit 4ec8d2198a1a0 added a disclaimer for combo items products tax calculations. It checks the `taxes_id` fields of the `combo_item_ids`. Issue is that the `product.combo` model isn't accessible for public users (unlike `product.product` and `product.template`. Solution -------- Use `sudo` on the combo product. opw-4608719
Accounting email aliases now mark bounce messages so the system can recognize and stop repeated rerouting. This prevents potential email loops when messages without attachments are rejected, reducing unnecessary email traffic and operational noise.
Original PR description
Sending emails with no attachments now bounce when sending to account.move aliases. This can cause loops if the bounce email is then rerouted because are not using any loop detection. Added the loop detection message id to the bounce email in order to prevent any loops. opw-4576526
This fixes an issue where editing a sales quotation email could make part of the message disappear. The quotation email template now preserves the affected text, helping sales teams send complete and consistent customer communications.
Original PR description
If user edited sale quotation, part of the template with span tag would disapear. opw-4563470 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where indenting a bullet list item while multiple people edit the same document could trigger an error for other collaborators. The editor now handles the list structure safely, reducing interruptions and improving reliability during shared editing.
Original PR description
**Problem**: When collaborating, indenting a list item (`LI`) using "Tab" causes a structural issue in the DOM. **Scenario**: 1. User C1 and C2 both edit a list item in collaboration mode. - Common…
**Problem**:
When collaborating, indenting a list item (`LI`) using "Tab"
causes a structural issue in the DOM.
**Scenario**:
1. User C1 and C2 both edit a list item in collaboration mode.
- Common structure at the beginning:
`<ul><li>[]</li></ul>`
- When C1 presses "Tab", the DOM updates to:
`<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
2. At this point C2 still has:
`<ul><li>[]</li></ul>`
3. When C2 receives a mutation update, it tries to insert:
`<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
before:
`<li>[]</li>`
- **Issue**: `li` is already inside `li (new)`, causing a DOM error.
**Solution**:
- Before inserting, remove `li2`, then reinsert it at the
correct position.
- This ensures the `.before()` operation does not conflict
with `li1`.
**PS**: I adapted `createPeers` and `Wysiwygs` to make it work with
custom content and by default it will use `initialValue`, because in
this test i needed to test collaboration with `ul`, `li`.
**Steps to Reproduce**:
1. Open two tabs with the editor.
2. Create a bullet list in the first tab.
3. Press "Tab" to indent a list item.
4. Observe a traceback error in the second tab.
opw-4538671
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe salary configurator now shows the working schedule dropdown in the expected place, directly below its label. This fixes a visual issue that could make the form harder to understand when configuring part-time salary offers.
Original PR description
This commit restores the position of the working schedule dropdown to be just below the label in the salary configurator, like in previous versions.  The cause of the issue is that the SelectMenuWrapper component is attached just after the invisible select element: https://github.com/odoo/enterprise/blob/9f6a4f0697edcc9330ad7976c6602d892e7b6ef9/hr_contract_salary/static/src/js/hr_contract_salary.js#L69-L71 But before other elements are placed in the DOM between them. A solution is to add a wrapper div around the selection, ensuring the `SelectMenuWrapper` component is attached inside that div, and further elements placed in the DOM after the wrapper div. **Steps to reproduce** - Install hr_contract_salary_payroll - Select any employee contract > Generate offer > Salary configurator - Add `part?=80` (any value != 100) at the end of URL opw-4496279
This update fixes an internal Studio test that could fail when run with newer Python versions due to changes in how documentation text is handled. It helps keep quality checks reliable without changing customer-facing behavior.
Original PR description
Since 3.13, leading whitespace is automatically stripped in a docstring (python/cpython#81283). The `info` field of an ir.model is a copy of the docstring, so running :TestStudioExports.test_export_customizations on 3.13 fails because the documents are different (the content of the info field is indented and has a leading space matching `Model`'s docstring). Instead of duplicating the info field, just inject it in the document we're creating from the record, that way it doesn't break if someone decides to improve the docstring either.
Draft invoices in the Peru electronic invoicing module can now be printed correctly. The fix prevents a printing error caused by draft invoices having no invoice number yet in Odoo 18.0.
Original PR description
Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean.
This fix prevents pivot spreadsheets from keeping a sort order based on a measure that is no longer selected. Users will avoid misleading or broken sorting when they remove measures or open views with preset sorts that cannot be applied.
Original PR description
Steps: Go to a pivot view with: - either a predefined sort on the action/filter. - sort by a measure then uncheck the measure. We can't keep the sorting because the sorting is done client-side. If the field is not part of the measures, we don't have the data to sort... Task: 4467262
The map view now shows pin counter numbers without cutting them off. This makes location counts easier to read and avoids confusion when users review records on a map.
Original PR description
This commit fixes the style of the pin counter on the map view. The counter didn't display the number correctly. task-4544732
Screen orientation settings are now only applied when an IoT Box supports kiosk mode. This prevents unintended orientation changes on devices where kiosk functionality is not available.
Original PR description
We made invisible the `screen_orientation` field if `can_be_kiosk` was `False` on the IoT Box, but we still updated the screen orientation if `screen_orientation` was set: which was always the case as it has a default value. We now update only if the IoT Box `can_be_kiosk`. Task: 4606855
The website generator now correctly updates the version information for existing databases. This helps keep generated website records aligned with the current system version and avoids outdated metadata.
Original PR description
This commit fixes a bug where the version of existing DBs was not being updated. To fix this, we use a compute for the version field.
The project dashboard now shows expense budget status with more intuitive colors. Staying under budget is treated as positive, while exceeding the expense budget is highlighted as negative, helping users interpret project costs correctly.
Original PR description
How to reproduce the issue: - Create an expense budget and associate it to a project. - Create invoice/bills related to the project In the project dashboard view, the remaining value will be marked in green for expenses that exceed the budget (over-achieving costs) and in red for expenses that are under the budget (under-achieving costs). However, this was deemed non-intuitive, as under-achieving costs should be seen as a positive indicator. After this commit the color for expense budget are inverted. opw-4562815
Miscellaneous changes
Current behavior before commit: creating cut-off journal entries for a vendor bill in a previous year using a new sequence reset period in current year will raise an error due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Reason: due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Fix: Added a function to compute a reference move for each get_lock_safe_date call an
Original PR description
Current behavior before commit: creating cut-off journal entries for a vendor bill in a previous year using a new sequence reset period in current year will raise an error due to the accrual move…
Current behavior before commit: creating cut-off journal entries for a vendor bill in a previous year using a new sequence reset period in current year will raise an error due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Reason: due to the accrual move date mismatch with the destination move fetched from the move in _get_accounting_date Fix: Added a function to compute a reference move for each get_lock_safe_date call and compare approrpiate dates for accrual moves. Steps to reproduce on runbot: 1. ensure the sequence for the Miscellaneous Operations journal (l10n_fr for example) resets yearly for the previous year (ex 2024) 2. create a new journal entry in the Miscellaneous Operations journal in current year and rename it to "Name 3000" 3. Create a vendor bill and set the date field to be 12/12/2024 for example and post it 4. Create cut-off journal entries with a recognition date set as today and the same journal "Miscellaneous Operations" and observe the traceback. opw-4507925 Forward-Port-Of: odoo/odoo#196836
Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid. This commit fixes the issue by improving the search method implementing for the `task_ids` field to make sure the search view supports a query contained inside `value` parameter. Steps to reproduce the issue: ---------------------------- 0. Install `sale_timesheet` module with demo data
Original PR description
Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid.…
Before this commit, when the user creates a custom filter in SO model to select the SO in which there is at least one task linked to a specific project, he got an error saying the domain is invalid. This commit fixes the issue by improving the search method implementing for the `task_ids` field to make sure the search view supports a query contained inside `value` parameter. Steps to reproduce the issue: ---------------------------- 0. Install `sale_timesheet` module with demo data 1. Go to Sales app 2. Creates a custom filter and select `Tasks associated to this sale > Project` as left part, `=` as operator (second field in the custom filter) and `After sales-service` as project (right part, last field in the custom filter). 3. Apply the custom filter Expected behavior: ----------------- The custom filter should be applied without any issue. Current behavior: ---------------- The user has an error saying the domain is invalid when he tries to save/apply his custom filter. Forward-Port-Of: odoo/odoo#200743 Forward-Port-Of: odoo/odoo#200130
Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right. This commit limits only some of the items to users having the Restricted Editor right: - Published: unrelated - Mobile preview: unrelated - Website switcher: unrelated - + New: Restricted Editor only - Edit in backend: unrelated - Translate: Restricted Editor only - Edit: Restricted Editor only It therefore now shows the Published button only based on the result of th
Original PR description
Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right. This commit limits only some of the items to users having the Restricted Editor…
Before this commit all systray items of website were hidden for users that did not have the Restricted Editor right. This commit limits only some of the items to users having the Restricted Editor right: - Published: unrelated - Mobile preview: unrelated - Website switcher: unrelated - + New: Restricted Editor only - Edit in backend: unrelated - Translate: Restricted Editor only - Edit: Restricted Editor only It therefore now shows the Published button only based on the result of the `_compute_can_publish` method of the `website.published.mixin`. The default implementation now checks whether the user has write access to the `website_published` field on the record. Steps to reproduce: - Install `website_crm_partner_assign`. - Connect as a user without any Website role, and in Sales, the "User: Own Documents Only" role. - Go to a partner in the `/partners` page. => "Published" button did not appear. And on the contrary: - Connect as a Restricted Editor user without Sales rights. - Go to a partner in the `/partners` page. - Click on "Published". => An access right error notification did appear. task-3175890 Forward-Port-Of: odoo/odoo#198208 Forward-Port-Of: odoo/odoo#112421
Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This error occurred because the getReceiptHeaderData method in the PoS restaurant used ‘this.get_order()’ to retrieve the order, which is not applicable for paid orders. The order is now passed as an argument to the getReceiptHeaderData function, allowing it to be used when assigning the is_settlement fi
Original PR description
Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This…
Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This error occurred because the getReceiptHeaderData method in the PoS restaurant used ‘this.get_order()’ to retrieve the order, which is not applicable for paid orders. The order is now passed as an argument to the getReceiptHeaderData function, allowing it to be used when assigning the is_settlement field. This was actually resolved in PR: #145252 but was accidentally reverted during this PR: #142566 Current behavior before PR - In saas-17.4, we get a traceback for the is_settlement field In 18.0+ it will silently fail Desired behavior after PR: Print the order Steps to reproduce: 1.) Install point_of_sale; pos_restaurant; l10n_sa_pos; 2.) This should have created a company 'SA Company' with the country code of 'SA', currency of 'SAR', country_id of Saudi Arabia. If not create one and activate it. 3.) Create a Restaurant point of sale shop 4.) Create a sale > validate so we had orders in the 'Paid' state 5.) Ensure no table is selected 6.) Navigate to orders > filter 'Paid' 7.) Select a paid order and 'Print Receipt' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200607
…ot used and give warning on the log Description of the issue/feature this PR addresses: it not an issue but unnecessary overridden 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#200060
Original PR description
…ot used and give warning on the log Description of the issue/feature this PR addresses: it not an issue but unnecessary overridden 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#200060
The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200897
Original PR description
The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200897
**Issue:** - When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.  **Solution:** - After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.co
Original PR description
**Issue:** - When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.  **Solution:** - After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.company_details` class, but this is no longer sufficient due to the presence of `<p>` tags in the footer. To resolve this - - remove the general font-size directive - add a new one in li - add a limited line-height to the `<p>` tag to reduce the vertical size of the footer, given we are boosting the font size.  opw-4506533 Forward-Port-Of: odoo/odoo#198117
### Steps to reproduce: - Create a new invoice - Attach a ZIP file then a PDF file - The file viewer shows but tries to preview the ZIP file - Happens with all non-viewable files ### Cause: The ZIP file is put as main attachment and the method `register_as_main_attachment` only change the main attachment (with `force=False`) when there is no main attachment. The behavior of the file viewer is problematic because we cannot switch between the attachments in the preview, so we cannot see
Original PR description
### Steps to reproduce: - Create a new invoice - Attach a ZIP file then a PDF file - The file viewer shows but tries to preview the ZIP file - Happens with all non-viewable files ### Cause: The ZIP…
### Steps to reproduce: - Create a new invoice - Attach a ZIP file then a PDF file - The file viewer shows but tries to preview the ZIP file - Happens with all non-viewable files ### Cause: The ZIP file is put as main attachment and the method `register_as_main_attachment` only change the main attachment (with `force=False`) when there is no main attachment. The behavior of the file viewer is problematic because we cannot switch between the attachments in the preview, so we cannot see the PDF. But if we add another PDF file (so one ZIP and 2 PDFs), we can switch but it will never show the ZIP again, only the two PDFs. This behavior is due to the [next/previous arrows](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/components/web_client_view_attachment_view/web_client_view_attachment_view.xml#L13) being displayed only if [`attachmentsInWebClientView`](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/models/attachment.js#L323-L328) contains more than one item. But this list only contains viewable attachments (PDF or Images), and the next/previous arrows only take attachments from this list. As the arrows are [changing the main attachment](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/models/web_client_view_attachment_view.js#L17) to change the displayed preview, it never comes back to the problematic ZIP file. ### Solution: Also display the arrows if the main attachment is not viewable and there is more than one attachment. This way the user can return in the list of viewable attachments. This is not an optimal because Odoo will still try to display the ZIP file, but it is a simple fix that works. I tried restraining the main attachment field only to viewable files in this [PR](https://github.com/odoo/odoo/pull/196390), but it seems to break things specially with OCR extraction and apparently it is sometimes wanted to have an XML as main attachment. opw-4486363 Forward-Port-Of: odoo/odoo#200427 Forward-Port-Of: odoo/odoo#196446
This PR backports some commits to add the tool functions to check structured reference/communication. It also add a new function for Netherlands and finally apply a check during the qr code values generation to make sure that we don't pass unstructured communication as structured one. See all the commit messages. Doc for NL case: - https://www.betaalvereniging.nl/betalingsverkeer/giraal-betalingsverkeer/betalingskenmerken/ - https://nl.wikipedia.org/wiki/Elfproef opw-4575004 ---
Original PR description
This PR backports some commits to add the tool functions to check structured reference/communication. It also add a new function for Netherlands and finally apply a check during the qr code values generation to make sure that we don't pass unstructured communication as structured one. See all the commit messages. Doc for NL case: - https://www.betaalvereniging.nl/betalingsverkeer/giraal-betalingsverkeer/betalingskenmerken/ - https://nl.wikipedia.org/wiki/Elfproef opw-4575004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200699 Forward-Port-Of: odoo/odoo#199735
Fix error in .pot and .po files that led to wrong translations. opw-4621039 Forward-Port-Of: odoo/odoo#200708
Original PR description
Fix error in .pot and .po files that led to wrong translations. opw-4621039 Forward-Port-Of: odoo/odoo#200708
How to reproduce: - Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason') - Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` ) - Add a relational filter that points on the 'lost reason' model - Go back to the dashboard app to visualize it and click on the modified cell -> crash The pivot ui plugin did not properly account for that scenario as it was ex
Original PR description
How to reproduce: - Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason') - Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` ) - Add a relational filter that points on the 'lost reason' model - Go back to the dashboard app to visualize it and click on the modified cell -> crash The pivot ui plugin did not properly account for that scenario as it was expecting a string as an output of `getPivotHeaderValue`. However, the later had changed its return type since we handle both balues and stringified values as arguments in the formula. Task-4582602 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#199575 Forward-Port-Of: odoo/odoo#198002
Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders. task: 4423974 Forward-Port-Of: odoo/enterprise#77683
Original PR description
Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders. task: 4423974 Forward-Port-Of: odoo/enterprise#77683
Add a step that ensures a name_search has been fired. The hypothesis is that the dropdown item is already present before editing the m2o's value (that triggers a name_search) The tour advances, captures a trigger but right there the rpc returns, modifies the DOM and the captured element is not there anymore, crashing as a consequence. runbot-error-67580 Forward-Port-Of: odoo/enterprise#80856 Forward-Port-Of: odoo/enterprise#80598
Original PR description
Add a step that ensures a name_search has been fired. The hypothesis is that the dropdown item is already present before editing the m2o's value (that triggers a name_search) The tour advances, captures a trigger but right there the rpc returns, modifies the DOM and the captured element is not there anymore, crashing as a consequence. runbot-error-67580 Forward-Port-Of: odoo/enterprise#80856 Forward-Port-Of: odoo/enterprise#80598
This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint. We also needed to update how the media id was fetched from the response as it changed between versions. task-4606722 Forward-Port-Of: odoo/enterprise#80232
Original PR description
This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint. We also needed to update how the media id was fetched from the response as it changed between versions. task-4606722 Forward-Port-Of: odoo/enterprise#80232
Purpose ======= In the Facebook settings, a user can ask an application (eg Social) to remove his data. If the deletion is not implemented, it should be done manually for each user, and so we want to automate that process. Technical ========= The deletion process is done in that order: 1. The user go to his settings and ask Odoo to remove the data we have 2. Facebook will hit an endpoint in IAP, with a signature, and the Facebook user id 3. IAP will reach the database, (with a shar
Original PR description
Purpose ======= In the Facebook settings, a user can ask an application (eg Social) to remove his data. If the deletion is not implemented, it should be done manually for each user, and so we want to…
Purpose
=======
In the Facebook settings, a user can ask an application (eg Social) to remove his data.
If the deletion is not implemented, it should be done manually for each user, and so we want to automate that process.
Technical
=========
The deletion process is done in that order:
1. The user go to his settings and ask Odoo to remove the data we have
2. Facebook will hit an endpoint in IAP, with a signature, and the Facebook user id
3. IAP will reach the database, (with a shared secret to authenticate itself) and that endpoint will remove the social accounts, and also the social posts / templates if the account is selected
We do it that way, instead of having a CRON on the client database, because we are able to know if the user uninstalled social, or if he already removed the account.
If the database is not reachable from the internet, we will have it's dbuuid, and so, we will be able to take an action.
Authentication
==============
IAP needs to authenticate to the Odoo database,
so both need to share a secret.
That secret can not be the extended token,
because we don't store it on the Odoo side.
That secret is derived from the database secret, and sent when we ask the Facebook URL (in python, without a browser redirection), so the social user can not see it (otherwise, he will be able to bypass company access rules, and delete the social accounts of different company).
Setup
=====
1. Start Odoo and IAP instances
2. Start ngrok on the IAP port
3. In the Facebook settings ("Facebook Login For Business" -> Settings)
- Add <ngrok_url>/api/social/facebook/1/callback in the Facebook settings
- Add <ngrok_url>/api/social_facebook/1/deletion_callback in the Facebook settings
4. Add the Facebook credentials in the IAP settings
5. In the Odoo db, add the system parameter `social.social_iap_endpoint` with the ngrok url
6. In the IAP db, change the system parameter `web.base.url` with the ngrok url
7. In the IAP code, in `facebook_controller.py`, comment the dbuid check `_check_has_access`
8. Add your accounts
9. Go to `https://www.facebook.com/settings/?tab=business_tools`, and remove the app
10. Go to the "Removed" tab, then "View Details" and click on "Send Request"
Task-4350697
Forward-Port-Of: odoo/enterprise#74865In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type. opw-4592446 Forward-Port-Of: odoo/enterprise#80019
Original PR description
In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type. opw-4592446 Forward-Port-Of: odoo/enterprise#80019
Problem ---------- - Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0. Objective ---------- - check if the SHIF/NHIF amount == 0 before add it in report entries. - Don't allow the user to add a line. Solution ---------- - add a condition on the SHIF/NHIF amount to add the payslip task-4463586 Forward-Port-Of: odoo/enterprise#80453
Original PR description
Problem ---------- - Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0. Objective ---------- - check if the SHIF/NHIF amount == 0 before add it in report entries. - Don't allow the user to add a line. Solution ---------- - add a condition on the SHIF/NHIF amount to add the payslip task-4463586 Forward-Port-Of: odoo/enterprise#80453
As a user I want to be able to choose if I want the frame or not, and as it's saved in a preference like way, I want to be able to disable the default frame if I enable it previously Steps: - Setup a signature image for your user - Open Sign - Upload a document and add Signature field - Sign the document - Open the Sign dialog - Check the "frame" option - Sign - Repeat the steps BUT uncheck frame option Actual result: - Signature frame is still there for the user - All signature
Original PR description
As a user I want to be able to choose if I want the frame or not, and as it's saved in a preference like way, I want to be able to disable the default frame if I enable it previously Steps: - Setup a signature image for your user - Open Sign - Upload a document and add Signature field - Sign the document - Open the Sign dialog - Check the "frame" option - Sign - Repeat the steps BUT uncheck frame option Actual result: - Signature frame is still there for the user - All signature have the frame by default Expected result: - If user sign without frame, this preferences is apply for next signature opw-4610410 Forward-Port-Of: odoo/enterprise#80848
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example: Morning: `08:00` to `12:00`, Afternoon: `12:00` to `16:00` - Go to *Planning* > *New* - Generate a slot within this period as an open shift - Go to the next week and select *Copy previous week* - Traceback error appears: - `TypeError: '<' not supported between instances of 'NoneType' an
Original PR description
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example:…
__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example: Morning: `08:00` to `12:00`, Afternoon: `12:00` to `16:00` - Go to *Planning* > *New* - Generate a slot within this period as an open shift - Go to the next week and select *Copy previous week* - Traceback error appears: - `TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'` __Description of the issue:__ - In Planning, `calender._attendance_intervals_batch` function returns dict() of `workInterval`, which does not merge overlapping intervals. The `_merge` function in `Intervals` assumes input intervals are already merged, This mismatch caused issues in the planning app when unmerged overlapping intervals were passed to `_merge` __Description of the solution:__ - Convert `workInterval` instances to `Intervals` by passing `workInterval._items` directly to `Intervals`, as it performs merging on overlapping intervals during instantiation. - bug introduced in: [#f283540][1] - opw-4282039 [1]:https://github.com/odoo/odoo/commit/f283540336b29037fe8af9c1a951c3d27c941b3d#diff-357c95d58ea67c00f24d3a4c5a8a987041c42de13ca9f5535e7bb250b2927af6L214 Forward-Port-Of: odoo/enterprise#73618