Wednesday, October 16, 2024
55 changes · 18.0
Enhancements to existing features
Date and time fields can now show placeholders that adjust dynamically based on the field setup. This helps users better understand what kind of date information to enter, improving clarity in forms without changing business workflows.
Original PR description
See commit
The Point of Sale employee settings have been adjusted so the Advanced Rights option displays more neatly on a single line. The placeholder text was also updated to make the setting clearer for users configuring employee permissions.
Original PR description
In this commit: == - Improve the view of Advance Rights to look in one line. - Change the placeholder for Advance Rights in settings. task-4260676 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The deferred end date field now shows a dynamic hint that helps users understand how the deferred period is calculated. This makes it clearer that both the start and end dates are included, reducing confusion when entering accounting deferrals.
Original PR description
We now add a dynamic placeholder to the deferred end date which allows the user to better understand what a deferred period is, and that both the start and end dates are included. task-id: none
Resolved issues and error corrections
The Discuss onboarding tour is now included in the correct application assets instead of being limited to test-only files. This ensures users can see the intended onboarding guidance when using Discuss, improving first-time user orientation.
Original PR description
The discuss onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The German point-of-sale certification modules were updated to use newer browser communication methods instead of an older dependency. This is an internal cleanup that should help maintainability without changing the user experience.
Original PR description
In this pr we refactor the methods that rely on `jquery` in favor of `fetch`.
Miscellaneous changes
Add some ids to avoid xpaths like "//th[3]" etc. task-4250697 Forward-Port-Of: odoo/odoo#183434
Original PR description
Add some ids to avoid xpaths like "//th[3]" etc. task-4250697 Forward-Port-Of: odoo/odoo#183434
The sales order confirmation warning now better explains what to do when an order was created before a warehouse existed. This helps users resolve the issue by assigning the warehouse to the order instead of repeatedly being told to create one.
Original PR description
### Steps to reproduce: - Create a new company - With this new company, create an SO for a storable product - Try to confirm the SO #### > A redirect warning is raised: "Please create a warehouse…
### Steps to reproduce: - Create a new company - With this new company, create an SO for a storable product - Try to confirm the SO #### > A redirect warning is raised: "Please create a warehouse ..." - Go to warehouses and create such a warehouse - Try to confirm the SO once more #### > The same warning is raised: "Please create a warehouse ..." ### Cause of the issue: The redirect warning that asks you to create a warehouse is raised when you try to confirm an SO wihtout a set "warehouse_id": https://github.com/odoo/odoo/blob/114b476755c37ae670f613200ffcc03377258873/addons/sale_stock/models/sale_order.py#L102-L113 https://github.com/odoo/odoo/blob/114b476755c37ae670f613200ffcc03377258873/addons/stock/models/stock_warehouse.py#L166-L172 Since you created the SO before the warehouse, the SO is curently not linked to any warehouse. Furthermove, when you created the warehouse, it did not update the 'warehouse_id' so that the exact same warning will be raised after the warehouse creation. opw-4250791 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website task creation form preview no longer crashes when opened directly without an existing task. This helps website editors test and configure forms more reliably.
Original PR description
Currently, an exception is generated when the user clicks on the preview URL of the "Create a Task" form by following the steps: - Go to any website page and open the website editor - Add form to website page - click on the added form and select Action as "Create a Task" - Click on the Preview URL button of the added form >> errro generated Error `KeyError: 'task'` This is because when the user opens the direct URL, no task is available. This commit will fix the above issue by accessing the key `task` when it is available in view. sentry-5983056185
This update prevents manufacturing report logic from accidentally mixing up an input value while processing operations. It helps keep bill of materials structure reporting consistent and reduces the chance of incorrect results in manufacturing views.
Original PR description
This commit makes sure `operation` parameter is not reused in the `for` loop. 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 an issue where videos used as the cover media in website Card snippets could appear shifted or fail to fill the card correctly when a fixed ratio was applied. Website editors can now replace card cover images with videos and expect the layout to remain consistent.
Original PR description
In the "Card" snippet, if the cover image is replaced by a video, and if it has a ratio (i.e. the "Ratio" option is not set on "Image default"), the video is not placed correctly. This happens because the videos have a rule setting their position to `relative`, overriding the `absolute` position set and needed by the `ratio` class. This commit fixes that by setting the position of card cover videos as `absolute`, to be placed correctly according to the ratio. Steps to reproduce: - Drop a "Card" inner snippet. - Click on the cover image and replace it by a video. => The video is shifted and does not fill the wrapper properly. Related to task-3674888
This fix prevents Odoo from automatically opening a default form view in list screens unless the user is creating a new record or the action explicitly requests it. This avoids confusing navigation in certain list views while preserving the intended behavior for dedicated open-form buttons.
Original PR description
This commit tweaks the behavior of the openFormView function introduced in https://github.com/odoo/odoo/pull/176707 by making it fallback on the default form view only in create mode or when the caller explicitly wants it to (using the force parameter). This solves issues with some list views where we don't want to show the form view on click while keeping the spec intact in case of list's open_form_view button. Task-4164683
This fixes an issue where scrolling an open Gantt popover out of view could trigger an error while it was closing. The change improves stability by ensuring the interface only repositions popovers when the required page elements are still available.
Original PR description
Since [1] have a gantt popover opened and then scroll the popover out: a traceback occur due to the onPositioned callback still called when the popover is being closed. Now usePosition will check if needed elements are connected before the positioning computation. [1]: https://github.com/odoo/enterprise/commit/ebeb633be737eb7bd614c2b474fafd65cd54f0ae
This update corrects a leftover internal reference in the hardware drivers used for customer-facing displays. It helps ensure connected display devices continue to launch and use the browser state correctly after a previous cleanup.
Original PR description
In #183565 the `chromium_additional_args` variable was removed, however a reference to it was missed in `DisplayDriver_L`. This PR fixes this reference by replacing it with `browser.state`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders that open tasks from the Tasks button now show the expected project navigation bar when all tasks belong to the same project. This restores easier navigation for users moving between a sales order, its project, and related tasks, while keeping the previous behavior when tasks span multiple projects.
Original PR description
Steps to reproduce: ------------------- 1. Install Project and Sales app 2. Create an SO which generates a project with tasks on confirmation 3. Confirm the SO 4. From the SO form view, click on the 'Tasks' stat button 5. The top bar is unavailable Fix: ------------------- In the action method, we check if all the tasks linked to the SO are in the same project. If so, we display the top bar by retrieving the right xml_id and passing the active_id of the project in the context. If not (more than one project), we fall back on the current behaviour. task-4239673 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users verifying Indian E-waybill credentials in production will now see a clear validation message when the username or password is incorrect. This prevents a confusing system error and makes it easier to correct setup issues during accounting configuration.
Original PR description
Before this PR, if the E-waybill credentials are wrong, the user gets a traceback in the production environment due to 61a85754800. Instead we introduce a `ValidationError`. Steps to reproduce: - Turn On (✓) "Production Environment" and "Indian Electronic Waybill" from accounting configuration settings. - Click "Verify Username and Password" in "Indian Electronic Waybill".
This fix ensures users can save email templates when using the mass mailing composer. If the composer cannot be saved first, the system now stops and shows the normal validation guidance instead of continuing into a broken template creation flow.
Original PR description
In the new composer design [1] saving a template is done by first saving the composer, then opening the "template creation" view on the same composer. The second step thus requires the composer to be properly saved first. This is easily checked as `Record.save` returns false on failure. In that case we do nothing and let the framework point out why the record could not be saved. [1]: 6c4526ec3b9509e0a6b99503d8d888417b2695e0 task-4246399
Dashboard administrators are now automatically treated as internal users, preventing permission mismatches that could break dashboard-related tests or setup flows. This keeps administrator access consistent and avoids errors caused by dashboard admins being treated like portal users.
Original PR description
With this commit, all Dashboard Admins are also automatically internal users. Steps to reproduce: - install module spreadsheet_dashboard_edition - run test `.test_session_info_with_right` => the test fails because of a combinaision of two factors: - the user is granted the group `group_dashboard_manager` but he is not an internal user (which means he is a portal user) - `_inverse_calendar_res_users_settings` creates `res.users.settings` for portal users (will be fixed independently) and it crashes in the readonly transaction --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Web Studio onboarding tour now appears correctly for users. This helps new or returning users discover Studio features as intended, improving guidance without changing core business workflows.
Original PR description
The studio onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour.
The update fixes an internal Documents test so it handles users who already belong to another company. This helps keep access-rights checks reliable in multi-company setups without changing everyday user behavior.
Original PR description
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company.
This fixes an internal issue that could incorrectly shorten sorting rules used in grouped views and reports. The change helps ensure accounting and document lists are ordered consistently when custom sorting logic is involved.
Original PR description
`_read_group_orderby` used `cr.mogrify`, `split(",")` and `split()[0]` for the
result coming from the `_order_to_sql` which may come from `_field_to_sql`
As a side effect, SQL code after a space/newline not adjacent to a comma will
be dropped after `split()[0]`. So the mogrified customized `_field_to_sql`
shouldn't have any space/newline not adjacent to a comma if the field is used
for `Model._order`.This update corrects how withholding reference information is read in the Indian TDS/TCS reporting module. It helps ensure the report uses the right linked accounting records and avoids errors caused by incomplete field access.
Original PR description
With this PR, field `l10n_in_withholding_ref_move_id` will be accessed with `mapped` from the record set which was missing in the commit https://github.com/odoo/enterprise/commit/69e5817f5c72b75f3879801364ca78c83b522f83
The SEPA direct debit mandate report layout has been adjusted so it prints on a single page. This helps users generate cleaner, more professional documents without awkward page breaks.
Original PR description
Adapt the layout of the account sepa direct debit report to make it fit on a single page. task-4183056
Users who try to validate the same project document twice will now see a clear invalid operation message instead of an unexpected error. This prevents disruption and makes the issue easier to understand and resolve.
Original PR description
Steps to Reproduce: 1. Select a document 2. validate document 3. click on validate again 4. Traceback thrown Technical Reason: Instead of raising a UserError, it throws a ValueError when evaluating directly '_()' in the XML file without using the 'env' context. After this commit: An invalid operation dialog will open with the message 'Impossible to validate twice'. Task-4228827
Manufacturing users can now post work-in-progress accounting entries even when a work order has been started but not yet given an end time. This avoids an unexpected error and helps keep manufacturing accounting actions from being interrupted.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183604 Forward-Port-Of: odoo/odoo#182791
Original PR description
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183604 Forward-Port-Of: odoo/odoo#182791
Issue: ====== Sent emails buttons arent correctly styled. Steps to reproduce the issue: ============================= - Go to email templates - Add primary button - Send a message with the created template - The button isn't correctly rendered Origin of the issue: ==================== The grouped styles like `border`. `padding` and `border-radius` doesn't propagate their values to their substyles when there are variables used in the value. Solution: ========= We handle thos
Original PR description
Issue: ====== Sent emails buttons arent correctly styled. Steps to reproduce the issue: ============================= - Go to email templates - Add primary button - Send a message with the created template - The button isn't correctly rendered Origin of the issue: ==================== The grouped styles like `border`. `padding` and `border-radius` doesn't propagate their values to their substyles when there are variables used in the value. Solution: ========= We handle those cases alone, by reapplying the group style again by using the computed values since they may have some values using var from a parent style opw-4199180 Forward-Port-Of: odoo/odoo#181051
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed th
Original PR description
Purpose ======= When users are editing course content and created multiple sections they are most likely working "chronologically" adding content to sections one after the other. It seems the fix to preselect last section by default when many exist to populate new content is in regression. How to fix ========== Whenever a channel has sections and users has not selected one: make the last section as the default one. task-4109586 see odoo#132934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176618
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order for 10 P > *Mark as Todo* * go to the detailed ops for the move * => it auto suggest the sml: pk1, qty = 10 * set the qty on the generated sml to 3 * *add a line* > pick from *WHStock - pk2*: * => this creates the sml: pk2, qty = 7 * set the new sml's package to pk1
Original PR description
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order…
Steps
---
* install `stock`
* from *Settings* > *Stock* activate packages
* create a product P and put 2 packages (pk1, pk2) of 10 units each
in stock (inventory adjustment)
* create a delivery order for 10 P > *Mark as Todo*
* go to the detailed ops for the move
* => it auto suggest the sml: pk1, qty = 10
* set the qty on the generated sml to 3
* *add a line* > pick from *WHStock - pk2*:
* => this creates the sml: pk2, qty = 7
* set the new sml's package to pk1
* => the *Pick From* field doesn't change
* *save*, the second sml's package has been reset to pk2
Cause
---
In the detailed ops we use a dummy `quant_id` field on sml to allow
selecting a quant and carrying some fields values from it to the sml.
But, when the quant was selected, setting the values of the carried
field, will not affect back the quant. And later, because the quant is
set, we use its values instead of the ones the user specified.
Fix
---
Hide the affected fields in the view, so the user cannot attempt to set
them, which would not work. i.e if they want to set the package id they should
do it via the quant dropdown.
opw-4089523
Forward-Port-Of: odoo/odoo#177260The date was always formatted as `'%m-%d-%y'` which creates confusion for some users. Now we use `format_date` which takes into consideration the language of the user yielding the expected date format. Current behavior before PR: In the quotation page, a downpayment's date is formatted mm/dd/yyyy when the client has the language es_ES. Desired behavior after PR is merged: The downpayment's date should be formatted dd/mm/yyyy following the standard date formatting in Spanish (assuming tha
Original PR description
The date was always formatted as `'%m-%d-%y'` which creates confusion for some users. Now we use `format_date` which takes into consideration the language of the user yielding the expected date format. Current behavior before PR: In the quotation page, a downpayment's date is formatted mm/dd/yyyy when the client has the language es_ES. Desired behavior after PR is merged: The downpayment's date should be formatted dd/mm/yyyy following the standard date formatting in Spanish (assuming that the client's language is Spanish) opw-4197849 Forward-Port-Of: odoo/odoo#182274
Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When
Original PR description
Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When making an edit, studio create an inheriting view that is applied before the x_plan fields are added. => Xpaths do not match Solution ======== When in studio, don't add x_plan_* fields opw-4210657 Forward-Port-Of: odoo/odoo#183658 Forward-Port-Of: odoo/odoo#183509
Before this commit, attempting to delete the only order in the paid order list would result in an error. This was due to the ticket screen setting the current order to `selectedOrder` upon opening. However, when the order was fetched again, it replaced the previous order, leading to not setting 'selectedOrder` to null after deleting. opw-4230543 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183628
Original PR description
Before this commit, attempting to delete the only order in the paid order list would result in an error. This was due to the ticket screen setting the current order to `selectedOrder` upon opening. However, when the order was fetched again, it replaced the previous order, leading to not setting 'selectedOrder` to null after deleting. opw-4230543 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183628
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency.
Original PR description
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183182 Forward-Port-Of: odoo/odoo#182799
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website > Shop > Add a product to cart > View cart - Pay with Demo > Pay - Click the back button - Apply Coupon code Traceback: ``` ValueError: not enough values to unpack (expected 1, got 0) File "odoo/models.py", line 5975, in ensure_one _id, = self._ids ValueError: Expected singleto
Original PR description
When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install ```website_sale_loyalty``` - Activate ```Demo``` payment provider - Go to Website >…
When user tries to apply a discount code in order,
a traceback will appear.
Steps to reproduce the error:
- Install ```website_sale_loyalty```
- Activate ```Demo``` payment provider
- Go to Website > Shop > Add a product to cart > View cart
- Pay with Demo > Pay
- Click the back button
- Apply Coupon code
Traceback:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5975, in ensure_one
_id, = self._ids
ValueError: Expected singleton: sale.order()
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2100, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale_loyalty/controllers/main.py", line 17, in pricelist
coupon_status = order._try_apply_code(promo)
File "addons/sale_loyalty/models/sale_order.py", line 1197, in _try_apply_code
self.ensure_one()
File "odoo/models.py", line 5978, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/9a9063a2d1f385b02f8453b766ec225def531d7e/addons/website_sale_loyalty/controllers/main.py#L16
When user clicks the back button and applies the coupon,
```order``` will be empty, So, it will lead to the above traceback.
sentry-5856780654
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#180450We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKgu
Original PR description
We did not compute fiscal position correctly regarding billing/delivery addresses combinations. Before this commit, we used the delivery to compute the fiscal position, except for invoices with no delivery or in the same country as the company, but it is not sufficient for several use cases. With this commit we check multiple combinations of EU/extra-EU partners with/without VAT. Change has been made regarding this spreadsheet: https://docs.google.com/spreadsheets/d/1PDlXpsgRiGvYvrUKguJqWPVl-g-7H6YqJiWoRNgWCYI/edit?gid=0#gid=0 opw-4072691 Forward-Port-Of: odoo/odoo#182438 Forward-Port-Of: odoo/odoo#178076
labour_credit_line_vals were not properly rounded/summed, and could result in a difference between credit & debit of $0.01.  This happened because the credit value rounded up twice, and instead of having -0.005 + 0.005 => 0, we had -0 + 0.01 => +0.01. The issue could also happen with a cost share, if the workcenter_cost * cost_share = x.xx5. Hence, we needed to refactor how the workcenter_cost is
Original PR description
labour_credit_line_vals were not properly rounded/summed, and could result in a difference between credit & debit of $0.01.  This happened because the credit value rounded up twice, and instead of having -0.005 + 0.005 => 0, we had -0 + 0.01 => +0.01. The issue could also happen with a cost share, if the workcenter_cost * cost_share = x.xx5. Hence, we needed to refactor how the workcenter_cost is computed to ensure that 'Original Credit Value = New Credit Value + Labor Credit Value'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182368
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
Original PR description
Follow up of https://github.com/odoo/odoo/pull/178219 The vies check service may limit ip addresses when: - checking too many vat numbers per day - checking the same vat number multiple times - checking too many invalid number This is to avoid the second case Forward-Port-Of: odoo/odoo#182764
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where
Original PR description
This fix aims to prevent the button_process_edi_web_services function from being executed with multiple records simultaneously. The reason is that calling action_process_edi_web_services with with_commit=False can cause issues if Odoo crashes in the middle of execution (e.g., the document is sent but not updated in Odoo, so when the server restarts, the document is sent again). Although I don't believe anything in Odoo calls this function with multiple records. But we encountered a case where a client had a server action that invoked this function with multiple records at the same tim, and it caused a duplicate document sent. opw-4195392 Forward-Port-Of: odoo/odoo#183060
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
Original PR description
Taxes with the l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and XML file refused. With this commit, the bug is fixed automatically for new users installing the l10n_es_edi_factuare module task-4095945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179638
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
Original PR description
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 Forward-Port-Of: odoo/odoo#165740
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds that tag as well as tweaking the width to not be cutoff on small screens. [FIX] hw_posbox_homepage: show error messages The IoT box returns error messages when connecting to a server fails. The new OWL homepage currently does not show these or any other sign of failure, instead just
Original PR description
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds…
This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds that tag as well as tweaking the width to not be cutoff on small screens. [FIX] hw_posbox_homepage: show error messages The IoT box returns error messages when connecting to a server fails. The new OWL homepage currently does not show these or any other sign of failure, instead just seeming unresponsive. This PR now shows the error messages again, as well as disabling the 'Connect' button while loading. [FIX] hw_posbox_homepage: allow new IoT connection tokens This change backports the URL helpers from 18.0, and modifies the homepage controller to allow the new type of IoT token. The result of this is that IoT boxes on v17 can connect to v18 databases via the token. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183169
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
During this commit: https://github.com/odoo/odoo/pull/126718/commits/00af576ec77e90b6e2e4b398e61b6b5a17f01067 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. task: 4210069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181513
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
Original PR description
The country is a mandatory field on the delivery address. Xpath: cac:Delivery/cac:DeliveryLocation/cac:Address/cac:Country/cbc:IdentificationCode "[BR-57]-Each Deliver to address (BG-15) shall contain a Deliver to country code (BT-80)." opw-4139689 Forward-Port-Of: odoo/odoo#180172
**Issue:** On the main product page of the client’s shop, only the current price is displayed, and the strikethrough price (comparison price) is not shown. This issue arises even when comparison prices are enabled on the website. **Cause:** At first it was decided that the base price should be given priority over compare price and hence if base price was already set, compare price shouldn't be shown. **Fix:** This commit modifies the condition that gives priority to compare price over b
Original PR description
**Issue:** On the main product page of the client’s shop, only the current price is displayed, and the strikethrough price (comparison price) is not shown. This issue arises even when comparison prices are enabled on the website. **Cause:** At first it was decided that the base price should be given priority over compare price and hence if base price was already set, compare price shouldn't be shown. **Fix:** This commit modifies the condition that gives priority to compare price over base price. **Before this commit:** The comparison price was shown in the individual product but wasn't shown on the shop page with all products **After this commit:** The comparison price is shown even for the shop page. **Affected version**: saas-17.4~master **opw**-4191727 Forward-Port-Of: odoo/odoo#181124
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invo
Original PR description
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to…
Issue: The Uso (l10n_mx_edi_usage) field in the Mexican invoice PDF report was displayed in English instead of Spanish (MX), even when the customer's language was set to Spanish(Mx). Step to reproduce the issue: - Go to the Accounting app --› Customer invoices journal --› Create a new invoice. - Select a customer with the Spanish (MX) / Español (MX) language set. - Select any product from the inventory catalog. - Set the Uso (l10n_mx_edi_usage) as "Gastos en general". - Confirm the invoice. - Click on "Send and print" button and mark the CFDI checkbox in the next window, click on send and print button again. - The Uso (l10n_mx_edi_usage) field is being translated into English, despite the language set for the customer is Spanish (MX) / Español (MX). Cause of the issue: The XML template (report_invoice.xml) uses a dynamic value for the Uso field, preventing the standard PO file translations from being applied. A python translation using the _description_selection from Fields with the env language detection method is necessary in the _l10n_mx_edi_get_extra_invoice_report_values method in account_move.py. opw-4212069 Forward-Port-Of: odoo/enterprise#71344
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#71825 Forward-Port-Of: odoo/enterprise#69973
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727 Forward-Port-Of: odoo/enterprise#71825 Forward-Port-Of: odoo/enterprise#69973
### Steps to reproduce the issue: 1. Create a Purchase Order and add Analytic Distribution to one of the Product Lines 2. Make sure the "Budget" Smart Button is visible 3. Create a User with no Accounting access rights and maximum Purchase access rights 4. With Purchase User, open the Purchase Order 5. Receive following Access Error: > You are not allowed to access 'Budget' (budget.analytic) records. > > This operation is allowed for the following groups: > - Accounting
Original PR description
### Steps to reproduce the issue: 1. Create a Purchase Order and add Analytic Distribution to one of the Product Lines 2. Make sure the "Budget" Smart Button is visible 3. Create a User with no…
### Steps to reproduce the issue: 1. Create a Purchase Order and add Analytic Distribution to one of the Product Lines 2. Make sure the "Budget" Smart Button is visible 3. Create a User with no Accounting access rights and maximum Purchase access rights 4. With Purchase User, open the Purchase Order 5. Receive following Access Error: > You are not allowed to access 'Budget' (budget.analytic) records. > > This operation is allowed for the following groups: > - Accounting/Bookkeeper > - Accounting/Read-only ### Explanation: When accessing `purchase.order`, a list of computes starting with `purchase.order._compute_above_budget` will cause the user to perform a `search` on `budget.line`, which he does not have access to without `account.group_account_readonly` or higher. ### Fix reasoning: Since the user will only perform a `search`, `sudo` is all indicated to bypass the Access Rights restriction. opw-4244187 Forward-Port-Of: odoo/enterprise#71576
### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info. ### Steps to reproduce 1. Open runbot install AR and UY modules 2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000 ### Before the PR W
Original PR description
### Description When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the…
### Description
When trying to invoice to a partner that does not have an Uruguayan identification type or do not have a generic identification type we get a traceback, this PR solve it and show the proper error message to the user so he can properly set the partner info.
### Steps to reproduce
1. Open runbot install AR and UY modules
2. In the UY company and invoice a e-ticket to ADHOC SA partner (id CUIT - AR type), total amount should be greater that 30.000
### Before the PR
We receive a traceback error
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1783, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 1810, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 2014, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/addons/base/models/ir_http.py", line 226, in _dispatch
result = endpoint(**request.params)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/http.py", line 759, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 732, in action_send_and_print
return self._process_send_and_print(
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 666, in _process_send_and_print
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/data/build/adhoc-cicd-odoo-odoo/addons/account/wizard/account_move_send.py", line 572, in _generate_invoice_documents
self._hook_invoice_document_before_pdf_report_render(invoice, invoice_data)
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/wizards/account_move_send.py", line 59, in _hook_invoice_document_before_pdf_report_render
if errors := invoice._l10n_uy_edi_check_move():
File "/data/build/adhoc-cicd-odoo-enterprise/l10n_uy_edi/models/account_move.py", line 502, in _l10n_uy_edi_check_move
dtype=self.partner_id.l10n_latam_document_type_id.name))
AttributeError: 'res.partner' object has no attribute 'l10n_latam_document_type_id'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2891:163)
at XMLHttpRequest.<anonymous> (https://80893-17-0-all.runbot.adhoc.com.ar/web/assets/d093fae/web.assets_web.min.js:2895:13)
```
This happens because the document type is related to the invoice, the partner actually has identification type field.
### After the PR
Now it shows the proper message telling the message the problem related to the partner configuration so they can fix it before sending EDI invoice
Reference: LATAM 1275 / ADHOC TICKET 81219
Forward-Port-Of: odoo/enterprise#71416Related to https://github.com/odoo/odoo/pull/182438 Since this fix, we make an extra query per batch, so we need to adapt the query count of `test_recurring_order_creation_perf` opw-4072691 Forward-Port-Of: odoo/enterprise#71903
Original PR description
Related to https://github.com/odoo/odoo/pull/182438 Since this fix, we make an extra query per batch, so we need to adapt the query count of `test_recurring_order_creation_perf` opw-4072691 Forward-Port-Of: odoo/enterprise#71903
Forward-Port-Of: odoo/enterprise#71652
Original PR description
Forward-Port-Of: odoo/enterprise#71652
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
Original PR description
Fixes an issue where the overriden split_uncompleted_moves method did not return its call to super(). Forward-Port-Of: odoo/enterprise#71980
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
Original PR description
Adding some new accounts in the reports task: 4210069 Forward-Port-Of: odoo/enterprise#70710
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71743 Forward-Port-Of: odoo/enterprise#71682
Original PR description
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71743 Forward-Port-Of: odoo/enterprise#71682
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: o
Original PR description
### Steps to reproduce the issue: 1. In Mexican Company, create an Invoice elligible for CFDI 2. Send & Print 3. In the PDF, "Digital stamp of the emitter" and "Digital stamp SAT" are the same ### Explanation: In the xml template, under "Digital stamp of the emitter", the value retrieved is `sello_sat` instead of `sello` ### Fix reasoning: Replacing `sello_sat` with `sello` under "Digital stamp of the emitter" in every template using the values opw-4227743 Forward-Port-Of: odoo/enterprise#71463
Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71859 Forward-Port-Of: odoo/enterprise#71641
Original PR description
Steps: - Install rental app. - Goto rental settings. - Create product from extra fees product Issue: - Consumable type product is creating is should be service product. Cause: - No context to set default values for detailed_type field. Fix: - Added context `default_detailed_type: service` to create service type product. opw-4142551 Forward-Port-Of: odoo/enterprise#71859 Forward-Port-Of: odoo/enterprise#71641
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012
Original PR description
In this PR: - Updated the matching criteria for GSTR2B late bills to use the specific month of the bill date. - Replaced previous date filter on `invoice_date` to limit searches to the start and end of the bill's month. - Ensured accurate retrieval of bills by filtering based on the bill number and company. This change enhances the precision of bill matching in the GSTR2B late bill streamline process. Forward-Port-Of: odoo/enterprise#72012