Tuesday, January 30, 2024
54 changes · master
New functionality added to Odoo
This update adds a more visible flow that encourages users to install Odoo as an app from the user menu. It can make Odoo easier to access on supported devices, improving convenience for frequent users.
Enhancements to existing features
Indian invoice reports now include an HSN summary showing tax rates and amounts grouped by HSN code. This helps businesses review GST details more clearly on invoices and supports reuse of the underlying tax calculation logic across related reporting needs.
Original PR description
In this PR
------------
- #### [REF] l10n_in*: move l10n_in gst tax query to `odoo/addons/l10n_in/account_move_line.py`
Before this commit:
The gst tax detail query which computes
the CGST, SGST, IGST and CESS for each
account move line was only used
for l10n_in_reports_gstr module
After this commit:
The gst tax detail query has now moved to
`odoo/addons/l10n_in/account_move_line.py`,
after which the query is now reusable,
and can be used for multiple purposes
task-3196107,3539187
- #### [IMP] l10n_in: add hsn summary in invoice report
Added HSN summary for showing taxes rate and amount according to the HSN
task-3196107
Related PR- https://github.com/odoo/enterprise/pull/53775
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prResolved issues and error corrections
Opening a live chat after the first message no longer sends an unnecessary background request to the server. This reduces needless processing and helps keep the chat experience clean without changing what users see.
Original PR description
Since [1], sending the first message in a live chat triggers a `/channel/fold` request. This route is only called when the user is known which was not the case before [1]. This occurs because the live chat service calls `chatWindowService.open` manually while this method should only be triggered by a user action. The state of the thread will automatically open its chat window without notifying the server. This PR removes the call to `chatWindowService.open` thus preventing this request to be made. [1]: https://github.com/odoo/odoo/pull/149712
Code cleanup and technical improvements
This update modernizes internal tests for web module dependencies by moving them to the newer testing framework. It helps maintain product quality and makes future web changes easier to validate, with no direct change expected for end users.
Original PR description
task 3705027 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
When changing the GST treatment on customers, update draft invoices task-3339052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151503
Original PR description
When changing the GST treatment on customers, update draft invoices task-3339052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151503
Work locations in the homeworking calendar are now shown outside the calendar event, in the same area as the add-location action. This improves spacing and makes location information easier to read without cluttering calendar entries.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now archive records from the three-dot menu on Kanban cards, making record management faster from visual workflows. In Recruitment, archiving an applicant from the Kanban view now follows the expected confirmation flow instead of incorrectly asking for a refusal reason.
Original PR description
[FIX] hr_recruitment : fix archive record on kanban view
STEP TO REPRODUCE :
1. Go on Recruitment application
2. Click on job position with applicants
3. Click on a 3dot of one card
4. Select "Archive"
5. Ask for a refuse reason (expected behaviour : "ask to the user if he really want to archive this record" )
task : 3621561
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis updates Odoo's spreadsheet component to a newer version, bringing several bug fixes and usability improvements. Users benefit from more reliable sheet renaming, search, formula handling, XLSX import/export behavior, and new spreadsheet options such as checkboxes, dropdowns, and scatter charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/03c13350d [REL] 17.2.0-alpha.2 https://github.com/odoo/o-spreadsheet/commit/410cb3a70 [IMP] index: export types Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/03c13350d [REL] 17.2.0-alpha.2 https://github.com/odoo/o-spreadsheet/commit/410cb3a70 [IMP] index: export types Task: 3705469 https://github.com/odoo/o-spreadsheet/commit/53456ad9b [FIX] BottomBarSheet: renaming a sheet with styled content https://github.com/odoo/o-spreadsheet/commit/c96021f14 [FIX] evaluation: behavior for invalid range arguments https://github.com/odoo/o-spreadsheet/commit/c2db5679d [FIX] SelectionInput: Allow commands that target non focused input Task: 3689504 https://github.com/odoo/o-spreadsheet/commit/d28fd3bc1 [FIX] evaluation: allow empty error message Task: / https://github.com/odoo/o-spreadsheet/commit/6fb856f5e [IMP] xlsx: import and export header groups Task: 3637643 https://github.com/odoo/o-spreadsheet/commit/07b7f2da5 [IMP] xlsx export: don't export default row size Task: 3637643 https://github.com/odoo/o-spreadsheet/commit/c84320336 [FIX] Edition: filter invalid references from edition highlights Task: 3378775 https://github.com/odoo/o-spreadsheet/commit/312ec8868 [IMP] config: Add favicon https://github.com/odoo/o-spreadsheet/commit/165da2201 [FIX] Find&Replace: always recompute search on sheet change Task: 3635912 https://github.com/odoo/o-spreadsheet/commit/901b85a50 [IMP] topbar: allow to insert checkbox and dropdown in a cell Task: 3175856 https://github.com/odoo/o-spreadsheet/commit/c4c9f9a71 [FIX] Composer: double click on composer gives traceback https://github.com/odoo/o-spreadsheet/commit/f8d2345e5 [IMP] index: export chart and side panels building blocks https://github.com/odoo/o-spreadsheet/commit/cc8dde40f [FIX] demo: wrong App.mount arguments https://github.com/odoo/o-spreadsheet/commit/bd9faf534 [FIX] tests: fix props validation https://github.com/odoo/o-spreadsheet/commit/6a4489d92 [FIX] icon: broken path for HIDE_COL icon https://github.com/odoo/o-spreadsheet/commit/cc1e28e22 [IMP] github: add templates https://github.com/odoo/o-spreadsheet/commit/2ddfadce0 [FIX] format: fix chaining of FORMAT.LARGE.NUMBER Task: 3633947 https://github.com/odoo/o-spreadsheet/commit/1d756abc5 [IMP] charts: add scatter chart Task: 3623608 https://github.com/odoo/o-spreadsheet/commit/c9922bc71 [FIX] components: useless static components
This update simplifies how list views decide whether records can be selected. It is an internal cleanup that should make the code easier to maintain without changing day-to-day user behavior.
Original PR description
Since `canSelectRecord` getter is cached inside the t-set at the start of the template, it is actually not useful to have it has a getter. This PR move it to the component setup and rename it `selectionEnabled`.
The discard button in forms now uses a cross icon instead of an undo icon and clarifies that it discards all changes. This reduces confusion for users who expect undo to reverse only the most recent action in editing tools.
Original PR description
<h3>Current behavior before PR:</h3> - `undo` (fa-undo) button was used globally to discard all changes - It leads to confusion as `undo` is used to revert to their last change in `web_editor` and `mass_mailing`. <h3>Desired behavior after the PR is merged:</h3> - Display the `cross` (fa-times) button instead of (fa-undo) and changed the tooltip from `Discard changes` to `Discard all changes`. Task-3688337
The web module's internal tests for name-related services were moved to a newer testing framework. This improves maintainability and reliability of future development without changing the user-facing product experience.
Original PR description
task-id: 3705027
The live chat chatbot now relies more directly on shared server-side conversation records instead of separate browser-side state. This should make chatbot behavior more consistent, reduce maintenance complexity, and support future improvements to live chat and discussion features.
Original PR description
This PR converts the chatbot classes to mail records. This will bring the chatbot code closer from the discuss one and allow further simplifications. Unlike [1], this change allows to rely on the server state instead of the local one: - Local state is hard to maintain - Local state is possibly outdated - Local state leads to highly specific code instead of relying on discuss mechanisms. [1]: https://github.com/odoo/odoo/pull/142155
Users importing FEC, SAF-T, or Winbooks files now see a summary of the records created, such as accounts, journals, entries, partners, and taxes. Each summary line links directly to the relevant list, making it easier to review imported data and confirm the import result.
Original PR description
*: account_saft_import, account_winbooks_import, l10n_fr_fec_import When a user imports data from a FEC, SAF-T, or Winbooks file, they don't have any feedback on what was imported. This task adds an improvement where an import summary view will be displayed, showing user a small summary, for example: ``` 4 accounts imported 2 journals imported 3 moves imported 2 partners imported 3 taxes imported ``` Where each line is a link to the list view of the selected imported data task-id: 3649778
This change adjusts an internal performance test to match the current behavior of the enterprise Discuss feature. It helps keep automated checks accurate and avoids false alarms during development, with no expected impact for end users.
Original PR description
It appears there is currently no extra query in enterprise. https://github.com/odoo/odoo/pull/151760
Users can now choose whether the ageing report is calculated from invoice dates or due dates. This gives finance teams more flexibility to analyze outstanding amounts in the way that best matches their reporting needs.
Original PR description
This PR enhances the ageing report's functionality, allowing users to choose between ageing based on either Invoice Date or Due Date. The addition of this feature enhances the usability and customization options for users. Task-3502555
The appraisal list view now includes feedback request information, giving users a more complete overview without opening each appraisal. This helps managers and HR teams quickly see appraisal context and follow-up needs from the main list.
Original PR description
To have all information in the tree view and thus having a better overview of the appraisals, the feedback requests is added in the tree view. task-3575633
The Indian GSTR-1 base report now shows GSTIN, CGST, SGST, IGST, CESS, and total amounts directly on move lines, giving finance teams clearer tax details in the report. The underlying GST tax calculation logic was also made reusable for related Indian reporting needs.
Original PR description
In this PR ------------- - #### [REF] l10n_in_reports*: move l10n_in gst tax query to odoo/addons/l10n_in/account_move_line.py Before this commit: The gst tax detail query which computes the CGST, SGST, IGST and CESS for each account move line was only used for l10n_in_reports_gstr module After this commit: The gst tax detail query has now moved to odoo/addons/l10n_in/account_move_line.py, after which the query is now reusable, and can be used for multiple purposes task-3196107,3539187 - #### [IMP] l10n_in_reports: Enhanced report with GST amount It adds the functionality to see the GSTIN, CGST, SGST, IGST and CESS and Total Amount of move line while viewing the GSTR1 Base Report task-3539187 Related PR- https://github.com/odoo/odoo/pull/148401
The spreadsheet components have been updated to a newer library version, bringing incremental improvements and keeping the product foundation current. This helps maintain reliability for spreadsheet-related features such as charts and document spreadsheets, with limited direct disruption expected for users.
Original PR description
…-alpha.2
This update strengthens internal checks used by Odoo's web testing tools so invalid statements are caught more reliably. It helps reduce the risk of faulty test code slipping through, improving development quality without changing user-facing behavior.
The appraisal form warning no longer includes a link that could accidentally create a new appraisal. This helps employees and HR teams avoid duplicate appraisal records and keeps the warning focused on preventing unnecessary entries.
Original PR description
we remove the link to appraisal from the form view, because if you click on it, it will create a new appraisal, and this goes against the original purpose of this warning that is to try to not create duplicate appraisals. task-3582140
The README was updated to remove outdated setup examples from an old version and fix the documentation badge so it points to the current version. This helps users and evaluators see accurate project information and avoid following obsolete setup guidance.
Original PR description
**README.md has code examples from `10.0` and wrong badge for docs** Impacted versions: - master Remove `./setup/setup-dev.py` code examples as they are obsolete since version `11.0`. Correct badge URL to show the current version.
The web module's XML utility tests were moved to a newer testing approach. This keeps internal quality checks current and easier to maintain without changing how users interact with Odoo.
Original PR description
task 3705027
Saved chat replies are no longer loaded upfront when messaging starts. They are fetched only when needed, which helps keep the messaging experience lighter while preserving the same functionality for users.
Original PR description
Fetch them dynamically when they are needed instead. Part of task-3605717 https://github.com/odoo/enterprise/pull/55429
The anglo saxon accounting was set in the wrong field. It should be set in the field 'anglo_saxon_accounting' on the company and not 'use_anglo_saxon' on the configs. task-3642826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149550 Forward-Port-Of: odoo/odoo#148868
Original PR description
The anglo saxon accounting was set in the wrong field. It should be set in the field 'anglo_saxon_accounting' on the company and not 'use_anglo_saxon' on the configs. task-3642826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149550 Forward-Port-Of: odoo/odoo#148868
After [1], because mass_mailing also had a SnippetsMenu outside an iframe, the code that was handling clicks was moved from website to web_editor. However, not all of the code was moved, and the code which unbind events from the $body was still only available for website. This commit fixes that and also removes some useless code present in the same file. [1]: https://github.com/odoo/odoo/commit/5623c858d06e77011680ef0a5e04da5fa5f207e5 Related to task-3630716 Forward-Port-Of: odoo/odoo#
Original PR description
After [1], because mass_mailing also had a SnippetsMenu outside an iframe, the code that was handling clicks was moved from website to web_editor. However, not all of the code was moved, and the code which unbind events from the $body was still only available for website. This commit fixes that and also removes some useless code present in the same file. [1]: https://github.com/odoo/odoo/commit/5623c858d06e77011680ef0a5e04da5fa5f207e5 Related to task-3630716 Forward-Port-Of: odoo/odoo#149582
**Current behavior before PR:** Clicking on invalid link results in a blank and bizarre notification because we are accessing wrong parameter in wysiwyg.js. **Desired behavior after PR is merged:** After correcting parameters clicking on an invalid link triggers a notification displaying an invalid URL message. task-3563345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139301
Original PR description
**Current behavior before PR:** Clicking on invalid link results in a blank and bizarre notification because we are accessing wrong parameter in wysiwyg.js. **Desired behavior after PR is merged:** After correcting parameters clicking on an invalid link triggers a notification displaying an invalid URL message. task-3563345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139301
## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. ### Before this commit All of the select menu are sorted when the user select a value in one of them. This is not
Original PR description
## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the…
## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. ### Before this commit All of the select menu are sorted when the user select a value in one of them. This is not necessary as the sorting is already handled in beforeOpen. ### After this commit Selecting or deleting a value from a select menu is significantly faster as the sorting is not being unnecessarily computed in useEffect() anymore. ## Benchmarks When importing an Excel file containing 70 columns as an invoice with subfields search enabled, selecting/deleting an option from a select menu: | | Before | After | |-------------|---------|--------| | Selecting | 31.2 s | 1.5 s | | Deleting | 35.9 s | 1.6 s | ## References opw-3616438 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151318 Forward-Port-Of: odoo/odoo#146324
To reproduce: - Go in admin user - activate Audit Trail in the settings - Log out - Connect as demo - Go to the audit trail report - Activate the filter Update Only => Access right error The demo user doesn't have the right access for the domain of the filter. We should hide this filter for these users (Causes an issue in the click_all test) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
To reproduce: - Go in admin user - activate Audit Trail in the settings - Log out - Connect as demo - Go to the audit trail report - Activate the filter Update Only => Access right error The demo user doesn't have the right access for the domain of the filter. We should hide this filter for these users (Causes an issue in the click_all test) 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#151368 Forward-Port-Of: odoo/odoo#149783
Current Behavior before PR: When we have some text in selection and we move away from the selection the the toolbar disappear. Desired behavior after this PR is megerd: The toolbar is still visible when we move far from the selected text. task-3054229 Forward-Port-Of: odoo/odoo#151354 Forward-Port-Of: odoo/odoo#117645
Original PR description
Current Behavior before PR: When we have some text in selection and we move away from the selection the the toolbar disappear. Desired behavior after this PR is megerd: The toolbar is still visible when we move far from the selected text. task-3054229 Forward-Port-Of: odoo/odoo#151354 Forward-Port-Of: odoo/odoo#117645
Commit[1] implemented a way to output an image as its raw representation `<img src="data:image/png;base64......." />` It is useful for integrating an image of a record not accessible publicly. However the original commit forgot to allow the img node to handle the options passed to the field. Classes in particular were absent After this commit, the options are handled correctly, and the image in raw mode has the right classes. opw-3517861 [1]: f8b901d04b6c5874b56576f9b89899b2812296f2
Original PR description
Commit[1] implemented a way to output an image as its raw representation `<img src="data:image/png;base64......." />` It is useful for integrating an image of a record not accessible publicly. However the original commit forgot to allow the img node to handle the options passed to the field. Classes in particular were absent After this commit, the options are handled correctly, and the image in raw mode has the right classes. opw-3517861 [1]: f8b901d04b6c5874b56576f9b89899b2812296f2 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#151410 Forward-Port-Of: odoo/odoo#150140
**Steps to reproduce the bug:** - Create a storable product P1: - Create a BoM: - type: subcontracting - Add vendor - Add any component - Create a purchase order with 3 units of P1 - Confirm the purchase order - Go to the picking - receive 2 units of P1 and validate it - create a backorder - Cancel the backorder - Try to update the purchased qty in the PO line **Problem**: A user error is triggered: “Nothing to check the availability for.” When upd
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1: - Create a BoM: - type: subcontracting - Add vendor - Add any component - Create a purchase order with 3 units of P1 - Confirm the…
**Steps to reproduce the bug:**
- Create a storable product P1:
- Create a BoM:
- type: subcontracting
- Add vendor
- Add any component
- Create a purchase order with 3 units of P1
- Confirm the purchase order
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line
**Problem**:
A user error is triggered:
“Nothing to check the availability for.”
When updating the quantity in the purchase order line, the
"_create_or_update_picking" function is called to search for a linked
picking and update its quantity. However, in our case, since no picking
can be updated, a new picking is created:
https://github.com/odoo/odoo/blob/783048616362702f/addons/purchase_stock/models/purchase.py#L271-L272
Subsequently, the moves are confirmed:
https://github.com/odoo/odoo/blob/e38ed7c780d35fb9d5d799ac783048616362702f/addons/purchase_stock/models/purchase.py#L277
However, as the product is subcontracted, the "action_assign" function
is called: https://github.com/odoo/odoo/blob/4055293873132d56fe3787c77e499808b136f300/addons/mrp_subcontracting/models/stock_move.py#L105-L106
Since there is no move in the confirmed state, a user error is
triggered: https://github.com/odoo/odoo/blob/d45996c9155b9576c74aa8c6c6f718f8ab4d0af6/addons/stock/models/stock_picking.py#L450-L453
**Solution**:
When updating the quantity in the purchase order, if no picking requires
an update, it is better to avoid creating a new picking.
opw-3616381
Forward-Port-Of: odoo/odoo#151422
Forward-Port-Of: odoo/odoo#150013Before this commit, it was not possible to create a new picking on mobile if this picking has multiple moves. How to reproduce: - Open Odoo on mobile (or on desktop but simulate mobile device with devtools); - Inventory > Operations > Transfers; - Create a new transfer (a receipt for example); - In its operations (moves), add a new product, then add a second product. - Try to save or validate the picking -> A warning prevent to do it, saying you're trying to write on the field `product_q
Original PR description
Before this commit, it was not possible to create a new picking on mobile if this picking has multiple moves. How to reproduce: - Open Odoo on mobile (or on desktop but simulate mobile device with devtools); - Inventory > Operations > Transfers; - Create a new transfer (a receipt for example); - In its operations (moves), add a new product, then add a second product. - Try to save or validate the picking -> A warning prevent to do it, saying you're trying to write on the field `product_qty` instead of the field `product_uom_qty`. What's happening: For a unknown reason, the fields from the `stock.move` list view are saved once a second move is created, even if we're using the kanban view in the mobile version. To avoid this issue, we force the `force_save` to be false for the field `product_qty` in the kanban view. That's way, it prevents the issue. OPW-3577844 Forward-Port-Of: odoo/odoo#144282 Forward-Port-Of: odoo/odoo#143776
Current behavior before PR: - On table when we hit tab it displays toolbar as it sets selection between startPosition and endPosition. - On hitting tab it selects the text in the next cell completely, which should not happen. Desired behavior after PR is merged: - Now toolbar is not displayed on hitting tab. - selection is made to collapse at the end the lastNode of the cell. task-3475079 Forward-Port-Of: odoo/odoo#132807
Original PR description
Current behavior before PR: - On table when we hit tab it displays toolbar as it sets selection between startPosition and endPosition. - On hitting tab it selects the text in the next cell completely, which should not happen. Desired behavior after PR is merged: - Now toolbar is not displayed on hitting tab. - selection is made to collapse at the end the lastNode of the cell. task-3475079 Forward-Port-Of: odoo/odoo#132807
Since the refactoring of base_automation, the 'website-publishing' option of server actions was broken; it did get included in the view but outside of a group node and without labels. The result was a floating checkbox which would trigger a label-less char field upon selection - not the clearest of UIs. This commit properly insert these fields into a group node. Note that since server actions can normally only be reached by going through technical menus, the fact that this section of view is
Original PR description
Since the refactoring of base_automation, the 'website-publishing' option of server actions was broken; it did get included in the view but outside of a group node and without labels. The result was a floating checkbox which would trigger a label-less char field upon selection - not the clearest of UIs. This commit properly insert these fields into a group node. Note that since server actions can normally only be reached by going through technical menus, the fact that this section of view is now in a group_no_one-only section should not change anything functionally. Forward-Port-Of: odoo/odoo#151498
Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear. The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it.
Original PR description
Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear. The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it. This commit makes sure to not display the arrow in this case. task 3690523 Forward-Port-Of: odoo/odoo#149912
Before this commit, the displayed allocation on the dashboard were all the ones linked to allocations regardless of their validity period. This resulted with an overloaded dashboard with leave types that are not supposed to be displayed. Forward-Port-Of: odoo/odoo#151306
Original PR description
Before this commit, the displayed allocation on the dashboard were all the ones linked to allocations regardless of their validity period. This resulted with an overloaded dashboard with leave types that are not supposed to be displayed. Forward-Port-Of: odoo/odoo#151306
Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs: odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp [Excerpts of those massive useless logs](https://github.com/odoo/odoo/files/14065596/odoo.log.txt) This is because this method is a callback that can come in a different thread, creating a race condition. There's no problem on checking wether the directory exists before creating the file
Original PR description
Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs:
odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp
[Excerpts of those massive useless logs](https://github.com/odoo/odoo/files/14065596/odoo.log.txt)
This is because this method is a callback that can come in a different thread, creating a race condition.
There's no problem on checking wether the directory exists before creating the file, and then safeguarding from the problem.
@moduon MT-1075
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#151364In 17.0 the calendar view was revamped and the boolean field `all_day` started being rendered with the boolean_toggle widget. This widget, however, behaves differently than the boolean widget without passing explicit props. This caused the onchange call not to be made after this change. This commit fixes this by passing the autosave option as False on the field. task-3669879 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is m
Original PR description
In 17.0 the calendar view was revamped and the boolean field `all_day` started being rendered with the boolean_toggle widget. This widget, however, behaves differently than the boolean widget without passing explicit props. This caused the onchange call not to be made after this change. This commit fixes this by passing the autosave option as False on the field. task-3669879 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#148874
After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens when the cron is run after the first trigger of the recurrence. Imagine we have an alarm of 5 minutes before the event, the call for_setup_alarm from _send_reminder will try to get the next event in the recurrency to notify. However, the SQL query uses `WHERE start > now` and if the cron trigger runs be
Original PR description
After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens…
After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens when the cron is run after the first trigger of the recurrence. Imagine we have an alarm of 5 minutes before the event, the call for_setup_alarm from _send_reminder will try to get the next event in the recurrency to notify. However, the SQL query uses `WHERE start > now` and if the cron trigger runs before the event is started (most cases) this query will return the event that we're notifying. This commit fixes this by passing the events that are being notified in the context of the `_setup_alarm` call, so that we can exclude them from the query. How to reproduce? Install calendar - Create a recurring event with daily recurrence repeating for 3 days. Invite Demo, set an email alarm for 5 min before the event and create the event - A cron trigger will be created for 5 min before the event - Change your computer's time so that it is 5min before the event - The cron trigger will be called and it should create a new cron trigger for the other day, however no cron trigger is created Issue: SQL query in _setup_alarms in calendar.recurrence is getting the first event with start > now, however it returns the event that was already notified Solution: Pass in the context which events are already being notified so that they are excluded from the query task-3663455 Forward-Port-Of: odoo/odoo#147914
When themes do not define the content of additional pages such as "About Us" and "Services", the page definition is obtained from theme_default. This causes a problem if theme_default templates have not been generated. This did not happen before [1] because the templates were also created for non-installed themes. This commit ensures that theme default's configurator templates are always generated when website's configurator templates are generated. Steps to reproduce: - Start with
Original PR description
When themes do not define the content of additional pages such as "About Us" and "Services", the page definition is obtained from theme_default. This causes a problem if theme_default templates have not been generated. This did not happen before [1] because the templates were also created for non-installed themes. This commit ensures that theme default's configurator templates are always generated when website's configurator templates are generated. Steps to reproduce: - Start with `odoo-bin -i website` and design-themes in the addons path. - Create a new website. - Generate a website with "About Us", "Services", "Pricing" and "Privacy Policy". => Failed because templates defined in theme_default were not generated. [1]: https://github.com/odoo/odoo/commit/cfed4e391d11058b1b46417f0b630cdbc4070d7c task-3670496 X-original-commit: https://github.com/odoo/odoo/commit/9ae5e2bb25ea164264aeab7e45f53472a7d6aa5a
In some case, the author should be notified. For example, in the case someone books or cancels an appointment. The author should be notified as it's a proof that the action worked correctly. task-3505819 Forward-Port-Of: odoo/odoo#151542 Forward-Port-Of: odoo/odoo#136153
Original PR description
In some case, the author should be notified. For example, in the case someone books or cancels an appointment. The author should be notified as it's a proof that the action worked correctly. task-3505819 Forward-Port-Of: odoo/odoo#151542 Forward-Port-Of: odoo/odoo#136153
The `see records` action that drill downs to the specific AccountMoveLines that match the formula domain would break if we left some optional formula arguments empty (specifically concerns the offset and companyId arguments). This revision ensures that we use their default value when the arguments are not provided. Task: 3621110 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed t
Original PR description
The `see records` action that drill downs to the specific AccountMoveLines that match the formula domain would break if we left some optional formula arguments empty (specifically concerns the offset and companyId arguments). This revision ensures that we use their default value when the arguments are not provided. Task: 3621110 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#151423 Forward-Port-Of: odoo/odoo#148284
Since [1], the `is_for_livechat` context is used to restrict the channels returned by the `init_messaging` request in the live chat context. This does not work in CORS since the CORS route does not pass the context parameter to the `mail_init_messaging` method. This PR fixes the issue. [1]: https://github.com/odoo/odoo/pull/146098 Forward-Port-Of: odoo/odoo#151727
Original PR description
Since [1], the `is_for_livechat` context is used to restrict the channels returned by the `init_messaging` request in the live chat context. This does not work in CORS since the CORS route does not pass the context parameter to the `mail_init_messaging` method. This PR fixes the issue. [1]: https://github.com/odoo/odoo/pull/146098 Forward-Port-Of: odoo/odoo#151727
Before this commit, when the company of the employees updated is not in the allowed_company_ids of the current user (could happen in the execution of a cron), an error is triggered saying we are not allowed to create a timesheet for an employee inactive. The reason is because the employee is not fetched in the check made in the timesheet creation because of the company of that employee is not in the companies contained in the environment. This commit makes sure the companies in the envi
Original PR description
Before this commit, when the company of the employees updated is not in the allowed_company_ids of the current user (could happen in the execution of a cron), an error is triggered saying we are not allowed to create a timesheet for an employee inactive. The reason is because the employee is not fetched in the check made in the timesheet creation because of the company of that employee is not in the companies contained in the environment. This commit makes sure the companies in the environment are the ones set on the employees created/updated, to be sure those employees are fetched in the check made in timesheet creation. Forward-Port-Of: odoo/odoo#151596 Forward-Port-Of: odoo/odoo#151386
This fix is to solve a bug that appears in the demo data of the l10n_be specifically in the cash journal using an income type account for the negative cash difference which should be an expense type. current behavior: using income type in a loss account. desired behavior: expense account instead. opw-3642586 Forward-Port-Of: odoo/odoo#146936
Original PR description
This fix is to solve a bug that appears in the demo data of the l10n_be specifically in the cash journal using an income type account for the negative cash difference which should be an expense type. current behavior: using income type in a loss account. desired behavior: expense account instead. opw-3642586 Forward-Port-Of: odoo/odoo#146936
[FIX] website: destroy widgets before instantiating the wysiwyg Steps to reproduce the problem: - Add a "Countdown" snippet on the website. - Save. - Enter in edit mode again. -> Problem: the `destroy()` of the `CountdownWidget` public widget comes from a `widgets_start_request` that is triggered when the `WysiwygAdapterComponent` has been mounted and patched (see [useEffect documentation]). The problem is that, as the widgets are only destroyed at this moment, it is possible that a w
Original PR description
[FIX] website: destroy widgets before instantiating the wysiwyg Steps to reproduce the problem: - Add a "Countdown" snippet on the website. - Save. - Enter in edit mode again. -> Problem: the…
[FIX] website: destroy widgets before instantiating the wysiwyg Steps to reproduce the problem: - Add a "Countdown" snippet on the website. - Save. - Enter in edit mode again. -> Problem: the `destroy()` of the `CountdownWidget` public widget comes from a `widgets_start_request` that is triggered when the `WysiwygAdapterComponent` has been mounted and patched (see [useEffect documentation]). The problem is that, as the widgets are only destroyed at this moment, it is possible that a widget could replace an element that has been modified during the instantiation of the `WysiwygAdapterComponent`. For example: - At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the `o_editable` is added on some elements. - A widget could then replace one of these elements. - The widget is destroyed after the rendering of the `WysiwygAdapterComponent`. -> The `o_editable` class is not on the element anymore. The goal of this commit is to, as before [1], destroy the existing widgets before instantiating the `wysiwyg`. This commit also adds a test to ensure that the order of the calls to the widgets and wysiwyg lifecycle methods is coherent. Related to runbot-28700 [1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826 [useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffect Forward-Port-Of: odoo/odoo#151411 Forward-Port-Of: odoo/odoo#149385
Prior to this commit, using an online payment method with an image in self-ordering mode resulted in an issue preventing the opening of the mobile menu. The specific error encountered was: `TypeError: Object of type bytes is not JSON serializable` This issue arose due to the image field being of type bytes. Since the image field is not necessary for self-ordering, this commit addresses the problem by preventing the loading of the image for a payment method, resolving the serialization error.
Original PR description
Prior to this commit, using an online payment method with an image in self-ordering mode resulted in an issue preventing the opening of the mobile menu. The specific error encountered was: `TypeError: Object of type bytes is not JSON serializable` This issue arose due to the image field being of type bytes. Since the image field is not necessary for self-ordering, this commit addresses the problem by preventing the loading of the image for a payment method, resolving the serialization error. opw-3624798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151475 Forward-Port-Of: odoo/odoo#151388
Purpose ======= This reverts commit https://github.com/odoo-dev/odoo/commit/27a1ccc829d290c8589a535f10b31caaacd6400f which fixed the container height when course name was too long. It added a 'visibility: hidden' style which caused an issue on the course left bar where the progress bar and completed tag are located next to each other. Instead of adjusting the size of the container we prefer to limit the size of the course name to fit a single line. To do that we use the text-truncate class.
Original PR description
Purpose ======= This reverts commit https://github.com/odoo-dev/odoo/commit/27a1ccc829d290c8589a535f10b31caaacd6400f which fixed the container height when course name was too long. It added a 'visibility: hidden' style which caused an issue on the course left bar where the progress bar and completed tag are located next to each other. Instead of adjusting the size of the container we prefer to limit the size of the course name to fit a single line. To do that we use the text-truncate class. Task-3607404 Forward-Port-Of: odoo/odoo#150162 Forward-Port-Of: odoo/odoo#143136
'+ website_crm_partner_assign that overrides website_partner Implement partner slug validation for accurate URL redirection Prior to this commit, partner slugs weren't verified, leading to Google indexing outdated partner URLs even after renaming. With this change, when the virtual slug (fake slug sinc no read access on res.partner) differs from the actual one, redirection to the correct URL is enforced. Forward-Port-Of: odoo/odoo#151678 Forward-Port-Of: odoo/odoo#151524
Original PR description
'+ website_crm_partner_assign that overrides website_partner Implement partner slug validation for accurate URL redirection Prior to this commit, partner slugs weren't verified, leading to Google indexing outdated partner URLs even after renaming. With this change, when the virtual slug (fake slug sinc no read access on res.partner) differs from the actual one, redirection to the correct URL is enforced. Forward-Port-Of: odoo/odoo#151678 Forward-Port-Of: odoo/odoo#151524
### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails list (debug) and open the feedback request mail 5. The survey is expired, which is expected 6. Repeat 3. and use the same settings except for the deadline, set it in the future 7. Repeat 4. 8. The survey is expired, which should not be the case - You can also observe the issue by opening
Original PR description
### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails…
### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails list (debug) and open the feedback request mail 5. The survey is expired, which is expected 6. Repeat 3. and use the same settings except for the deadline, set it in the future 7. Repeat 4. 8. The survey is expired, which should not be the case - You can also observe the issue by opening `survey.user.input.view.tree.inherit.appraisal` (debug) instead of emails list. No survey to click on but the deadline is visible. ### Explanation: Deadline is not transmitted to answers in [action_send](https://github.com/odoo/enterprise/blob/df62564226d0ac9b4a3c7c489e5b2ff486dc7b2f/hr_appraisal_survey/wizard/appraisal_ask_feedback.py#L127-L130), which makes it not updating, despite being created with a deadline. ### Suggested Fix: The fix from 17.0 (commit: aecbb5c3e9b708e117510fb4ffd60baed3b6930c) is working in multiple version ranging from 15.0 to 16.4, applying it from 15.0. A test is also added to ensure workflow is not compromised again. opw-3665560 Forward-Port-Of: odoo/enterprise#55326 Forward-Port-Of: odoo/enterprise#54234
The author should always be notified when he cancels an appointment. The mail works as a proof that the cancellation has been taken into account. task-3505819 Forward-Port-Of: odoo/enterprise#55336 Forward-Port-Of: odoo/enterprise#47724
Original PR description
The author should always be notified when he cancels an appointment. The mail works as a proof that the cancellation has been taken into account. task-3505819 Forward-Port-Of: odoo/enterprise#55336 Forward-Port-Of: odoo/enterprise#47724
**[FIX] l10n_mx_edi: Remove reference to account_edi** **[IMP] l10n_mx_edi: Get the Mexican timezone from the same method.** The timezone is hardcoded at multiple places. It's less error prone to get the timezone everywhere from the same method. **[FIX] l10n_mx_edi: Don't fetch twice certificate + fix empty root_company** The certificate was fetched first when checking the config of the company, then when finding the certificate to use when processing the cfdi. Also, when we try t
Original PR description
**[FIX] l10n_mx_edi: Remove reference to account_edi** **[IMP] l10n_mx_edi: Get the Mexican timezone from the same method.** The timezone is hardcoded at multiple places. It's less error prone to get the timezone everywhere from the same method. **[FIX] l10n_mx_edi: Don't fetch twice certificate + fix empty root_company** The certificate was fetched first when checking the config of the company, then when finding the certificate to use when processing the cfdi. Also, when we try to send a CFDI when no certificate are configurated, a traceback is raised. This is because the root_company is the one having some certificate. If no certificate, the root_company is empty and then, an ensure_one raises an error. sentry-4719634588,4729692933,4729689997 Forward-Port-Of: odoo/enterprise#55351 Forward-Port-Of: odoo/enterprise#54544
In this commit =========================== Corrected the customer invoices sum total value, before it was not including the invoices from pos, so made necessary changes in domain to consider it. task-3541414 Forward-Port-Of: odoo/enterprise#55315
Original PR description
In this commit =========================== Corrected the customer invoices sum total value, before it was not including the invoices from pos, so made necessary changes in domain to consider it. task-3541414 Forward-Port-Of: odoo/enterprise#55315
Commit 7ad17cb introduced a change in the way payroll reports are generated. However, this change forgot to include those changes in the kenyan l10n reporting. This commit adapts the P9 form so it can be generated again. Forward-Port-Of: odoo/enterprise#55206
Original PR description
Commit 7ad17cb introduced a change in the way payroll reports are generated. However, this change forgot to include those changes in the kenyan l10n reporting. This commit adapts the P9 form so it can be generated again. Forward-Port-Of: odoo/enterprise#55206