Wednesday, September 18, 2024
31 changes · saas-17.4
Resolved issues and error corrections
Recruitment applicants can now correctly use the company information needed when assigning a recruiter from the kanban view. This prevents an error that blocked recruiter assignment when the recruiter field was initially empty.
Original PR description
Steps to reproduce:
1. make an applicant, leave recruiter field empty
2. Go to kanban view and try to assign a recruiter on the applicant
Error:
```
UncaughtPromiseError > EvalError
Uncaught Promise > Can not evaluate python expression: ([('share', '=', False), ('company_ids', 'in', company_id)])
Error: Name 'company_id' is not defined
```
The issue happens because the `company_id` field is missing from the view and as a result this field cannot be found.
This commit adds the field so that the domain can be calculated correctly.
opw-4188706
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where working hours scheduled on Sundays were missing from employee calendar views. This ensures weekly schedules are displayed accurately for teams that work on Sundays.
Original PR description
Issue ----- Sunday working hours set in the working schedule do not appear in the calendar. Unlike other working hours which are displayed in white. Cause ----- Fullcalendar uses 0-based indexing starting on Sunday, the correct conversion from backend to fullcalendar library is 6 -> 0 for Sunday. opw-4152047
Opening a member list in Mail could get stuck in Firefox when two people had the same display name. The list ordering now uses each member's ID as a tie-breaker, preventing the loop and keeping the member list reliable.
Original PR description
This PR fixes an infinite loop that occurs when opening a member list with two members sharing the same name on firefox. This occurs because the sort function on `offlineMembers` is non deterministic when two members have the same name. It will first put the first member above the other one, then the opposite and so on. This PR updates the sort function to rely on id when two members have the same name, making the sort deterministic.
A web module test was adjusted so it checks the intended behavior around screen positioning in an invalid embedded page scenario. This helps keep future updates reliable without changing what users see in the product.
Original PR description
This commit fixes a test that even though would pass with the current implementation of the position hook, was behaving in a completely different way from before the conversion.
The receipt screen no longer shows an unnecessary email toggle when email is the only available delivery method. This reduces confusion for cashiers and keeps the checkout flow cleaner when SMS or WhatsApp sending is not enabled.
Original PR description
If SMS or Whatsapp are not enabled, diplaying the email toggle button to set the mode to email is redundant, as email would be the only available option by default. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The appointment booking flow now uses a more specific label, "Review Booking," to avoid conflicting with another translated use of "Review." This prevents customers from seeing an incorrect translation during booking review, improving clarity in localized interfaces.
Original PR description
### Issue: The word 'Review' being used in 2 different frontend locations (it's also used in portal_rating) and the frontend can only use the last translation that it loads. Thus, the 'Review' is translated as 'Avis', which is wrong. ### After this PR: Renamed 'Review' label to 'Review Booking'. Task-4164125
Miscellaneous changes
Versions: 17.0, saas-17.1, saas-17.2 Issue: The tax totals company currency table displays repetitive information. Purpose of this PR: To remove the repetitive tax totals table. Steps to Reproduce: - Install l10n_cl_edi - Set up a currency rate for any active foreign currency (different from CLP) (Using USD for the example) - Create an invoice using a foreign currency (USD in the example) opw-4127839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
Versions: 17.0, saas-17.1, saas-17.2 Issue: The tax totals company currency table displays repetitive information. Purpose of this PR: To remove the repetitive tax totals table. Steps to Reproduce: - Install l10n_cl_edi - Set up a currency rate for any active foreign currency (different from CLP) (Using USD for the example) - Create an invoice using a foreign currency (USD in the example) opw-4127839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178265
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments be
Original PR description
This error occurs when attempting to add a payment using the ``Quick Add`` feature in the Kanban view. Steps to reproduce: - Install the ``pos_online_payment`` module - Point of Sale > Orders > Payments > Go to Kanban view - Click on the ``Quick Add`` button and ``Add`` Traceback: ``KeyError: 'payment_method_id'`` The error in [1] occurred because the ``payment_method_id`` was not found in the vals. This commit will fix the above error by removing the Kanban view from payments because we never allow payment creation. [1]- https://github.com/odoo/odoo/blob/42ab53925b140508e2aa837ce09c914b8f243b21/addons/pos_online_payment/models/pos_payment.py#L20 sentry-5750182450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180557
The changes made in #156437 had the purpose of adding more flexibility in the moves, being able the re-route them on the fly, without having to bother with the whole chain being already created. And while the search for pull rules properly look for parent location if no rule is found within the givin location, it wasn't the case yet for push rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180181
Original PR description
The changes made in #156437 had the purpose of adding more flexibility in the moves, being able the re-route them on the fly, without having to bother with the whole chain being already created. And while the search for pull rules properly look for parent location if no rule is found within the givin location, it wasn't the case yet for push rules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180181
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase order with the oldest date_order field. The last_purchase_date field should be set using the purchase order with the most recent date_order field. Purpose: By ordering the purchase orders by date_order desc we will get the purchase order with the most recent date_order field. This will cause the supp
Original PR description
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase…
Problem: When viewing the replenishment information for a product, the last purchase date is set to the date from the oldest purchase order. The last_purchase_date field is set using the purchase order with the oldest date_order field. The last_purchase_date field should be set using the purchase order with the most recent date_order field. Purpose: By ordering the purchase orders by date_order desc we will get the purchase order with the most recent date_order field. This will cause the supplier’s last purchase date to be the most recent one instead of the oldest one. Steps to Reproduce on Runbot: 1. Create a storable product and create a reordering rule for this product 2. Create a purchase order for this product and set the Order Deadline to a date in the past and then confirm it 3. Create a purchase order for this product and set the Order Deadline to the current date and the confirm it 4. Navigate to this product’s replenishment information 5. Observe that the Last Purchase date is the earlier of the two dates from the purchase orders opw-4113810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180500 Forward-Port-Of: odoo/odoo#177306
**Steps to reproduce this issue:** - Go to views (Settings -> Technical -> User Interface -> Views). - Edit something and click the Save/Discard button. - Notice that the Save and Discard buttons remain visible. **Current behavior before PR:** The state `fieldIsDirty` remains true after clicking the Save/Discard button because the `FIELD_IS_DIRTY` event defined in the `useBus` hook is not triggered in `commitChanges`. **Desired behavior after PR is merged:** The Save and Discard
Original PR description
**Steps to reproduce this issue:** - Go to views (Settings -> Technical -> User Interface -> Views). - Edit something and click the Save/Discard button. - Notice that the Save and Discard buttons remain visible. **Current behavior before PR:** The state `fieldIsDirty` remains true after clicking the Save/Discard button because the `FIELD_IS_DIRTY` event defined in the `useBus` hook is not triggered in `commitChanges`. **Desired behavior after PR is merged:** The Save and Discard buttons hide successfully when not needed. task-3948043 Forward-Port-Of: odoo/odoo#180414 Forward-Port-Of: odoo/odoo#174187
Description of the issue/feature this PR addresses: The date format in Lao contain a typo: `%d/%m/y` should be `%d/%m/%Y` Desired behavior after PR is merged: The date format should be `%d/%m/%Y` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180481
Original PR description
Description of the issue/feature this PR addresses: The date format in Lao contain a typo: `%d/%m/y` should be `%d/%m/%Y` Desired behavior after PR is merged: The date format should be `%d/%m/%Y` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180481
With this commit we extend the account_tax model to add tax category code and tax exemption reason, that will be used when generating peppol xml. Without that we can only do some incomplete computation leading to missing informations in peppol xml. opw-4061329 Forward-Port-Of: odoo/odoo#180309 Forward-Port-Of: odoo/odoo#176221
Original PR description
With this commit we extend the account_tax model to add tax category code and tax exemption reason, that will be used when generating peppol xml. Without that we can only do some incomplete computation leading to missing informations in peppol xml. opw-4061329 Forward-Port-Of: odoo/odoo#180309 Forward-Port-Of: odoo/odoo#176221
When returning a purchase/sale order, we can not create accrued entry for the returned order Steps: - Create a purchase order - Receive product - Create and confirm bill - Set received quantity to 0 - From the action menu, select "Accrued Expense Entry" -> There is no line, it should be a line for the vendor credit not This is because we filter the order lines to get only the lines that have a positive quantity to invoice, in that case the quantity to invoice is negative and should be taken i
Original PR description
When returning a purchase/sale order, we can not create accrued entry for the returned order Steps: - Create a purchase order - Receive product - Create and confirm bill - Set received quantity to 0 - From the action menu, select "Accrued Expense Entry" -> There is no line, it should be a line for the vendor credit not This is because we filter the order lines to get only the lines that have a positive quantity to invoice, in that case the quantity to invoice is negative and should be taken into account opw-4176706 Forward-Port-Of: odoo/odoo#180299
Purpose of this PR: When a canned response have a long shortcut text, the text overflow the navigablelist. Before:  After:  Forward-Port-Of: odoo/odoo#180438
Original PR description
Purpose of this PR: When a canned response have a long shortcut text, the text overflow the navigablelist. Before:  After:  Forward-Port-Of: odoo/odoo#180438
When uploading a bill via xml, if the file does not contain the node 'Name` in accounting parties informations, we don't set the partner at all on the bill. With this commit, if the node `Name` is missing, we fallback to the node `RegistrationName`. opw-4154071 Forward-Port-Of: odoo/odoo#180308 Forward-Port-Of: odoo/odoo#180056
Original PR description
When uploading a bill via xml, if the file does not contain the node 'Name` in accounting parties informations, we don't set the partner at all on the bill. With this commit, if the node `Name` is missing, we fallback to the node `RegistrationName`. opw-4154071 Forward-Port-Of: odoo/odoo#180308 Forward-Port-Of: odoo/odoo#180056
Before this commit, when importing multiple leaves for different employee, the last employee in the list will be set as a follower on all the created leaves. This commit fixes this behavior by checking for the employee assigned to each leave and using its ID when adding the follower. opw-4023073 Forward-Port-Of: odoo/odoo#179872 Forward-Port-Of: odoo/odoo#178994
Original PR description
Before this commit, when importing multiple leaves for different employee, the last employee in the list will be set as a follower on all the created leaves. This commit fixes this behavior by checking for the employee assigned to each leave and using its ID when adding the follower. opw-4023073 Forward-Port-Of: odoo/odoo#179872 Forward-Port-Of: odoo/odoo#178994
Do not use the purchase description in dropshipping pickings Example use case: - Create a dropshipping product and set a purchase description - Create a sales order with the product and confirm - Purchase order will have the purchase description - Confirm the purchase order - Go to dropshipping picking - Print Delivery slip Current behavior: - Product name and purchase description is displayed Expected behavior: - Purchase description should not be displayed @Tecnativa TT5067
Original PR description
Do not use the purchase description in dropshipping pickings Example use case: - Create a dropshipping product and set a purchase description - Create a sales order with the product and confirm - Purchase order will have the purchase description - Confirm the purchase order - Go to dropshipping picking - Print Delivery slip Current behavior: - Product name and purchase description is displayed Expected behavior: - Purchase description should not be displayed @Tecnativa TT50677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180111 Forward-Port-Of: odoo/odoo#179104
For the US, it is mandatory to have the accrual gains, usage and balance on the payslip. This adds a new table with the information for the current period. Task: 3993175 Forward-Port-Of: odoo/odoo#180288
Original PR description
For the US, it is mandatory to have the accrual gains, usage and balance on the payslip. This adds a new table with the information for the current period. Task: 3993175 Forward-Port-Of: odoo/odoo#180288
On accounts from 14... to 19..., there are current liabilities while they should be non-current libialities. Manual forward-port of #178373 opw-4134510 Forward-Port-Of: odoo/odoo#180446
Original PR description
On accounts from 14... to 19..., there are current liabilities while they should be non-current libialities. Manual forward-port of #178373 opw-4134510 Forward-Port-Of: odoo/odoo#180446
The custom stock.move.line's x2many field computes a domain automatically for the SML that can be selected from the stock.move records (e.g. when trying to find a specific lot, etc. to fulfill a demand). This commit makes it possible to include the domain defined on the field in the final constructed domain, making it possible to somewhat customize this behaviour without the need for a js override. Task-4116000 ----------- Example of customization made possible with this: Have a com
Original PR description
The custom stock.move.line's x2many field computes a domain automatically for the SML that can be selected from the stock.move records (e.g. when trying to find a specific lot, etc. to fulfill a demand).
This commit makes it possible to include the domain defined on the field in the final constructed domain, making it possible to somewhat customize this behaviour without the need for a js override.
Task-4116000
-----------
Example of customization made possible with this:
Have a computed field `x_allowed_lot_ids` on the stock.move and restrict the selection of the lots to this domain by modifying the view `stock.view_stock_move_operations`:
```xml
<field name="move_line_ids" domain="[('lot_id', 'in', x_allowed_lot_ids)]" [...] widget="sml_x2_many"/>
```
without this commit, the `domain` attribute set on the field is simply ignored and it would require a more complex js custo (we could live with it)
Forward-Port-Of: odoo/odoo#180421This commit will remove the readonly constraint on the journal when an account move has been posted. task: 4028973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180266 Forward-Port-Of: odoo/odoo#171710
Original PR description
This commit will remove the readonly constraint on the journal when an account move has been posted. task: 4028973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180266 Forward-Port-Of: odoo/odoo#171710
This commit will set the deferred accounts for spain template. task: 4181499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180004
Original PR description
This commit will set the deferred accounts for spain template. task: 4181499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180004
Steps to reproduce: Create 2 products with a product tag (ex. '3+1') Create Buy X Get Y reward. In the conditional rules choose: - in the 'among' section the product tag '3+1', - in the 'grant' 1 point per unit paid In the rewards choose: - reward type as 'Free product' - in exchage of 3 points - in the 'among' section the product tag '3+1' Go to /shop page and add 3 products with the tag '3+1' Try to click on the button 'Free product'
Original PR description
Steps to reproduce:
Create 2 products with a product tag (ex. '3+1')
Create Buy X Get Y reward.
In the conditional rules choose:
- in the 'among' section the product tag '3+1',
- in the 'grant' 1 point per unit paid
In the rewards choose:
- reward type as 'Free product'
- in exchage of 3 points
- in the 'among' section the product tag '3+1'
Go to /shop page and add 3 products with the tag '3+1'
Try to click on the button 'Free product'
The reward is not applied
Reason:
In the claim_reward function a reward is not applied if it is a multi_product one.
Fix:
added a dropdown on template that will allow user to select product. the selected product will be sent to backend and processed in claim_reward function
Task : 3774033
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#180224
Forward-Port-Of: odoo/odoo#164868Problem was we try to get partner from `order.partner` instead of `order.partner_id` Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4180894 Forward-Port-Of: odoo/enterprise#70239
Original PR description
Problem was we try to get partner from `order.partner` instead of `order.partner_id` Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4180894 Forward-Port-Of: odoo/enterprise#70239
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the 1st account, select 'Account Receivable' (e.g., 121000 Account Receivable). - Set the Partner field to "0h3n-abcdefg@yahoo.example.com" and the label field to "Online transfer reced agst INV-00171, Dt:01.08.2024". - For the 2nd account, set it to any other type, such as "101401 Bank". - Add
Original PR description
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the…
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the 1st account, select 'Account Receivable' (e.g., 121000 Account Receivable). - Set the Partner field to "0h3n-abcdefg@yahoo.example.com" and the label field to "Online transfer reced agst INV-00171, Dt:01.08.2024". - For the 2nd account, set it to any other type, such as "101401 Bank". - Add a credit amount in the 'Account Receivable' and the same amount in the 2nd account. - Save and post the transaction. - Navigate to the general ledger. - Ensure you expand the list of this newly created account move under the 121000 Account Receivable to observe overlapping text. - Click on 'PDF' and print the report. - Notice the overlapping text.  Cause of the issue ================== The o_overflow_value class is only applied when the cell value length is longer than 65 chars Solution =======  Here are the differences, only the following lines are pushed down  opw-4130917 Forward-Port-Of: odoo/enterprise#70141
Steps to reproduce (on IOS): ------------------- With Safari browser: - Install `Meeting Rooms` app - Go to Meeting Rooms -> Rooms and open any room - Copy the `Room Booking URL` and open it in a new tab - Click on the menu, then on `Add to Home Screen` - Open the room booking from the home screen Issue: ------ The URL and browser buttons are visible at the top of the screen. Solution: --------- Add the meta tags `mobile-web-app-capable` and `apple-mobile-web-app-capable`
Original PR description
Steps to reproduce (on IOS): ------------------- With Safari browser: - Install `Meeting Rooms` app - Go to Meeting Rooms -> Rooms and open any room - Copy the `Room Booking URL` and open it in a new tab - Click on the menu, then on `Add to Home Screen` - Open the room booking from the home screen Issue: ------ The URL and browser buttons are visible at the top of the screen. Solution: --------- Add the meta tags `mobile-web-app-capable` and `apple-mobile-web-app-capable` to the room template. opw-3639196 Forward-Port-Of: odoo/enterprise#67944
For the US, it is mandatory to have the accrual gains, usage and balance on the payslip. This adds a new table with the information for the current period. Task: 3993175 Forward-Port-Of: odoo/enterprise#66563
Original PR description
For the US, it is mandatory to have the accrual gains, usage and balance on the payslip. This adds a new table with the information for the current period. Task: 3993175 Forward-Port-Of: odoo/enterprise#66563
This commit's purpose is to force the use of the widget 'taskWithHours' when the timesheet timer is launched. Previously, this was done through the xml by setting the 'type' attribute. This is no longer an option, so instead, we update the arguments given in the getPropertyFieldInfo method on the js side with the type we need. task - 4166816 affected version saas-17.2 - master Forward-Port-Of: odoo/enterprise#69663
Original PR description
This commit's purpose is to force the use of the widget 'taskWithHours' when the timesheet timer is launched. Previously, this was done through the xml by setting the 'type' attribute. This is no longer an option, so instead, we update the arguments given in the getPropertyFieldInfo method on the js side with the type we need. task - 4166816 affected version saas-17.2 - master Forward-Port-Of: odoo/enterprise#69663
Since the fiscal position is added in data with the xml, the others companies than the current ones don't have it. So this commit will allow: - When installing the Avatax modules, create the fiscal position in all US companies at the same time - When creating a new US company with the Avatax module installed, setup the fiscal position in the new company at the same time task: 4100725 Forward-Port-Of: odoo/enterprise#69204
Original PR description
Since the fiscal position is added in data with the xml, the others companies than the current ones don't have it. So this commit will allow: - When installing the Avatax modules, create the fiscal position in all US companies at the same time - When creating a new US company with the Avatax module installed, setup the fiscal position in the new company at the same time task: 4100725 Forward-Port-Of: odoo/enterprise#69204
A new dependency has been introduced by mistake. Even if it still makes sense from a functional point of view, this modification wasn't respecting our stable policy and thus should be reverted. Error introduced at https://github.com/odoo/enterprise/pull/63481 Forward-Port-Of: odoo/enterprise#70173
Original PR description
A new dependency has been introduced by mistake. Even if it still makes sense from a functional point of view, this modification wasn't respecting our stable policy and thus should be reverted. Error introduced at https://github.com/odoo/enterprise/pull/63481 Forward-Port-Of: odoo/enterprise#70173