Wednesday, December 6, 2023
37 changes · 17.0
Enhancements to existing features
Requests for the website robots.txt file no longer trigger a language-based redirect. This removes an unnecessary step for real users and keeps handling of this non-language-specific file consistent with similar website files.
Original PR description
Same as what was done: - in 2019 for favicon.ico at [1]. - in 2018 for sitemap.xml at [2]. - in 2015 for many controllers at [3]. Note that it's not about crawlers/robots, because those won't go through the lang redirect (see `is_a_bot()`). It's just to avoid a redirect which has no meaning/sense when requested by real users. /robots.txt is not language dependent. [1]: https://github.com/odoo/odoo/commit/94bcbc92e5e5a6fd3de7267e3c01f8c11fb045f4 [2]: https://github.com/odoo/odoo/commit/708ad186d52aff9270ea73888326370ada2fbc71 [3]: https://github.com/odoo/odoo/commit/a696913364ffc4d5f1ce0675bc9be82f84f3ff93
This update improves the reliability of payslip form creation by adding a safety check to ensure options are properly validated before use. This prevents errors during testing and makes the payroll system more robust when handling edge cases.
Original PR description
- Verify that options is different to None to avoid errors when trying to get 'toolbar' when creating payslip Form in unit tests.
Resolved issues and error corrections
Homeworking icons now use the calendar’s standard color assignment so colors remain accurate even for employees with large contact IDs. Employees without a linked user now fall back to their work contact, helping homeworking information display reliably.
Original PR description
Since the early versions of the homeworking modules, we were showing incorrect colors for the homeworking icons if the partner_id was too large. This comes from the fact that we were not using the getColor helper from calendar to decide which color to render. Since we have a limited amount of colors, we should not use the partner id to define the color, but actually cycle through all the possible colors, which is done by the getColor method. Also, when getting the homeworking data, it was possible to get partner_id as false when the employee had no related user. This commit also changes this to fallback on the work_contact_id if no user is set. task-3561678 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
Miscellaneous changes
The migration script for taxes was forward-ported without changes from 15.0 to master. However, it should be done differently since saas-16.2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145243
Original PR description
The migration script for taxes was forward-ported without changes from 15.0 to master. However, it should be done differently since saas-16.2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145243
The Chart of Accounts shortcut from the Accounting dashboard now opens account details correctly when users click the View button. This removes a small workflow blocker during accounting setup and account review.
Original PR description
Description of the issue/behavior this commit fixes: When accessing the chart of accounts from the button in the starting banner on the accounting dashboard, the "View" button on the right does nothing while it should open the form view of the account of the row which's button is clicked. --- Steps to reproduce: 1 - Install account_accountant (or else the coa is not reachable from the dash) 2 - Open the Accounting app 3 - Click on "Chart of Accounts" in the onboarding banner 4 - Click on the View button of any row 5 - Nothing happens --- Desired behavior after this commit is merged: This commit adds the form view in the view that is returned when clicking on "Chart of Accounts". Thanks to that, the open_form_view is able to return a form view when the button is clicked. With this commit, the view button is operational. --- task-3624209 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where calendars with back-to-back work periods could cause an error when creating or calculating time off. This makes work duration and leave handling more reliable for employees using schedules split into adjacent shifts.
Original PR description
### Issue : When calling get_work_duration_data on a calendar that contains adjacent calendar attendances, we get a traceback in the method `_get_attendance_intervals_days_data.` This is due to the fact that adjacent attendances (like 09:00 -> 13:00, 13:00 -> 17:00) will get merged into one single interval. Which will generate an attendance interval with multiple `resource.calendar.attendance` records associated with it. ### Steps to reproduce : 1) Create a Calendar 2) Create for a same day 2 attendances going from 09:00 to 13:00 and another going from 13:00 to 17:00 3) Try creating a time-off for that day 3) Associate that calendar with an employee 4) Try creating a time off on the day where we have adjacent attendances ### Fix: Adapt `_get_attendance_intervals_days_data` to handle attendance intervals associated with multiple resource.calendar.attendance task-3615723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the Lithuanian accounting setup so account numbers can use the expected six digits instead of being limited to one. Businesses using the Lithuanian chart of accounts will get more accurate default account formatting during setup.
Original PR description
The digits of the accounts of Lithuania's COA go up to 6. It's currently defined to 1, which makes no sense. We will change it to 6. 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 fix ensures the website editor finishes loading its hidden editing frame properly after content is written. As a result, import or loading errors are shown to users instead of failing silently, while tooltip handling is simplified to match the current editor behavior.
Original PR description
[FIX] web_editor: close iframe document after write [FIX] web_editor: remove observerUnactive before adding tooltip task-3537756 This PR is the 17.0+ version of https://github.com/odoo/odoo/pull/138039. While the changes are essentially the same, the motivation (commit messages) changed, due to the fact that, in 17.0: - the use of Bootstrap tooltip.js was replaced by web/'s own Tooltip component - the module loader error report relies on the same `document.readyState` to be "complete" (or the "DOMContentLoaded" event) in order to display the error message.
This update fixes the visual appearance of status buttons in the Planning and MRP PLM modules to ensure consistent font sizing across the application. The buttons now display with the same formatting regardless of how they are generated, improving the overall user interface consistency and professional appearance.
Original PR description
The structure of the stat button which is not generated by a field has been changed to match the buttons which are generated by a field. | Before | After | |--------|--------| |  | | Community PR: https://github.com/odoo/odoo/pull/141163 task-3573807
When canceling an asset, the system was displaying HTML line break tags as plain text instead of rendering them properly. This fix ensures that cancellation messages display correctly with proper formatting, making them easier to read in the activity log.
Original PR description
To reproduce: - Create an asset last month, with duration monthly - Confirm it, then cancel it => The message in the chatter contains the \<br> in plain text. Following ac0bfab08e1c7e14c815cb33ed2a5c081668b0f8, we should Markup to render html Forward-Port-Of: odoo/enterprise#51032
At Odoo, we want custom models and fields to start with `x_`. However, other developers and companies might want to customize that behavior and be able to change the rule. This revision targets to factorize the rule `startswith('x_')` in a dedicated method on `ir.model` and `ir.model.fields` so they can be overridden to allow the customization of custom model and fields name in custom modules. Forward-Port-Of: odoo/odoo#145154
Original PR description
At Odoo, we want custom models and fields to start with `x_`. However, other developers and companies might want to customize that behavior and be able to change the rule.
This revision targets to factorize the rule `startswith('x_')` in a dedicated method on `ir.model` and `ir.model.fields` so they can be overridden to allow the customization of custom model and fields name in custom modules.
Forward-Port-Of: odoo/odoo#145154When the user creates a new customer and enters "." in Identification Number, a traceback will appear. Steps to reproduce the error: - Install "l10n_cl" module - Switch to Chile Company - Go to Invoicing > Customers > Create New Customer > Enter Name > Select 'Chile' in Country > Enter "." in Identification Number > Save Traceback: ``` IndexError: string index out of range File "odoo/http.py", line 2139, in __call__ response = request._serve_db() File "odoo/http.py", li
Original PR description
When the user creates a new customer and enters "." in Identification Number, a traceback will appear. Steps to reproduce the error: - Install "l10n_cl" module - Switch to Chile Company - Go to…
When the user creates a new customer and enters "." in Identification Number,
a traceback will appear.
Steps to reproduce the error:
- Install "l10n_cl" module
- Switch to Chile Company
- Go to Invoicing > Customers > Create New Customer > Enter Name >
Select 'Chile' in Country > Enter "." in Identification Number > Save
Traceback:
```
IndexError: string index out of range
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 464, in call_kw
result = _call_kw_model_create(method, model, args, kwargs)
File "odoo/api.py", line 444, in _call_kw_model_create
result = method(recs, *args, **kwargs)
File "<decorator-gen-490>", line 2, in create
File "odoo/api.py", line 414, in _model_create_multi
return create(self, [arg])
File "addons/l10n_cl/models/res_partner.py", line 55, in create
vals['vat'] = self._format_vat_cl(vals)
File "addons/l10n_cl/models/res_partner.py", line 41, in _format_vat_cl
return stdnum.util.get_cc_module('cl', 'vat').format(values['vat']).replace('.', '').replace(
File "stdnum/cl/rut.py", line 90, in format
number[-4:-1] + '-' + number[-1])
```
code reference:
https://github.com/odoo/odoo/blob/276972f96d2eb1a65686e7319f601ed435b57b88/addons/l10n_cl/models/res_partner.py#L40
Here, when user enters "." in Identification Number
then values['vat'] will be ".",
So when it will try to .format(),
It will lead to above traceback.
sentry-4593791704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#140862Create a vendor bill Input any value in the "payment reference field" > save Payment line name will be set to the payment reference Remove the value > save Issue: Payment line name will be unchanged Register payment In the payment wizard, the "memo" field will be filled with the old payment reference. opw-3596003 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
Original PR description
Create a vendor bill Input any value in the "payment reference field" > save Payment line name will be set to the payment reference Remove the value > save Issue: Payment line name will be unchanged Register payment In the payment wizard, the "memo" field will be filled with the old payment reference. opw-3596003 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#145054 Forward-Port-Of: odoo/odoo#143511
Context: When an HTTPS certificate is delivered, it is valid for ~1 month. To avoid missing the certificate, a script is automatically ran daily to check if a new HTTPS certificate is necessary. On the IoT box, it is added in the native Unix system with this file: https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/tools/posbox/overwrite_after_init/etc/cron.daily/odoo However, prior to this commit, there is nothing equivalent for windows Note: the HTTPS certificate check is als
Original PR description
Context: When an HTTPS certificate is delivered, it is valid for ~1 month. To avoid missing the certificate, a script is automatically ran daily to check if a new HTTPS certificate is necessary. On…
Context: When an HTTPS certificate is delivered, it is valid for ~1 month. To avoid missing the certificate, a script is automatically ran daily to check if a new HTTPS certificate is necessary. On the IoT box, it is added in the native Unix system with this file: https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/tools/posbox/overwrite_after_init/etc/cron.daily/odoo However, prior to this commit, there is nothing equivalent for windows Note: the HTTPS certificate check is also done automatically when accessing the homepage. Before this commit: After an HTTPS certificate delivery, if we let the IoT server running non-stop (and without accessing the homepage). The HTTPS will expire without any automatic renew. After this commit: A "Cron Handler" have been introduced in order to manage time related actions. For now, only some actions that have to be executed daily is implemented. Other note: - Using native Windows "Scheduled Task" have been proposed at: https://github.com/odoo/odoo/pull/144584 But, was judged too risky from a security point of view - `sched` library have been chosen as it is native in python (since 2.6). Other non-native libraries might be better, but should be considered in master for stability - `sched` default way of working is using `time.sleep`, so we basically wait for 24 hours in the handler thread. If it is an issue, we might be able to have something similar using thread.Timer: https://docs.python.org/3/library/threading.html#timer-objects but I think it will consume more resources for no real benefit: https://stackoverflow.com/questions/13261593/resource-usage-of-time-sleep-in-loop-vs-threading-timer opw-3617687 Forward-Port-Of: odoo/odoo#144652
saas-16.3 Steps To reproduce: - install project, sales, and timesheets - open the project module and select any project created from SO - click on any task - click on the Sales Order smart button - to set the end date hover beside the start date Issue: - end date should not be optional to select. Cause: - the unification of datetime, daterange, and date happened in task 3121497 where daterange widget has the end date by default optional. Solution: - I have added attr
Original PR description
saas-16.3 Steps To reproduce: - install project, sales, and timesheets - open the project module and select any project created from SO - click on any task - click on the Sales Order smart button - to set the end date hover beside the start date Issue: - end date should not be optional to select. Cause: - the unification of datetime, daterange, and date happened in task 3121497 where daterange widget has the end date by default optional. Solution: - I have added attrs and Timesheets Period label to have the same behavior as it was in saas-16.2. task-3506482 Forward-Port-Of: odoo/odoo#140874
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Expense Report'. --- **Issue:** - When viewing the department's expense in the employee module, all data of state wiith submit and approved is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request inf
Original PR description
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Expense Report'. --- **Issue:** - When viewing the department's expense in the employee module, all data of state wiith submit and approved is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/odoo#138993
Back-port changes done in recent versions. Also run can be async but it's not actually awaited, so an extra_trigger is necessary for proper waiting. runbot-45508 Forward-Port-Of: odoo/odoo#145219 Forward-Port-Of: odoo/odoo#145051
Original PR description
Back-port changes done in recent versions.
Also run can be async but it's not actually awaited, so an extra_trigger is necessary for proper waiting.
runbot-45508
Forward-Port-Of: odoo/odoo#145219
Forward-Port-Of: odoo/odoo#145051### Steps to reproduce: 1. install Employee app 2. install HR Gamification module (not an app) 3. Go to Employees app 4. Go to Configuration > Challenges > Challenges 5. Create a new challenge with goals and participants 6. Go to Configuration > Challenges > Goals History 7. Open up a group 8. The word "Completeness" and the progress bar is not aligned correctly, the bar is supposed to be directly underneath the label. ### Investigation - The styling of the progress bar inside tabl
Original PR description
### Steps to reproduce: 1. install Employee app 2. install HR Gamification module (not an app) 3. Go to Employees app 4. Go to Configuration > Challenges > Challenges 5. Create a new challenge with goals and participants 6. Go to Configuration > Challenges > Goals History 7. Open up a group 8. The word "Completeness" and the progress bar is not aligned correctly, the bar is supposed to be directly underneath the label. ### Investigation - The styling of the progress bar inside table cells https://github.com/odoo/odoo/blob/1f12670a8061a4eb3fd57abca238d8daf7ef574d/addons/web/static/src/views/fields/progress_bar/progress_bar_field.scss#L27-L32 was missing to align the progress bar to the end of the containing flex box opw-3599052 Forward-Port-Of: odoo/odoo#145102 Forward-Port-Of: odoo/odoo#143290
- Set up an MX company - Activate the QR for invoicing by going to POS > Settings > Use the QR code on the ticket - Create a sale with the QR code. - Scan the QR code, fill invoice data, generate the invoice Issue: invoice is not signed Backport of e433414cddd34925e916292b355b5e0ac47e5346 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
Original PR description
- Set up an MX company - Activate the QR for invoicing by going to POS > Settings > Use the QR code on the ticket - Create a sale with the QR code. - Scan the QR code, fill invoice data, generate the invoice Issue: invoice is not signed Backport of e433414cddd34925e916292b355b5e0ac47e5346 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#145024
This commit replaces `nl_NL` by the fake language `pa_GB` in the `test_html_editor_language` test so that it does not have to load an existing language's translation resource bundle. opw-3493355 Forward-Port-Of: odoo/odoo#144948
Original PR description
This commit replaces `nl_NL` by the fake language `pa_GB` in the `test_html_editor_language` test so that it does not have to load an existing language's translation resource bundle. opw-3493355 Forward-Port-Of: odoo/odoo#144948
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference, triggering lots of unwanted spam for attendees on Microsoft side when it shouldn't happen. Additionaly, when restarting the synchronization with Microsoft, the setting parameter `range_days` was being used to update all events in Odoo with `{'need_sync_m': True}`, which also triggered updates in old even
Original PR description
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference,…
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference, triggering lots of unwanted spam for attendees on Microsoft side when it shouldn't happen. Additionaly, when restarting the synchronization with Microsoft, the setting parameter `range_days` was being used to update all events in Odoo with `{'need_sync_m': True}`, which also triggered updates in old events and future events on Microsoft side. If `range_days` was too big, lots of events were 'updated' and triggered spam, and if it was too small, only events within the `range_days` range were synchronized with Outlook.
After this commit, using system parameters, old events in Odoo which update time difference between Microsoft and Odoo is too small are not updated in Odoo anymore, thus not triggering unwanted spam for attendees in these situations. Also, one system parameter `lower_bound_range` was added to be used for selecting the range of old events in Odoo that will be synchronized (and send emails).
Task-id: 3601306
Forward-Port-Of: odoo/odoo#142521Purpose ======= If we buy a course without being logged in, we are redirected to a page with a button "Start Learning". That button redirects to the course we just purchased. Instead, we want to redirect the user to the login page, and after he login to the course page. Task-3544591 Forward-Port-Of: odoo/odoo#138377
Original PR description
Purpose ======= If we buy a course without being logged in, we are redirected to a page with a button "Start Learning". That button redirects to the course we just purchased. Instead, we want to redirect the user to the login page, and after he login to the course page. Task-3544591 Forward-Port-Of: odoo/odoo#138377
Before this commit, to be sure to wait for all the RPC are finished before continue, the clickbot, patched the ORM class and saved in a waiting list the model and method called, and removed when finished. The issue with this, is that when calling an ORM with a protected RPC service (as is the case for the BatcherORM), if the caller component is destroyed before the return of the RPC, as the RPC service is protected it will return an always pending promise, and the RPC will never be remo
Original PR description
Before this commit, to be sure to wait for all the RPC are finished before continue, the clickbot, patched the ORM class and saved in a waiting list the model and method called, and removed when finished. The issue with this, is that when calling an ORM with a protected RPC service (as is the case for the BatcherORM), if the caller component is destroyed before the return of the RPC, as the RPC service is protected it will return an always pending promise, and the RPC will never be removed from the waiting list and the clickbot will wait indefinitely. Now, we use the RPC event directly, so even if the component is destroyed, we know that the RPC was finished, and is removed from the waiting list. Note that, this commit doesn't have a test, making a test for this case is quite difficult, and some of the causes of the issue will be removed in future versions. Forward-Port-Of: odoo/odoo#144788
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his address, `payment_term_id` is set to `partner_id.property_payment_term_id` because [onchange_partner_id][2] is triggered. This means that `payment_term_id` is computed differently if the user edits his address before confirming the order or not. (Resulting in it being `False` most of the time).
Original PR description
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his…
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his address, `payment_term_id` is set to `partner_id.property_payment_term_id` because [onchange_partner_id][2] is triggered. This means that `payment_term_id` is computed differently if the user edits his address before confirming the order or not. (Resulting in it being `False` most of the time). __Description of the fix:__ Inherit [onchange_partner_id][2] to set `payment_term_id` using [sale_get_payment_term][1] from the **website_sale** module. __Steps to reproduce the issue on runbot:__ - Add a product to the cart through the website. → A new sale order will be created with payment terms set. - Proceed to checkout and edit the address on the website → The sale order payment terms will be removed opw-3492868 [1]: https://github.com/odoo/odoo/blob/96b0939554101be2e93d88787d3978929b23e67c/addons/website_sale/models/website.py#L202 [2]: https://github.com/odoo/odoo/blob/96b0939554101be2e93d88787d3978929b23e67c/addons/sale/models/sale.py#L413 Forward-Port-Of: odoo/odoo#144339 Forward-Port-Of: odoo/odoo#136311
# Issue: The name_search performance was highly inefficient with a high number of records. # Analyze: The bottleneck came from the NOT IN search on the product_template. # Fix: As a NOT IN is not efficient, an not exists must be used. # Note: The ORM has to be bypassed has no "not exists" feature has been implemented yet. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 182386 | 15+ min | ~100
Original PR description
# Issue: The name_search performance was highly inefficient with a high number of records. # Analyze: The bottleneck came from the NOT IN search on the product_template. # Fix: As a NOT IN is not efficient, an not exists must be used. # Note: The ORM has to be bypassed has no "not exists" feature has been implemented yet. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 182386 | 15+ min | ~100 ms | | 29 | ~29 ms | ~28 ms | # Related task: opw-3554133 Forward-Port-Of: odoo/odoo#145004 Forward-Port-Of: odoo/odoo#143543
Issue: ====== When we use the website in a language different the the partner lang , it will always display `Free product` in the partner language. Steps to reproduce: =================== - Create a loyalty program that gives a free product - Install another lang (FR for example) apply it for website too - Go to website and change lang to FR - Added the product which gives the free product promotion - Go to cart Origin of the issue: ==================== The lang was forced as pa
Original PR description
Issue: ====== When we use the website in a language different the the partner lang , it will always display `Free product` in the partner language. Steps to reproduce: =================== - Create a loyalty program that gives a free product - Install another lang (FR for example) apply it for website too - Go to website and change lang to FR - Added the product which gives the free product promotion - Go to cart Origin of the issue: ==================== The lang was forced as partner language in displaying the free product name. Solution: ========= For frontend request related to ecommerce orders, keep the request lang to have the cart content in the website language, not in the partner one. opw-3593505 Forward-Port-Of: odoo/odoo#143364
On a company with branches, you can move an amount from a branch company account to a parent company account using "Move to Account" action. This will create a new entry with both accounts. If this entry is created on the parent company, it will trigger an error since parent company does not have access to branch company accounts. Steps to reproduce - Have a company with a branch company - Create an account belonging to the branch company - Create an entry with this account - Select paren
Original PR description
On a company with branches, you can move an amount from a branch company account to a parent company account using "Move to Account" action. This will create a new entry with both accounts. If this entry is created on the parent company, it will trigger an error since parent company does not have access to branch company accounts. Steps to reproduce - Have a company with a branch company - Create an account belonging to the branch company - Create an entry with this account - Select parent company and go to journal item list - Select one item with the account created above and use the action "Move to Account" - Try to move to an account of parent company => Company access error Now we create the entry on the lowest child company. opw-3554088 Forward-Port-Of: odoo/odoo#144508
Steps: - Open Appraisals - Go to Skills - Add new skill - Progress-bar was left-aligned in both rtl and ltr mode Issue: - progress-bar should always aligned to the right (it should be to the left only in rtl mode) in list view.In rtl mode, white space coming before progress-bar. Cause: - the progress bar alignment was inconsistent, especially when dealing with RTL languages . Fix: - By justifying the content of progress-bar to flex-end and of rtl mode to flex-start and by alignin
Original PR description
Steps: - Open Appraisals - Go to Skills - Add new skill - Progress-bar was left-aligned in both rtl and ltr mode Issue: - progress-bar should always aligned to the right (it should be to the left only in rtl mode) in list view.In rtl mode, white space coming before progress-bar. Cause: - the progress bar alignment was inconsistent, especially when dealing with RTL languages . Fix: - By justifying the content of progress-bar to flex-end and of rtl mode to flex-start and by aligning the progressbar-cell to start. Task: 3470978 Forward-Port-Of: odoo/odoo#134109
To reproduce ============ on time Off -> allocations, open a record and try to open studio -> Owl Traceback Problem ======= the ButtonBox is not well compiled, we check if it has children using `!el.childNodes.length`, but this property returns the total number of child nodes, including text nodes ... So counting text nodes, we proceed to create ButtonBox node and fill it with children `for (const child of el.children)`, but the property `el.children` doesn't take into account text nodes
Original PR description
To reproduce ============ on time Off -> allocations, open a record and try to open studio -> Owl Traceback Problem ======= the ButtonBox is not well compiled, we check if it has children using `!el.childNodes.length`, but this property returns the total number of child nodes, including text nodes ... So counting text nodes, we proceed to create ButtonBox node and fill it with children `for (const child of el.children)`, but the property `el.children` doesn't take into account text nodes, which leads to return `''` then a null object Solution ======== as we loop on `el.children` the check must be done using the same property. opw-3603952 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143804
This traceback arises when the user tries to post multiple expense sheets of different employees. To reproduce this issue: 1) Install `hr_expense` 2) Open `Expenses/Expense Reports` 3) Select multiple expense sheets of different employees in list view 4) Make sure the selected recordsets status is `Approved` 5) Now click on the `Posted Entries` button Error:- ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5457, in ensure_one _id, = s
Original PR description
This traceback arises when the user tries to post multiple expense sheets of different employees. To reproduce this issue: 1) Install `hr_expense` 2) Open `Expenses/Expense Reports` 3) Select…
This traceback arises when the user tries to post multiple expense sheets of different employees.
To reproduce this issue:
1) Install `hr_expense`
2) Open `Expenses/Expense Reports`
3) Select multiple expense sheets of different employees in list view
4) Make sure the selected recordsets status is `Approved`
5) Now click on the `Posted Entries` button
Error:-
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5457, in ensure_one
_id, = self._ids
ValueError: Expected singleton: hr.employee(10, 7, 15, 11, 6, 17, 13, 4)
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/saas-16.4/hr_expense_extract/models/hr_expense.py", line 224, in action_sheet_move_create
return super().action_sheet_move_create()
File "addons/hr_expense/models/hr_expense.py", line 1387, in action_sheet_move_create
self._check_can_create_move()
File "addons/hr_expense/models/hr_expense.py", line 1474, in _check_can_create_move
if not self.employee_id.work_email:
File "odoo/fields.py", line 1153, in __get__
record.ensure_one()
File "odoo/models.py", line 5460, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/655c408d319a14cc9b972d4f49816c91fb502b22/addons/hr_expense/models/hr_expense.py#L1474-L1475
After applying this commit will resolve the issue by looping the recordset.
sentry-4595012933
Forward-Port-Of: odoo/odoo#140906To make the module more accessible in its target country, add translations to the module. This mostly concerns error messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144942
Original PR description
To make the module more accessible in its target country, add translations to the module. This mostly concerns error messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144942
-According VietNam Circular , Receivable account we should use for POS is 131 account, not 132 see https://thuvienphapluat.vn/van-ban/Doanh-nghiep/Thong-tu-200-2014-TT-BTC-huong-dan-Che-do-ke-toan-Doanh-nghiep-263599.aspx , select English version - Section 'Short-term receivables from customers' to read it and we will see 132 account is not appropriate  --- I confirm I have signed the CLA a
Original PR description
-According VietNam Circular , Receivable account we should use for POS is 131 account, not 132 see https://thuvienphapluat.vn/van-ban/Doanh-nghiep/Thong-tu-200-2014-TT-BTC-huong-dan-Che-do-ke-toan-Doanh-nghiep-263599.aspx , select English version - Section 'Short-term receivables from customers' to read it and we will see 132 account is not appropriate  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144974 Forward-Port-Of: odoo/odoo#144115
Current distribution of taxes is not correct - 461411 is a current liability account (expressing VAT due) - 421611 is a current asset account (expressing VAT deductible) Example distribution as it is: - grid 459 expresses VAT deductible - grid 712 expresses VAT due Hence, the current configuration of all IntraCom taxes is inconsistent. Essentially, the taxes need to be swapped between these accounts. task-3619708 --- I confirm I have signed the CLA and read the PR guideli
Original PR description
Current distribution of taxes is not correct - 461411 is a current liability account (expressing VAT due) - 421611 is a current asset account (expressing VAT deductible) Example distribution as it is: - grid 459 expresses VAT deductible - grid 712 expresses VAT due Hence, the current configuration of all IntraCom taxes is inconsistent. Essentially, the taxes need to be swapped between these accounts. task-3619708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144913 Forward-Port-Of: odoo/odoo#144610
Somehow the module disappeared from the file between versions 16.0 and saas-16.1 even though the .po files exist (up to + including saas-16.2). Further investigation/fixing will occur later on to check overall consistency correctly, this commit is only a quick fix to get the translations working properly for this specific module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144850 Forward-Port-Of: odoo/odoo#14442
Original PR description
Somehow the module disappeared from the file between versions 16.0 and saas-16.1 even though the .po files exist (up to + including saas-16.2). Further investigation/fixing will occur later on to check overall consistency correctly, this commit is only a quick fix to get the translations working properly for this specific module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144850 Forward-Port-Of: odoo/odoo#144420
The payment method line set on the expense sheet isn't the one used on the payment. The 'print check' payment method test, requiring the 'account_check_printing' installation and that module not being in hr_expense dependencies would fail if both weren't installed. A new and more method-agnostic test replaces it Task-3498991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144909 Forward-Port-Of: odoo/odoo#1419
Original PR description
The payment method line set on the expense sheet isn't the one used on the payment. The 'print check' payment method test, requiring the 'account_check_printing' installation and that module not being in hr_expense dependencies would fail if both weren't installed. A new and more method-agnostic test replaces it Task-3498991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144909 Forward-Port-Of: odoo/odoo#141946
- Set up an MX company - Activate the QR for invoicing by going to POS > Settings > Use the QR code on the ticket - Create a sale with the QR code. - Scan the QR code, fill invoice data, generate the invoice Issue: invoice is not signed Backporting 4d4094a81d50b015805e4aa0c01a5ad2e326c499 for saas-16.4 opw-3591773 Forward-Port-Of: odoo/enterprise#52166
Original PR description
- Set up an MX company - Activate the QR for invoicing by going to POS > Settings > Use the QR code on the ticket - Create a sale with the QR code. - Scan the QR code, fill invoice data, generate the invoice Issue: invoice is not signed Backporting 4d4094a81d50b015805e4aa0c01a5ad2e326c499 for saas-16.4 opw-3591773 Forward-Port-Of: odoo/enterprise#52166