Wednesday, February 14, 2024
22 changes · 17.0
Resolved issues and error corrections
Corrects BIS3 electronic invoice exports so VAT exemption reasons are included only where required by validation rules. This prevents compliance errors and warnings when invoices contain 0% tax lines, helping exported invoices pass e-invoicing checks more reliably.
Original PR description
Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error…
Previously, exporting BIS3 when there is a 0% tax in the invoice will
results in the XML showing warning of UBL-CR-601. But if we do not
include any TaxExemptionReason reason at all, a fatal error BR-E-10 will
pop up.
Here is the details of those 2 rules:
```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
<assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
exists(cbc:TaxExemptionReasonCode)">
[BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
"Exempt from VAT" shall have a VAT exemption reason code (BT-121)
or a VAT exemption reason text (BT-120). </assert>
and
(no context)
<assert id="UBL-CR-601" flag="warning" test="
not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
[UBL-CR-601]-A UBL invoice should not include the InvoiceLine
Item ClassifiedTaxCategory TaxExemptionReason </assert>
```
Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax)
in TaxTotal/TaxSubtotal/TaxCategory
Previously, the TaxExemptionReason will appear on both places.
This commit fixes that and adds a test to ensure that when a 0% tax is
present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory
task-id: 3703206This fixes a missing sales order reference in the payment form after a prior code change. Keeping that link ensures payments made from a sales order remain correctly associated with the order, reducing checkout or payment tracking issues.
Original PR description
In 7e012dd5441e87ce3c2688f9280381b041b00b0d, `_get_custom_rendering_context_values` was refactored and renamed `_get_extra_payment_form_values`. In this refactoring, `sale_order_id` was inadvertently removed from the values returned to the payment form. This commit re-introduce `sale_order_id` in the extra payment form values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now remove paid appointment bookings even when they answered booking questions. The related answers are deleted together with the booking, preventing checkout or order cleanup errors.
Original PR description
Problem: When a user books an appointment, whose up-front payment is enabled, and provides answers to the questions from the website,the user is unable to remove the booking because a ValidationError occurs due to the answers not getting deleted before the booking gets deleted. Solution: When a booking gets deleted, its answers should also get deleted to prevent errors. Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Attempt to remove the booking and a ValidationError occurs "The operation cannot be completed: The answer inputs must be linked to a meeting or to a booking." opw-3671511
This fix resolves an issue where users would encounter an error when trying to preview a document after restoring it from trash. The problem occurred because the preview window wasn't being closed during the restore process. This update ensures the preview closes properly when documents are restored, preventing errors and improving the user experience.
Original PR description
How to reproduce: 1. Select a file/doc. 2. Move to trash ( by trash bin icon). 3. Go to trash workspace. 4. Preview the file/doc. 5. Restore the file. 6. Now, try to preview it from the inspector. 7. It throws an error Technical Reason: Before version 17.0, Inside `_toggleArchive`, we were triggering the event to close the preview, but In 17.0 `_toggleArchive` is removed after this [commit](https://github.com/odoo-dev/enterprise/commit/2254eb07fd42ec88341d9d7ac92f09a379c6fa55#diff-78d9f8faf609f35072d4b2617a9e13b3f137a679efb2c46c84acf29da4edfe46L426), So the preview remains open. After this commit: No traceback will appear, and the preview will be closed, after clicking on the restore button. Task-3619214
This fix removes automatic contact assignment when documents are received via email. Previously, the system would automatically assign the email sender as the document contact if they were an existing partner, which caused conflicts with accounting features like OCR that need to independently detect contacts. Now documents received via email will have an empty contact field, allowing users and other systems to assign contacts without interference.
Original PR description
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In…
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In odoo/enterprise#39292, we have implemented: If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. In odoo/enterprise#50379, we have partially reverted the change: When receiving a document from an unknown contact, we no longer create a new partner. However, if the contact is known, we assign the already existing partner to the document. We revert here the last part that is to assign the author of the message to the document if the author is a known partner. However, we keep the tests introduced in odoo/enterprise#39292 with some minor adaptations. How to reproduce: - install documents with demo data - send an email with an attachment to the inbox alias (that create a document when receiving an email) from an email of an existing partner. It can be simulated using odoo_mail_gate.py. - find the document received and select it - in the document inspector, the contact should be empty but it is not Task-3672520 Forward-Port-Of: odoo/enterprise#55035
A dropdown menu for selecting additional fields in the Documents module was being blocked by table cells, preventing users from clicking options. This fix removes a CSS styling issue that was interfering with the dropdown display, restoring the ability to properly select fields in the documents list.
Original PR description
**Steps to reproduce:** 1- Install Documents module 2- Go to documents list view 3- Click on the dropdown menu for additional fields selection **Current behavior before PR:** The dropdown menu for additional fields selection in documents list view is interfered with the table cells so the user will not be able to select the wanted option. This is happening because the table row in this list is having a css value for position property which is relative.  **Desired behavior after PR is merged:** The view has been adjusted by removing the css style for the data-row in document list view.  opw-3682703 Forward-Port-Of: odoo/enterprise#54854
This fix ensures that records imported from CSV files in the Austrian SAFT module are properly assigned unique identifiers. Without these IDs, the system cannot create proper references to these records, causing errors during database upgrades and preventing accurate data tracking. This resolves upgrade failures and prevents duplicate entries when updating existing installations.
Original PR description
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a…
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a local migration script and thus the increase of subversion (I'll work on it if this gets approved). Updating a db with this module already installed, results in duplicated entries in `l10n_at_saft_account`. A simple script would match the existing records with newly created xmlids. This issue is also raising an error during upgrades because our scripts expect all csv data to have the `id` field: https://github.com/odoo/upgrade/blob/d861ce33eef5c51996005664353021be779121bd/migrations/base/0.0.0/pre-models-load-csv.py#L44 Here's the [traceback group](https://upgrade.odoo.com/web#id=1073&cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form). Tests conducted on [upg-1289502](https://upgrade.odoo.com/web#id=1289502&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form). <s>I have also taken the liberty to remove quotation marks to be more in line with the current standard in Odoo repos.</s>
This fix ensures that when the POS preparation display loses its internet connection and reconnects, it automatically retrieves any orders that were sent while offline. Previously, these orders would be lost, causing discrepancies in the kitchen display system. Now the system automatically syncs when the connection is restored, ensuring no orders are missed.
Original PR description
Current behavior: When the websocket connection is lost, the webworker will attempt to reconnect. However, the messages that were sent in the meantime are lost. The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. To solve this, we listen to the reconnect event and retrieve the orders that were sent in the meantime. opw-3701020
This update fixes a performance issue in accounting reports where all default expressions in the database were being evaluated whenever a lock date was set, causing problems when multiple localizations were installed. The fix now limits expression evaluation to only those relevant to the current company's available reports, improving system efficiency and stability.
Original PR description
Currently, when a lock date is set, all default expressions in the db are evaluated, causing some issues when there are different localizations installed. This commit limits the computation to only those expressions that exist on reports that are available to the current company. Forward-Port-Of: odoo/enterprise#56519
This fix resolves issues where AvaTax rejects invoices due to invalid state transitions, which can occur when system errors or concurrent access problems interrupt normal invoice processing. By switching to AvaTax's more flexible "create or adjust" endpoint, Odoo now treats itself as the source of truth for invoice states, preventing errors that could break automatic subscription renewals and other critical workflows.
Original PR description
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't…
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo because of a concurrent access error. Next time an invoice with the same Avatax Code is generated the tax calculation will fail with this error: odoo.exceptions.UserError: Odoo could not fetch the taxes related to Draft Invoice (* 123456) (M123456). Please check the status of `Journal Entry 123456` in the AvaTax portal. DocStatus is invalid for this operation. Errors like this can then break the automatic subscription renewal. Since there's many reasons a flow can crash it's better to make Avatax as idempotent as possible. The source of truth for invoice state is Odoo, regardless of what's in Avatax. To achieve this we'll fully switch to the createoradjust [1] endpoint that was previously introduced for test environments [2]. This endpoint allows almost all state transitions and should avoid the majority of blocking errors. [1] https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateOrAdjustTransaction [2] 12039763a3a8f27a1d69bebb6d661ad20ce3537b cc @tfr-odoo
This fix restores the ability to schedule call activities directly from the activity wizard without needing to navigate to the calendar view. Users can now create call activities with a working Schedule button, just like other activity types, improving workflow efficiency.
Original PR description
Since PR #137969, the `save` button is no longer available in schedule activity wizard. This PR makes `schedule` button available for call activities like other activities (except meeting), so user can create a call activity without going to calendar view. Before this PR:  After this PR:  task-3668732
This update resolves a font warning that occurs when installing Odoo on Debian Bookworm systems. The fix implements a workaround for a known Debian system issue that prevents proper font installation. This ensures a smoother installation experience for users deploying Odoo on Debian-based systems.
Original PR description
When installing the Odoo Debian package on Bookworm, under certain conditions, the following bug may arise: `Warn: Can't find .pfb for face 'Times-Roman'` See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059326 As this bug is not yet fixed on the Debian side, this commit is a workaround. This workaround was tested against Ubuntu Jammy and Debian Bookworm. It works in both version because the odoo depends on gsfonts and: - on Jammy, the file exists so the workaround is not applied - on Bookworms the gsfonts package installs the workaround target file x-original-commit: 70e192137e9b603c502aea878313cd7611fe0337
This fix resolves an issue where events with assigned companies were not appearing as options when creating lead rules without a company. The problem was caused by overly strict company filtering on the event field. The fix removes the automatic company filtering and uses a more flexible domain approach instead, allowing users to select any event regardless of company settings.
Original PR description
Steps to reproduce: - Install `event_crm` module - Create an Event with a company - Go to `Events > Configuration > Event Lead Rules` - Create a new rule and set no company - Try to set the event created above for Event field Issue: Event created not displayed as possible value for the Event field. Cause: Because we have `check_company=True` set on `event_id` field, the field will be filtered based on the `company_id` field, and since no company is set on the rule, events with company will not be listed. Commit that introduced the issue: https://github.com/odoo/odoo/commit/0479b2b59466ae1d6d74165345aa3a7dc5de24ed Solution: Revert to the previous behavior (remove `check_company=True` from `event_id` field and use a domain instead). opw-3715864 Forward-Port-Of: odoo/odoo#153906
Fixed an issue where dynamic placeholders were appearing below the visible page area when added near the end of email templates. The system now calculates the proper position by accounting for the popover height, ensuring all dynamic placeholders remain visible and accessible within the page boundaries.
Original PR description
Reproduction: 1. Install Sales, Email Marketing 2. Go to Email template by searching 3. Click the Sales: Send Quotation template and make a duplicate 4. Add empty lines in the template, till it almost reaches the end of the page 5. Use slash command to add a Dynamic holder, and it’ll be positioned below the page Fix: compute the position by consider the height of the popover to make sure it’ll be always in the page opw-3373403 task-3442559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#129883
This fix resolves an issue where inventory removal strategies were not recognized when using translated language names. When users switched to languages like French and set a translated removal strategy on product categories, the system would fail with an error. The fix ensures the system uses the original untranslated strategy names internally, allowing translations to work properly without breaking functionality.
Original PR description
Steps to reproduce: - Switch to a language where removal strategy name is translated (FR in 17.0) - Edit product category and set a translated removal strategy - Update on hand quantity Bug: User error removal strategy not implemented the removal strategy name is used in the code to identify them when changing the name through translation it is not recognized anymore Fix: use the untranslated term when checking the strategy type opw-3697462 Forward-Port-Of: odoo/odoo#152928
This fix restores the ability to properly display all measurement options (Planned amount, Theoretical amount, and Practical amount) when viewing budget analysis in graph format. Previously, switching between different measurements would cause some options to become unavailable or undefined. The fix ensures all measurement fields are properly tracked and available for selection.
Original PR description
Steps to reproduce ================== - Install account_accountant - Go to settings - Enable Budget Management - Go to Accounting > Reporting > Management > Budgets Analysis - Switch to the graph…
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to "Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and thus are skipped inside `computeReportMeasures` unless they are passed in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure. This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
Forward-Port-Of: odoo/odoo#153710
Forward-Port-Of: odoo/odoo#153599This update fixes a technical error that occurred when creating expense reports from multiple expenses with inconsistent date information. Previously, the system would crash when trying to automatically name the report. Now the system handles this gracefully by allowing users to manually enter the report name, ensuring the expense reporting process works smoothly.
Original PR description
This fixes a bug where trying to set the default name value of an expense report when created from the expense tree view would traceback. Step to reproduce: - Create 2+ new expenses having the same payment_mode (E.G. 'own_account') - Clear the date field of an expense so at least one of the expense has a date and one has no date - Press the 'Create Report' button on the expense tree view Current behaviour: Traceback due to bool > Date comparison Expected behaviour: We don't set a default report name, as it is required the user will be forced to set one manually. 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#153870 Forward-Port-Of: odoo/odoo#152852
This update fixes visibility problems that occur when using dark color themes on e-commerce product pages. Text in shopping cart popovers, product price badges, and product descriptions was becoming invisible because the text color wasn't adapting to dark backgrounds. The fix ensures text colors automatically adjust based on their specific background, improving readability across all theme options.
Original PR description
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk"…
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Click on the "Add to cart" button. - Hover over the cart in the navbar to make the popover appear. - Bug: All the popover texts are not visible because they are white and the background is white. Steps to reproduce the second bug (badge light): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Bug: The text of the "extra price" badge is not visible because both text and background are white. These two issues existed because the text color of those elements depended on the body's background color. With this commit, the text color for those elements is now determined by their respective backgrounds. This commit is a follow-up to this commit [1]. We also add the handling of the text-muted color to ensure it remains visible if a modal has a dark background while the body background color is light. Before this commit, we only handled the opposite case (dark body and light modal). This commit also fixes the text color of the button in a file input of a form when the background color of the <body> is dark. Similar to the other elements fixed in this commit, the text color of this button could be invisible because it was the same color as its background. [1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7 opw-3570774 _______________________________________________ **[FIX] web, website_sale: fix products page with a dark body background** Steps to reproduce the bugs: - Install the e-commerce on your website. - Go to the "/shop" page. - Click on "Edit" to enter edit mode. - Click on the "Customize" tab. - Choose "Cards" for the "Style" option. - Enable the "Product Description" toggle. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to exit edit mode. - Bug 1: The product description and the price in the product cards are not visible. - Bug 2: The scrollbar below the category buttons has the same color as its background. - Click on the "Mobile Preview" button in the backend navbar. - Click on the "Filters" button on the page to show the offcanvas. - Bug 3: The text color in the offcanvas is not visible and the background color of the inputs is the "body" background color instead of the "offcanvas" background color. opw-3570774 Forward-Port-Of: odoo/odoo#153741 Forward-Port-Of: odoo/odoo#150420
This fix ensures that event notification emails always have a proper partner assigned as the author, rather than defaulting to the OdooBot user when organizer and company email addresses are missing. This maintains data consistency in the email system and prevents incorrect author attribution in event-related communications.
Original PR description
The `author_id` of a `mail.mail` should always be a `res.partner` (cfr. [this line][1]). __Current behavior before commit:__ When `organizer.email` and `company.email` are empty, `author` is set to the user OdooBot instead of its corresponding partner. opw-3715380 [1]: https://github.com/odoo/odoo/blob/dcae15dcc072d14164d6454c35ce7d8d870e96ee/addons/mail/wizard/mail_compose_message.py#L107 Forward-Port-Of: odoo/odoo#153689
Users can now edit the Manufacturing Order (MO) Overview report using Studio without encountering errors. The fix adds proper fallback values to prevent calculation errors when the report is loaded in the Studio editor, making the report fully customizable through the Studio interface.
Original PR description
Steps: - Install `mrp` - Install `web_studio` - Open `Inventory` - Click on `Toggle Studio` button - Click on `Reports` tab - Remove default filter - Try to open `MO Overview` report via reports view…
Steps: - Install `mrp` - Install `web_studio` - Open `Inventory` - Click on `Toggle Studio` button - Click on `Reports` tab - Remove default filter - Try to open `MO Overview` report via reports view - Traceback When loading the `MO Overview` report, `_get_report_qweb` is called and builds the context rendering here https://github.com/odoo/enterprise/blob/b7d0d3034d53cdab831f42f8b37a14cf50f3720e/web_studio/controllers/report.py#L549 We therefore call _get_rendering_context with `[0]` in `docids`, which will call `_get_report_values` in `mrp/report/mrp_report_mo_overview`. https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L29-L30 https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L53-L54 `_get_report_data` performs a `browse(0)` on `mrp.production`. BaseModels::browse replaces falsy values with empty tuples `()`. https://github.com/odoo/odoo/blob/5d726c933b591468bcef85a4e14b183278a00e5b/odoo/models.py#L5441-L5442 This implies the return of an empty model record. `mrp_report_mo_overview` will therefore use a record containing null values in its operations, for example division, which causes a division by 0 error, or a log10(0) in `_get_uom_precision` because `product_uom.rounding` is 0. https://github.com/odoo/odoo/blob/6e8e62db1fa2010c3e6696baacaedf997fd8fa89/addons/mrp/report/mrp_report_mo_overview.py#L105-L106 This commit corrects these incorrect defaults with fallbacks opw-[3725827](https://www.odoo.com/web#id=3725827&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#153594
This fix prevents sub-tasks from being automatically assigned to a project when created through the smart button interface. Previously, new sub-tasks were incorrectly inheriting the parent project assignment, which violated the intended behavior where sub-tasks should remain unassigned to projects. This change removes the automatic project context passing during sub-task creation.
Original PR description
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and…
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately. **Steps to Reproduce**: 1. Open `Project` app. 2. Enter any project, then navigate to any task. 3. Within the task, go to `sub-task` tab. 4. At the top center of the page, click on 'Sub-task' smart button. 5. Then, create a new sub-task using the 'New' button. 6. You will observe that the sub-task is immediately assigned to a project, which should not happen. **Proposed Solution**: By removing the passing of the default_project_id variable from the context when open a sub-task action, we ensure that sub-tasks are not automatically assigned to a project, as intended. opw-3708537 Forward-Port-Of: odoo/odoo#153975 Forward-Port-Of: odoo/odoo#153349
Fixed an issue where the Members module was hidden from the dashboard when installed without the full Accounting module. The module's access permissions have been updated to only require the Invoicing module, which is its actual dependency. Users can now install and use the Members module independently without needing the complete Accounting module.
Original PR description
[FIX] membership : Members module is not visible without Accounting Steps to reproduce: 1- Install Members module while Accounting is uninstalled Current behavior before PR: When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module `group_account_user`. Desired behavior after PR is merged: Now the Members module has the access right group of Invoicing module `group_account_invoice` which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed opw-3627010 Forward-Port-Of: odoo/odoo#153938 Forward-Port-Of: odoo/odoo#146373