Tuesday, October 8, 2024
35 changes · saas-17.4
Enhancements to existing features
This update adds a test to help ensure Xendit payment information continues to display correctly after a previous fix. It reduces the risk of the same issue returning in future changes, with no expected change for day-to-day users.
Original PR description
Adding unit test to ensure that the behaviour fixed by PR https://github.com/odoo/odoo/pull/181752 persists in the future --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Time Off dashboard link for pending requests now opens the right allocation records by including both first and second approval filters. This helps managers review all pending allocations without missing requests that are waiting for the first approval step.
Original PR description
Steps: - Install the hr_holidays module - Click on the `Pending Requests` from dashboard Description of the issue/feature this PR addresses: In the Time Off module, when clicking on Pending Requests, it opens the allocation with the only second approval filter. Fix: This PR resolves the issue by setting the default search filter to first approval along with second approval. task-4208036
Miscellaneous changes
Steps to reproduce: 1. Open the course content. 2. Exit the full screen. 3. Try to comment on the content. 4. The Send button on comments not working Technical Reason: In portal_chatter_post, a ValidationError was shown in the terminal: "Only a single review can be posted per course." This occurred because it was checking the 'res_id' in the 'slide.channel' model while being in the 'slide.slide' model. After this Commit: The send button on the comment should work properly on the cont
Original PR description
Steps to reproduce: 1. Open the course content. 2. Exit the full screen. 3. Try to comment on the content. 4. The Send button on comments not working Technical Reason: In portal_chatter_post, a ValidationError was shown in the terminal: "Only a single review can be posted per course." This occurred because it was checking the 'res_id' in the 'slide.channel' model while being in the 'slide.slide' model. After this Commit: The send button on the comment should work properly on the content. Task-4213443 Forward-Port-Of: odoo/odoo#182652 Forward-Port-Of: odoo/odoo#182153
This fixes an issue where adding a map block to an event description could fail when certain website menu settings were disabled. The map is now initialized in the right order, preventing save/start errors and making the website editor more reliable.
Original PR description
Since [1] when miscellaneous trackers were disabled until cookies are accepted, `s_map` generates its URL if the `iframe` is not inside the document. Unfortunately, it does it before adding the `iframe` to the element and this results in an error. This commit reorders the operations so that the `iframe` source is set only once the element has an `iframe`. Steps to reproduce: - Edit an event - Make sure to disable the event's sub-menu - Drop an `s_map` into the event's `description` field - Save => The `s_map` snippet failed upon `start`. [1]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-21d1f66e41f1c6b04a9c11edf6d4ff7d9773b0bf0b4f77c8cecea173f0c0db19R22 opw-4171564
This fix ensures customer information linked to draft Point of Sale orders is loaded correctly after a page refresh. It prevents staff from having to re-enter customer details, reducing checkout disruption and duplicate effort.
Original PR description
Before this commit, there was an issue where a partner associated with a draft order might not be loaded. This could lead to users having to re-enter the customer's information if the page was refreshed. opw-4207881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Week-based date filters now return records from the correct week when used on a Monday. This helps managers and employees avoid seeing misleading timesheet, attendance, or task information at the start of the week.
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531
The point of sale product screen now shows the main product image instead of an image from one of its variants. This helps staff identify products more consistently and avoids confusion when products have multiple variants.
Original PR description
Before this commit, the product screen displayed an image of one of the product's variants, contrary to the expectation of showing the product template image. This commit corrects the behavior to ensure the product template image is displayed. opw-4234351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Week-based date filters now show the correct records when the current day is Monday. This prevents users from seeing entries from the wrong week in planning and timesheet forecast views.
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531
The signing workflow now shows the “Saved” confirmation only when the template remains active. This prevents users from being misled into looking for archived templates that are hidden by default after uploading a PDF to sign.
Original PR description
Change ----- UX improvement: a "Saved" message is displayed when leaving the template only if it is active, as it can be confusing for the user to not be able to find it (archived records are not visible by default). This happens when uploading a pdf as a document to sign. opw-4207093
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167565 Forward-Port-Of: odoo/odoo#153993
Original PR description
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167565 Forward-Port-Of: odoo/odoo#153993
**Current behavior before PR:** The pencil icon for editing the channel image was not visible on hover due to a wrongly written condition, preventing users from updating the image in the form view. **Desired behavior after PR is merged:** This PR fixes the issue by ensuring that the pencil icon now appears on hover, allowing users to edit the channel image directly from the form view. Task-4224182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
**Current behavior before PR:** The pencil icon for editing the channel image was not visible on hover due to a wrongly written condition, preventing users from updating the image in the form view. **Desired behavior after PR is merged:** This PR fixes the issue by ensuring that the pencil icon now appears on hover, allowing users to edit the channel image directly from the form view. Task-4224182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182486
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On save, this error appears: > odoo.exceptions.UserError: Incompatible companies on records: > - [Company Name] belongs to company [Company Name] and 'Address' (partner_id: [Company Name]) belongs to another company. ### Explanation: When accessing its branches, the context key `def
Original PR description
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On…
### Steps to reproduce the issue: 1. Create a Parent Company and a Branch Company 2. In the Parent Company, click on the "Branches" Smart Button 3. From there, create another Branch Company 4. On save, this error appears: > odoo.exceptions.UserError: Incompatible companies on records: > - [Company Name] belongs to company [Company Name] and 'Address' (partner_id: [Company Name]) belongs to another company. ### Explanation: When accessing its branches, the context key `default_parent_id` is set to the Parent Company's `id`. It is used to make sure the Branch Company has the Parent Company as `parent_id`. https://github.com/odoo/odoo/blob/4d5195d6756d47c33929fffa972ee801bb833622/odoo/addons/base/models/res_company.py#L423-L426 It is not removed when creating the Branch Partner, and this value will be used to assign a `parent_id` to the Branch Partner through `get_default`, this alone could create an out of range error if there is no `res.partner` with the same `id` as the Parent Company. https://github.com/odoo/odoo/blob/fbf95d3c4655b23554fe5dfa136382472041c195/odoo/addons/base/models/res_partner.py#L193-L197 https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L1488-L1491 If there is a Parent Partner, it will give its `company_id` to the Branch Partner. Afterwards, `stock.warehouse` is created with the Branch Company as `company_id` and the Branch Partner as `partner_id`. https://github.com/odoo/odoo/blob/78e44dc5a3dee67956f380fa468bab02692ce5ac/addons/stock/models/res_company.py#L202-L207 During its creation, `stock.warehouse` will call `_check_company` and, when `res.partner.company_id` is not in `stock.warehouse.company_id.parent_ids`, will report the inconsistency. https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L4068-L4073 https://github.com/odoo/odoo/blob/71b6eeed0a648934525cd758afebdb87500ec939/odoo/models.py#L185-L189 ### Fix reasoning: Removing the problematic context key `default_parent_id` during the creation of the Branch Partner will avoid any out of range error and most importantly will not assign a default value to the Partner when it should not have one. opw-4194396 Forward-Port-Of: odoo/odoo#182565 Forward-Port-Of: odoo/odoo#182342
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the paymen
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the payment term line if it has not been modified manually. This can be done by checking that their values in _origin are similar. opw-4173634 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182568 Forward-Port-Of: odoo/odoo#182136
Before this commit, due to the commit https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd, when the user goes to list view of timesheets, he could be disconnect due to a many rpc calls made to get the projects for which we only allow to create and edit task (because some fields could be required). This commit moves most of changes made in https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd in enterprise since only with hr_timesheet module
Original PR description
Before this commit, due to the commit https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd, when the user goes to list view of timesheets, he could be disconnect due to a many rpc calls made to get the projects for which we only allow to create and edit task (because some fields could be required). This commit moves most of changes made in https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd in enterprise since only with hr_timesheet module installed, we will never get a project for which we don't want to allow the quick create on task_id field. Impacted versions: 17.0+ task-4221621 Forward-Port-Of: odoo/odoo#182459 Forward-Port-Of: odoo/odoo#182303
Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection. Steps to reproduce: 1. Create an order in a table 2. Block the internet connection to preven
Original PR description
Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks,…
Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection. Steps to reproduce: 1. Create an order in a table 2. Block the internet connection to prevent the order from syncing 2. Go to the floor screen 3. Re-enable a slow internet connection 4. Quickly click on two different tables without orders This behavior results in duplicate order creation. Since it's not possible to enforce uniqueness on the server side via a constraint, this commit introduces a debouncing mechanism in the `_save_to_server` function. This ensures that an order cannot be sent to the server more than once concurrently, preventing duplicate creation. opw-4136101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181472 Forward-Port-Of: odoo/odoo#180278
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#61981](https://github.com/odoo/enterprise/pull/61981) opw-3874034 Forward-Port-Of: odoo/odoo#179220 Forward-Port-Of: odoo/odoo#164410
before this PR: In a multi-company environment, the GST E-Invoice (India) option appears for all companies, regardless of the company's country after this PR: on Journal, GST E-Invoice (India) option appears for only Indian companies Forward-Port-Of: odoo/odoo#181153
Original PR description
before this PR: In a multi-company environment, the GST E-Invoice (India) option appears for all companies, regardless of the company's country after this PR: on Journal, GST E-Invoice (India) option appears for only Indian companies Forward-Port-Of: odoo/odoo#181153
a bug was reported that when there were multiple available pricelists, the sequence provided by the admin wasn't taken into consideration. This fix returns the first available pricelist based on the model's order, instead of based on the creation order. > [EBC] pricelist country detection issue with more than 2 pricelists: > https://drive.google.com/file/d/1eHlCqA_2CW2HB_IvGlOscQhXZVi_Owq3/view?usp=sharing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/sub
Original PR description
a bug was reported that when there were multiple available pricelists, the sequence provided by the admin wasn't taken into consideration. This fix returns the first available pricelist based on the model's order, instead of based on the creation order. > [EBC] pricelist country detection issue with more than 2 pricelists: > https://drive.google.com/file/d/1eHlCqA_2CW2HB_IvGlOscQhXZVi_Owq3/view?usp=sharing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182100
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing.
Original PR description
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in…
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing. This is even more obvious on a slow network. The difference between the first time and the others is that the form view used in the quick create must be loaded the first time, and is in cache afterwards. When we click on the "+" icon, the following happens: - we remove sample records from the groups and we enable the quick create in a column => triggers a rendering of the KanbanRenderer - in the same tick, we toggle the useSampleModel flag on the model => triggers a rendering of the Controller After its rendering, the Controller no longer has the classname `o_view_sample_data` which ensures that sample records are displayed as ghosts. After its rendering, the Renderer no longer contains sample records. The flickering occurs when the rendering of the Renderer is async (the one of the Controller being always sync, as it doesn't wait for his children to be re-rendered, as their props didn't change). Indeed, in that case, there's a small timeframe during which the controller no longer has the classname `o_view_sample_data` but the renderer still contains sample records. Normally, the rendering of the Renderer should always be sync. Indeed, we triggered the loadViews in its onWillStart but we didn't wait for the rpc to return (we have a `isLoaded` flag, and we have an empty rendering while `isLoaded` is false). However, when the loadViews is already in the cache, the promise is resolves in the next microTick, and we directly render the component with the state `isLoaded` true, i.e. with the KanbanQuickCreateController. But that component is always async, as it loads the form view data (onchange) in its onWillStart, and must wait for it. As a consequence, in that case, the whole rendering of the Renderer is delayed. To fix the issue, this commit simply ensures that the rendering of the KanbanRecordQuickCreate is **always** sync, by toggling the `isLoaded` flag in onMounted instead of onWillStart. That way, the Renderer is rendered without the sample records in the same animationFrame as the Controller, and only then we toggle the KanbanQuickCreateController. Closes #181743 Task~4196741 Forward-Port-Of: odoo/odoo#182300
Steps to reproduce =================== - Create a survey having MCQ-type questions. - Create a live session. - Copy & paste the link into another browser. - Start giving the answer. - Try to submit the answer which is mandatory in MCQ. - The alert box overlaps the options. This PR addresses the issue and adds the margin between the options and the alert box. Task-4231590 Forward-Port-Of: odoo/odoo#182532
Original PR description
Steps to reproduce =================== - Create a survey having MCQ-type questions. - Create a live session. - Copy & paste the link into another browser. - Start giving the answer. - Try to submit the answer which is mandatory in MCQ. - The alert box overlaps the options. This PR addresses the issue and adds the margin between the options and the alert box. Task-4231590 Forward-Port-Of: odoo/odoo#182532
**How to reproduce:** - Go to website, then on events - Open edit mode - Select 'Template Badge' - Select List from dropdown - Open a mobile view **Specifications:** Template badge is overlapped with the event details, change its position for mobile view. Add it above location. **After this PR:** Template Badge's position will be changed in mobile view and will no longer be overlapped by the content. Task-4210363 Forward-Port-Of: odoo/odoo#182323
Original PR description
**How to reproduce:** - Go to website, then on events - Open edit mode - Select 'Template Badge' - Select List from dropdown - Open a mobile view **Specifications:** Template badge is overlapped with the event details, change its position for mobile view. Add it above location. **After this PR:** Template Badge's position will be changed in mobile view and will no longer be overlapped by the content. Task-4210363 Forward-Port-Of: odoo/odoo#182323
Maybe not the right approach, but to put the issue over the table at least. Users can copy paste their html signatures from whatever source, and that can lead to buggy behaviors when that signatures are used in the editor. For this case, users copy-pasted from outlook their html signature containing nested comments like this ``` <!--<![endif]--> ``` This lead to a buggy behavior of the web_editor whenever those signatures were loaded in the template. For example, in the invoice s
Original PR description
Maybe not the right approach, but to put the issue over the table at least. Users can copy paste their html signatures from whatever source, and that can lead to buggy behaviors when that signatures are used in the editor. For this case, users copy-pasted from outlook their html signature containing nested comments like this ``` <!--<![endif]--> ``` This lead to a buggy behavior of the web_editor whenever those signatures were loaded in the template. For example, in the invoice sending template. In that case, the web_editor will rollback any attemped change in the mail composer when that code is loaded into the composer body editor. The issue is that those nested comments are detected incorrectly. So better simply ignore them as they don't add up any value. cc @Tecnativa TT51068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182382
Currently, a traceback is occurring when the user tries to export a translation without selecting the model when the export type is `model` To reproduce this issue: 1) Try to export a translation without a model with the export type as `model` Error:- ``` KeyError: False ``` We can see that the model is not required when exporting a translation when the export type is `model`. This leads to a Keyerror from the below line https://github.com/odoo/odoo/blob/ce786882fe8527864
Original PR description
Currently, a traceback is occurring when the user tries to export a translation without selecting the model when the export type is `model` To reproduce this issue: 1) Try to export a translation without a model with the export type as `model` Error:- ``` KeyError: False ``` We can see that the model is not required when exporting a translation when the export type is `model`. This leads to a Keyerror from the below line https://github.com/odoo/odoo/blob/ce786882fe852786441ab86d9311aecc143cf57d/odoo/addons/base/wizard/base_export_language.py#L43-L44 Making the model as required in a stable version if the export type is `model` in XML is not stable friendly. So raising a `Usererror` will resolve this issue in stable. Note:- Will make the model as required if the export_type is `model` in master in xml sentry-5686584762 Forward-Port-Of: odoo/odoo#181114
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Enterprise PR: https://github.com/odoo/enterprise/pull/70505 Forward-Port-Of: odoo/odoo#181068
Issues: The test I created here had an inheritance which was in enterprise, as pointed by gawa https://github.com/odoo/odoo/pull/168930#issuecomment-2340200503 Solution: Correct the test to remove the inheritance. opw-3921156 Forward-Port-Of: odoo/odoo#179761
Original PR description
Issues: The test I created here had an inheritance which was in enterprise, as pointed by gawa https://github.com/odoo/odoo/pull/168930#issuecomment-2340200503 Solution: Correct the test to remove the inheritance. opw-3921156 Forward-Port-Of: odoo/odoo#179761
Currently the IoT Box accepts maximum the default nginx size of 1MB per request. This can be an issue when sending over heavy files to print. This PR increases the limit to 10MB and backports the PR #157733 in v17.0 as this version will be the base for our new image Forward-Port-Of: odoo/odoo#181202
Original PR description
Currently the IoT Box accepts maximum the default nginx size of 1MB per request. This can be an issue when sending over heavy files to print. This PR increases the limit to 10MB and backports the PR #157733 in v17.0 as this version will be the base for our new image Forward-Port-Of: odoo/odoo#181202
**This is a back-port of a hotfix done during the OXP. See the original commit message below:** `websocket.WebSocketApp` doesn't set any fingerprint header, like no user-agent or origin, ... It can lead to issues when using a proxy firewall, such as HAProxy, as it could lead to the fingerpint to be 00000000-00000000-00000000-00000000, which can be seen as not legitimate, and the requests to be rejected for that reason. By setting a user-agent, we overcome this limitation --- I conf
Original PR description
**This is a back-port of a hotfix done during the OXP. See the original commit message below:** `websocket.WebSocketApp` doesn't set any fingerprint header, like no user-agent or origin, ... It can lead to issues when using a proxy firewall, such as HAProxy, as it could lead to the fingerpint to be 00000000-00000000-00000000-00000000, which can be seen as not legitimate, and the requests to be rejected for that reason. By setting a user-agent, we overcome this limitation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182562
Steps to reproduce: - On a fresh DB install only project_hr_expense(Uninstall project_sale_expense). - Create a expense on a project. - Go to Project Updates/ Dashboard - i.e., project right side panel Issue: - You can see that there is no action click on Expense while there should be. Reason: - Incorrect configuration of attaching ids into the action causing this. Solution: - Fixed the incorrect in which action is being generated. Technical: - The issue only occurs w
Original PR description
Steps to reproduce:
- On a fresh DB install only project_hr_expense(Uninstall project_sale_expense).
- Create a expense on a project.
- Go to Project Updates/ Dashboard - i.e., project right side panel
Issue:
- You can see that there is no action click on Expense while there should be.
Reason:
- Incorrect configuration of attaching ids into the action causing this.
Solution:
- Fixed the incorrect in which action is being generated.
Technical:
- The issue only occurs when the project_hr_expense module is installed. If the project_sale_expense module is installed,
the issue does not reproduce because the expense action is handled properly.
task-4175573
Forward-Port-Of: odoo/odoo#182431
Forward-Port-Of: odoo/odoo#179717If an Amazon order has more than one item it was creating for each item an own shipping line even if it had not even a shipping price defined per item line. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#70940
Original PR description
If an Amazon order has more than one item it was creating for each item an own shipping line even if it had not even a shipping price defined per item line. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#70940
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed i
Original PR description
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in…
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed in the list view instead of calling that rpc once. This commit moves that behavior in industry_fsm module since `get_create_edit_project_ids` method will only return fsm projects when the industry_fsm module is installed. Without that module, no project ids will be returned and so it is not really needed to do a rpc call for nothing. This commit also improves the changes to make sure the rpc call is made only once in the list view. Note: that behavior is not managed in the list view of All Timesheets since it would need to add a custom js class. It will be done in 18.0. task-4221621 Forward-Port-Of: odoo/enterprise#71286 Forward-Port-Of: odoo/enterprise#71183
The vendor dropdown does not close when a extract box is clicked and a creation dialog opens. It would only close after the first click. In this commit the dropdown is closed straight away. Forward-Port-Of: odoo/enterprise#71039
Original PR description
The vendor dropdown does not close when a extract box is clicked and a creation dialog opens. It would only close after the first click. In this commit the dropdown is closed straight away. Forward-Port-Of: odoo/enterprise#71039
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410) opw-3874034 Forward-Port-Of: odoo/enterprise#69469 Forward-Port-Of: odoo/enterprise#61981
As the Fixed Establishment is no more an obligation for the government, we remove this information from the xml export of the OSS sales report opw-3981681 Forward-Port-Of: odoo/enterprise#71130 Forward-Port-Of: odoo/enterprise#66876
Original PR description
As the Fixed Establishment is no more an obligation for the government, we remove this information from the xml export of the OSS sales report opw-3981681 Forward-Port-Of: odoo/enterprise#71130 Forward-Port-Of: odoo/enterprise#66876
Backport of parts of https://github.com/odoo/enterprise/pull/60147/commits/976158bca652bc21765306ff5366a73e8982853b commit. When running Timer tests for single app install nightly builds, we were getting error, as timer tests needed timesheet_greed to be installed.  This pr is solving this issue by moving the test in timesheet_grid, and creating additional tests in time
Original PR description
Backport of parts of https://github.com/odoo/enterprise/pull/60147/commits/976158bca652bc21765306ff5366a73e8982853b commit. When running Timer tests for single app install nightly builds, we were getting error, as timer tests needed timesheet_greed to be installed.  This pr is solving this issue by moving the test in timesheet_grid, and creating additional tests in timer module. Forward-Port-Of: odoo/enterprise#67789
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_pe_edi_pos** * Switch to the **PE Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_pe_edi_pos** * Switch to the **PE Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Community PR: https://github.com/odoo/odoo/pull/181068 Forward-Port-Of: odoo/enterprise#70505