Tuesday, July 2, 2024
42 changes · saas-17.3
Resolved issues and error corrections
Invoices created from Point of Sale now keep product names out of the invoice line description field. This ensures the description shows only the custom product description, making invoices clearer and consistent with the updated invoice layout.
Original PR description
Description of the issue this commit addresses: Since the redesign of the description column of the invoice lines, that column is not supposed to contain the name of the product anymore. At the moment, the computation of the line name still uses it in the PoS. Referenced commit is: https://github.com/odoo/odoo/pull/152869/commits/216634fd048c568d5b398134ba948a301bf76e3c --- Desired behavior after the commit is merged: When creating an invoice from the PoS, the invoice lines' description only contain the custom description of the product and not the name of the product. --- task-4013483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several internal web testing tools so they better match real application behavior, including correct view styling, date-time checks, relationship handling, and breadcrumb loading. This helps reduce misleading test results and improves confidence in future web changes without directly affecting end users.
The task form no longer shows an inactive analytic account warning when timesheets are not enabled. This prevents users from seeing a confusing message in cases where timesheet tracking is not being used.
Original PR description
Following odoo/odoo@79e3e783dc05, the warning for inactive analytic account was moved from the `Timesheet` page to the form top but miss the same invisible attrs as the page. This commit hide the warning as well when the `Timesheet` option is disable (when there is no project, that option is also considered disabled). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated Point of Sale dashboard test so it works with the updated demo data. The change helps keep release checks reliable and reduces false test failures without affecting day-to-day user workflows.
Original PR description
Since the refactoring of demo data, the initial kanban view of the pos dashboard contain different choice of demo. This commit fixes the test by changing the test to be compatible with the new demo data. RB error: 66009, 67126
Subscription invoices now show only the product's custom description on invoice lines, without repeating the product name. This keeps invoice wording consistent with the updated invoice layout and makes customer-facing documents clearer.
Original PR description
... in Subscriptions --- Description of the issue this commit addresses: Since the redesign of the description column of the invoice lines, that column is not supposed to contain the name of the product anymore. At the moment, the computation of the line name still uses it in the subscription app. Referenced commit is: https://github.com/odoo/odoo/pull/152869/commits/216634fd048c568d5b398134ba948a301bf76e3c --- Desired behavior after the commit is merged: When creating an invoice for a subscription, the invoice lines' description only contain the custom description of the product and not the name of the product. --- task-4013483
Miscellaneous changes
In commit [1], the `o-map-omit` SCSS function has been modified in order to fix the values of CSS variables that would have been wrongly set to `'True'` or `'False'`, instead of boolean `true` and `false`. However, the issue only happened in "website", so the code should not have been added in this function which is located in the "web" module, because it is really website-specific. This commit moves this fix in the website `o-map-force-nulls` function instead. [1]: https://github.com/odoo
Original PR description
In commit [1], the `o-map-omit` SCSS function has been modified in order to fix the values of CSS variables that would have been wrongly set to `'True'` or `'False'`, instead of boolean `true` and `false`. However, the issue only happened in "website", so the code should not have been added in this function which is located in the "web" module, because it is really website-specific. This commit moves this fix in the website `o-map-force-nulls` function instead. [1]: https://github.com/odoo/odoo/commit/e01b861b89546ab5d7b5ce8269b06e9b7a845835 Related to opw-3957157 Forward-Port-Of: odoo/odoo#171312
Here the error was due to timezone differences, so a frozentime wouldn't act indifferent irrespective of timezone. Also the isCheck is required in tour because a default run function is generated for every tour step for the specific I changed it is click. It is currently not affecting the tour because the tour is run with no delay. task-4004285 Forward-Port-Of: odoo/odoo#170476
Original PR description
Here the error was due to timezone differences, so a frozentime wouldn't act indifferent irrespective of timezone. Also the isCheck is required in tour because a default run function is generated for every tour step for the specific I changed it is click. It is currently not affecting the tour because the tour is run with no delay. task-4004285 Forward-Port-Of: odoo/odoo#170476
We should add the price_unit via a `t-out` attribute, using a condition inside, rather than trying to use `t-if`. This was missed in resolving fw-port issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171439 Forward-Port-Of: odoo/odoo#171041
Original PR description
We should add the price_unit via a `t-out` attribute, using a condition inside, rather than trying to use `t-if`. This was missed in resolving fw-port issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171439 Forward-Port-Of: odoo/odoo#171041
Problem: Placeholders were added in 17.0 to be used when switching to Studio mode. However, this placeholder will appear on the printed report if the `res.partner` has no name. Creating a `Delivery Address` for a `res.partner` does not require a name due to its type. Purpose: Hide this placeholder in cases were `Delivery Address` record does not have a `name` set. Steps to Reproduce: 1) Enable `Signatures` for deliveries 2) Create a new `Delivery Address` with no `name` for an existing `
Original PR description
Problem: Placeholders were added in 17.0 to be used when switching to Studio mode. However, this placeholder will appear on the printed report if the `res.partner` has no name. Creating a `Delivery Address` for a `res.partner` does not require a name due to its type. Purpose: Hide this placeholder in cases were `Delivery Address` record does not have a `name` set. Steps to Reproduce: 1) Enable `Signatures` for deliveries 2) Create a new `Delivery Address` with no `name` for an existing `res.partner` record 3) Create a SO -> confirm -> sign delivery 4) Print `Delivery Slip` opw-3988100 Forward-Port-Of: odoo/odoo#171305
Versions -------- - saas-17.1+ Steps ----- 1. Have Appointments installed; 2. go to Appointments / Configuration / Resource Leaves; 3. create a new Resource Time Off; 4. use the daterange widget to select a start & end date. Issue ----- No matter which end date you select, it will be on the same day as the start date. Cause ----- Commit bc2ea5fb6d12dc3e6c09c36c7bdc48276fb7960a modified the `resource_calendar_leave_form` to use the `daterange` widget for the `date_from` & `dat
Original PR description
Versions -------- - saas-17.1+ Steps ----- 1. Have Appointments installed; 2. go to Appointments / Configuration / Resource Leaves; 3. create a new Resource Time Off; 4. use the daterange widget to…
Versions -------- - saas-17.1+ Steps ----- 1. Have Appointments installed; 2. go to Appointments / Configuration / Resource Leaves; 3. create a new Resource Time Off; 4. use the daterange widget to select a start & end date. Issue ----- No matter which end date you select, it will be on the same day as the start date. Cause ----- Commit bc2ea5fb6d12dc3e6c09c36c7bdc48276fb7960a modified the `resource_calendar_leave_form` to use the `daterange` widget for the `date_from` & `date_to` fields. As a consequence, selecting any `date_from` value triggers the `_compute_date_to` method, overriding the `date_to` field selected by the datepicker. Solution -------- If the leave has a `date_to` value, and it is valid (i.e. not earlier than `date_from`), don't recompute the value. Also fixed an issue computing the `date_to` field by actually converting the `date_from` value to the user's tz: - `user_tz.localize(date_from)` only adds `tzinfo`, it doesn't change the values from UTC. - As a consequence, if `date_from` is '2024-05-01 23:00:00' with user tz Europe/Brussels, the compute method will set hh:mm:ss of `date_to` to '23:59:59', then convert it to UTC, so '21:59:59', which is before `date_from`, causing to a validation error. - Instead, '2024-05-01 23:00:00' should first get converted to local time '2024-05-02 01:00:00', so that `date_to` gets set correctly to '2024-05-02 21:59:59' UTC. opw-3910990 Forward-Port-Of: odoo/odoo#167024
## Description: navigateTo helper function in helpers.js was not passing the context to the action. This commit resolves the problem by ensuring the context is properly passed to the action. task-3880304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164872
Original PR description
## Description: navigateTo helper function in helpers.js was not passing the context to the action. This commit resolves the problem by ensuring the context is properly passed to the action. task-3880304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164872
Avoid the installation of Odoo windows version in unsafe places. Forward-Port-Of: odoo/odoo#170356
Original PR description
Avoid the installation of Odoo windows version in unsafe places. Forward-Port-Of: odoo/odoo#170356
Steps to reproduce the issue: - Create a storable product “P1” with a BoM: - Component: Select any component - Work order: OP1: 60 minutes in workcenter “Assembly Line 1” - Go to workcenter “Assembly Line 1”: - Specific capacities: P1, capacity: 1, setup: 10 minutes - Alternative workcenter: “Assembly Line 2”: - Specific capacities: P1, capacity: 1, setup: 5 minutes - Create a manufacturing order “MO1” to produce 1 unit: - Date: May 10, 2024, 08:00:00 -
Original PR description
Steps to reproduce the issue:
- Create a storable product “P1” with a BoM:
- Component: Select any component
- Work order: OP1: 60 minutes in workcenter “Assembly Line 1”
- Go to workcenter “Assembly Line 1”:
- Specific capacities: P1, capacity: 1, setup: 10 minutes
- Alternative workcenter: “Assembly Line 2”:
- Specific capacities: P1, capacity: 1, setup: 5 minutes
- Create a manufacturing order “MO1” to produce 1 unit:
- Date: May 10, 2024, 08:00:00
- Create a manufacturing order “MO2” to produce 1 unit:
- Date: May 10, 2024, 08:00:00
Issue:
- After confirming and planning MO1, the expected duration is 70 minutes.
- After confirming and planning MO2, the expected duration is 75 minutes
instead of 65.
The setup time of workcenter Assembly Line 1 for specific product is not
reduced from the expected time.
opw-3904023
Forward-Port-Of: odoo/odoo#170633
Forward-Port-Of: odoo/odoo#165128__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit, refusing a parent allocation would refuse the children allocation, and validating it again would still create new children regardless. This behaviour is reminescent from the draft state which was the only way to modify an allocation __Reproduce the issue:__ - Create a multiple-employee allocation - Va
Original PR description
__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit,…
__Explanation of the issue:__ Creating an allocation for multiple employees create children allocations for each individual employee concerned by that allocation. However, before this commit, refusing a parent allocation would refuse the children allocation, and validating it again would still create new children regardless. This behaviour is reminescent from the draft state which was the only way to modify an allocation __Reproduce the issue:__ - Create a multiple-employee allocation - Validate it - Refuse it - Validate it again - Refuse it again - An error should appear, saying: "Allocation request must be confirmed or validated in order to refuse it." __How the issue was fixed:__ This commit synchronizes both parent and children allocations upon the write of the parent one, which will also update the children. Additionally, validating those parent allocations will now check if children allocations are present beforehand to avoid duplicating them. task-3935358 Forward-Port-Of: odoo/odoo#169731 Forward-Port-Of: odoo/odoo#165990
The font-awesome icons taking the `.btn` font-size was making them 14px while the other icons in the web_editor are 12px (eg. the svg ones) It creates an overflow on the #toolbar creating on some screensize an horizontal overflow. This commit applies a font size of 12px on the .fa inside the `#toolbar`. Additionally the createlink was not receiving the border radius rule due to the `#unlink` element being present in the DOM but invisible on screen after the create-link el. Swapping their o
Original PR description
The font-awesome icons taking the `.btn` font-size was making them 14px while the other icons in the web_editor are 12px (eg. the svg ones) It creates an overflow on the #toolbar creating on some screensize an horizontal overflow. This commit applies a font size of 12px on the .fa inside the `#toolbar`. Additionally the createlink was not receiving the border radius rule due to the `#unlink` element being present in the DOM but invisible on screen after the create-link el. Swapping their order in the xml and using the class `order-1` solve the issue without impacting the backend editor. task-3634260 Part of task-3503975 Forward-Port-Of: odoo/odoo#136806
Issue: ====== Image and icons changes and dropped snippets are not autosaved, changes are lost when you switch tab. Steps to reproduce the issue: ============================= For Image and icon: - Go to email marketing - Choose a template with an image - Update the image and click on another tab directly (A/B tests for example) - Go back to mail body tab, the changes are not saved For dropped snippets: - Go to email marketing - Choose any template - Click on another tab (A/
Original PR description
Issue: ====== Image and icons changes and dropped snippets are not autosaved, changes are lost when you switch tab. Steps to reproduce the issue: ============================= For Image and icon: -…
Issue: ====== Image and icons changes and dropped snippets are not autosaved, changes are lost when you switch tab. Steps to reproduce the issue: ============================= For Image and icon: - Go to email marketing - Choose a template with an image - Update the image and click on another tab directly (A/B tests for example) - Go back to mail body tab, the changes are not saved For dropped snippets: - Go to email marketing - Choose any template - Click on another tab (A/B tests for example) - Go back to meil body tab - Add snippet click directly on another tab - Go back to mail body tab , the changes are not saved Origin of the issue: ==================== For Image and Icon: When we open the image media dialog, `_onWysiwygBlur` is called which means we lost the focus from the editable view. Old updates are saved because we call `commitChanges` but the updates after the change of the image are not since we lost the focus of the wysiwyg. Switching to another tab will not trigger `blur` event again so we loose the changes. (same flow for icon change). For dropped snippets: The first switch of tabs will trigger the blur event and will commit changes. When we switch again to the mail body tab, the focus isn't on the editable, we drop the snippet , still no focus on the editable so no `blur` event is called and we loose the changes again. We call `commitChanges` on `onWillUnmount` but we don't pass the paremeters from `mass_mailing_html_field` to its parent class so we loose the `urgent` flag which is responsible to save the data before destroying the component. Passing just the args in `commitChanges` will produce another issue about `Component is destroyed`. To have a minimal change in stable we just refocus on the wysiwyg on the mentioned 2 cases so the updates will be applied when blurring the `wysiwyg` Solution: ========= Put the focus again in the editor's window. Forward-Port-Of: odoo/odoo#171142 Forward-Port-Of: odoo/odoo#167753
**Steps to reproduce the bug:** - Parent company: CompanyA with a purchase tax of “15%” - Create a branch from Company - select only the brunch as current company - Create a storable product P1: - Add vendor: Azure Interior, price: $10 per unit - Create a recording rule: - Trigger: Manual - Route: Buy - Minimum quantity: 10 - save - Click on order **Problem**: A purchase order is created with Azure Interior as the vendor and 10 units
Original PR description
**Steps to reproduce the bug:**
- Parent company: CompanyA with a purchase tax of “15%”
- Create a branch from Company
- select only the brunch as current company
- Create a storable product P1:
- Add vendor: Azure Interior, price: $10 per unit
- Create a recording rule:
- Trigger: Manual
- Route: Buy
- Minimum quantity: 10
- save
- Click on order
**Problem**:
A purchase order is created with Azure Interior as the vendor and 10 units of P1, but the tax is not set. This happens because when the PO line values are prepared, the tax is retrieved from the supplier tax, but it is filtered by the current company, So only the branch taxes. However, it should also check in the parent company.
opw-3937178
Forward-Port-Of: odoo/odoo#171052
Forward-Port-Of: odoo/odoo#169635Since the automation revamp, it is not possible to update read-only fields without executing Python code. This commit removes this limitation as some use-cases are useful: - Automatically update the invoice status of SO when an action is executed. - Force the SO status to "sent" without sending the email. Task: 3983645 Forward-Port-Of: odoo/odoo#170729
Original PR description
Since the automation revamp, it is not possible to update read-only fields without executing Python code. This commit removes this limitation as some use-cases are useful: - Automatically update the invoice status of SO when an action is executed. - Force the SO status to "sent" without sending the email. Task: 3983645 Forward-Port-Of: odoo/odoo#170729
## Description The `web_read_group` done when loading the "All Applicants" view is slow when having a large quantity of `hr.applicant` ## Analysis The query done by the `web_read_group` will get all the `active` `hr.applicant`, but the field isn't indexed, so even if only a small portion of applicants are active, we are still scanning the whole table to filter out the applicants. ## Solution Index the `active` field. ## Benchmark On a DB with 900k `hr_applicant`, where only 80k are
Original PR description
## Description The `web_read_group` done when loading the "All Applicants" view is slow when having a large quantity of `hr.applicant` ## Analysis The query done by the `web_read_group` will get all the `active` `hr.applicant`, but the field isn't indexed, so even if only a small portion of applicants are active, we are still scanning the whole table to filter out the applicants. ## Solution Index the `active` field. ## Benchmark On a DB with 900k `hr_applicant`, where only 80k are `active`, the main query for the `web_read_group` takes | | Before | After | |---------|--------|-------| | Timings | 320ms | 80ms | ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171000
When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it
Original PR description
When using base.automation a timed condition using a calendar, the check was done for each record to get the datetime with the delay using the calendar. Now we invert the logic instead of adding the delay to the record in a loop datetime field, we substract from the last_run and now once outside of the loop. It goes from this logic: last_run <= record_dt + delay < now to this: last_run - delay <= record_dt < now - delay In a database with 1000 records to check a single calendar: it went from 15s to 20ms opw-3876867 https://github.com/odoo/enterprise/pull/65417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171270 Forward-Port-Of: odoo/odoo#167310
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differenciate fixed taxes from other and adapt display accordingly. see https://github.com/odoo/odoo/pull/168638 task-3964942 Forward-Port-Of: odoo/odoo#168634
Original PR description
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differenciate fixed taxes from other and adapt display accordingly. see https://github.com/odoo/odoo/pull/168638 task-3964942 Forward-Port-Of: odoo/odoo#168634
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historySt
Original PR description
Steps to reproduce: 1. Go to website > Edit 2. Drag and drop 'Banner' snippet and 'Items' snippet > Save 3. Repeat the step 2 again 4. Error will be generated in terminal Current behavior before PR: Dropping and saving new snippets immediately after snippets containing links would generate a traceback. This issue occurred because the `callPostSnippetDrop` had not completed execution, and `cleanForSave`, responsible for removing `zwnbsp` was called prematurely. Consequently `historyStep` after `callPostSnippetDrop` would reintroduce `zwnbsp` to links. Desired behavior after PR is merged: Ensure that all post-snippet drop promises are resolved before saving. task-3954229 Forward-Port-Of: odoo/odoo#171068 Forward-Port-Of: odoo/odoo#167365
**Description of the issue/feature this PR addresses:** The field condition is used but it is not show in any view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169077
Original PR description
**Description of the issue/feature this PR addresses:** The field condition is used but it is not show in any view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169077
Currently, you cannot merge partners if they have bank accounts linked to payments. ### Steps to reproduce * Install the `account` module. * Create two partners having the same bank account number. * Create and post payments for each of those partners. * Attempt to merge those partners. You should be met with the following message: ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Journal Entry (accoun
Original PR description
Currently, you cannot merge partners if they have bank accounts linked to payments. ### Steps to reproduce * Install the `account` module. * Create two partners having the same bank account number. *…
Currently, you cannot merge partners if they have bank accounts linked to payments. ### Steps to reproduce * Install the `account` module. * Create two partners having the same bank account number. * Create and post payments for each of those partners. * Attempt to merge those partners. You should be met with the following message: ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Journal Entry (account.move) Constraint: account_move_partner_bank_id_fkey ``` ### Cause When merging partners, the system attempts to update all foreign keys referencing the partners being merged. In certain circumstances, this update violates unicity constraints. In such cases, the system simply deletes the records that can't be updated. In our case, the `res_partner_bank` table has the following unicity constraint: `unique(sanitized_acc_number, partner_id)`. When we merge the two partners and the system attempts to update the `partner_id` field on `res_partner_bank`, the constraint is violated because both partners originally had the same account number. The system then tries to delete those bank accounts, but it fails because they are linked to payments (with an `ondelete restrict` clause). ### Fix Identify the bank accounts that are duplicated between the source and destination partners, and merge them before merging the partners. opw-3925952 Forward-Port-Of: odoo/odoo#169800
This commit fixes two things: 1- Allow for importing V3.2.2 Factura-E. 2- While importing, if the customer doesn't exist in our database, we create it. The country and the VAT were never set correctly as the country code is in three letter format in the XML and two letter format in Odoo. task-4011534 Forward-Port-Of: odoo/odoo#170744
Original PR description
This commit fixes two things: 1- Allow for importing V3.2.2 Factura-E. 2- While importing, if the customer doesn't exist in our database, we create it. The country and the VAT were never set correctly as the country code is in three letter format in the XML and two letter format in Odoo. task-4011534 Forward-Port-Of: odoo/odoo#170744
Steps --- * create MO * confirm > produce all * unlock > set produced quantity to 0 * click 'Overview' => Traceback (zero div) Fix --- set overview fields that do not make sense when the final production quantity is 0 to `False`, so they are left blank on the report opw-3958811 Forward-Port-Of: odoo/odoo#168529
Original PR description
Steps --- * create MO * confirm > produce all * unlock > set produced quantity to 0 * click 'Overview' => Traceback (zero div) Fix --- set overview fields that do not make sense when the final production quantity is 0 to `False`, so they are left blank on the report opw-3958811 Forward-Port-Of: odoo/odoo#168529
Use of the record.{field}.value was causing the displayed (string) values to be used in the kanban card's t-if logic rather than the actual value of the field. This resulted in - `record.cap_accrued_time.value` ALWAYS being evaluated as True (since "False" is True) - `record.maximum_leave.value > 0` evaluating as True when the language wasn't a language that uses "." as it's decimal separator. e.g. "5.00" > 0 == True but "5,00" > 0 == False opw-3999753 Also, re-export the po
Original PR description
Use of the record.{field}.value was causing the displayed (string) values
to be used in the kanban card's t-if logic rather than the actual value
of the field. This resulted in
- `record.cap_accrued_time.value` ALWAYS being evaluated as True (since
"False" is True)
- `record.maximum_leave.value > 0` evaluating as True when the language
wasn't a language that uses "." as it's decimal separator. e.g.
"5.00" > 0 == True but "5,00" > 0 == False
opw-3999753
Also, re-export the pot file since it was noticed that it's no longer correct.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171394
Forward-Port-Of: odoo/odoo#170321When you take a time off for which there is no need of validation, you can refuse it, although you don't have any time off rights. This fixes the issue, you have to be either a time off officer or the manager of the one who took the time off. Task: 3981373 Forward-Port-Of: odoo/odoo#170514
Original PR description
When you take a time off for which there is no need of validation, you can refuse it, although you don't have any time off rights. This fixes the issue, you have to be either a time off officer or the manager of the one who took the time off. Task: 3981373 Forward-Port-Of: odoo/odoo#170514
According to the documentation, the user receives their registration code through SMS, so phone number label is misleading. Steps to reproduce: 1.Install account_peppol > install an peppol egilible accounting l10n (i.e l10n_be) 2.In settings > technical > system parameter > set account_peppol.edi.mode to test 2.in settings search for peppol 3.notice how the phone number is requested in the registration form 4.click on validate registration 5.notice how the validation button displays
Original PR description
According to the documentation, the user receives their registration code through SMS, so phone number label is misleading.
Steps to reproduce:
1.Install account_peppol > install an peppol egilible accounting l10n (i.e l10n_be)
2.In settings > technical > system parameter > set account_peppol.edi.mode to test
2.in settings search for peppol
3.notice how the phone number is requested in the registration form
4.click on validate registration
5.notice how the validation button displays "verify phone number" while the verification code is sent by sms
Solution:
refactor labels, buttons, helps and errors message to indicate mobile number. The actual field account_peppol_phone_number is not renamed as per stable version changes condition.
opw-3977664
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#170870
Forward-Port-Of: odoo/odoo#169607## Description Following a1bc13b39559fa82763a9f0b3b603f6026b8a151 the field `One2many: applicant_ids` becomes `Many2one: applicant_id`. The field is used in lookups (ir.rules) and is also the inverse of `hr.applicant.response_ids`, and is present on the model `survey.user_input`, which is a large table, therefor should be indexed. ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170918
Original PR description
## Description Following a1bc13b39559fa82763a9f0b3b603f6026b8a151 the field `One2many: applicant_ids` becomes `Many2one: applicant_id`. The field is used in lookups (ir.rules) and is also the inverse of `hr.applicant.response_ids`, and is present on the model `survey.user_input`, which is a large table, therefor should be indexed. ## Reference task-4011294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170918
Current behaviour: --- Product name can overflow from the label box Expected behaviour: --- Truncate the name if it's too long Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/o
Original PR description
Current behaviour: --- Product name can overflow from the label box Expected behaviour: --- Truncate the name if it's too long Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/a5924bfe11cd9324e2ba056e0ac1d449aed730c8 Fix: --- Reverting: https://github.com/odoo/odoo/commit/a5924bfe11cd9324e2ba056e0ac1d449aed730c8 opw-3819349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169226
Before this commit: The content of list view is empty, the outline of the `<thead>` tag (the line below the first `<tr>` inside `<thead>`) would disappear, means its opacity reduced. After this commit: This commit fixes the issue by ensuring that the outline of the `<thead>` tag remains visible even when the list view is empty. task - 3834758 Forward-Port-Of: odoo/odoo#163715
Original PR description
Before this commit: The content of list view is empty, the outline of the `<thead>` tag (the line below the first `<tr>` inside `<thead>`) would disappear, means its opacity reduced. After this commit: This commit fixes the issue by ensuring that the outline of the `<thead>` tag remains visible even when the list view is empty. task - 3834758 Forward-Port-Of: odoo/odoo#163715
The Odoo Menu linked to the graphs would not be duplicated on sheet duplication. task-3810369 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#171336 Forward-Port-Of: odoo/odoo#167964
Original PR description
The Odoo Menu linked to the graphs would not be duplicated on sheet duplication. task-3810369 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#171336 Forward-Port-Of: odoo/odoo#167964
task-3754591 Forward-Port-Of: odoo/odoo#171390
Original PR description
task-3754591 Forward-Port-Of: odoo/odoo#171390
Removed dependency on demo data for the TestInvoiceExtractPurchase tests, as they would previously fail if the demo data had not been loaded. Now the results will be consistent, no matter if the demo data is present. Task-3957718 Forward-Port-Of: odoo/enterprise#65805 Forward-Port-Of: odoo/enterprise#65660
Original PR description
Removed dependency on demo data for the TestInvoiceExtractPurchase tests, as they would previously fail if the demo data had not been loaded. Now the results will be consistent, no matter if the demo data is present. Task-3957718 Forward-Port-Of: odoo/enterprise#65805 Forward-Port-Of: odoo/enterprise#65660
## Description: Clicking the "Insert in Spreadsheet" button within the pivot view previously failed to pass the necessary context, leading to a traceback. This PR resolves the problem by ensuring the context is properly passed to the action. Task ID: [3880304](https://www.odoo.com/web#id=3880304&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61230
Original PR description
## Description: Clicking the "Insert in Spreadsheet" button within the pivot view previously failed to pass the necessary context, leading to a traceback. This PR resolves the problem by ensuring the context is properly passed to the action. Task ID: [3880304](https://www.odoo.com/web#id=3880304&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61230
Avoid to check calendar for each record. Follows the logic of the community PR: https://github.com/odoo/odoo/pull/167310 Forward-Port-Of: odoo/enterprise#65770 Forward-Port-Of: odoo/enterprise#65417
Original PR description
Avoid to check calendar for each record. Follows the logic of the community PR: https://github.com/odoo/odoo/pull/167310 Forward-Port-Of: odoo/enterprise#65770 Forward-Port-Of: odoo/enterprise#65417
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. see https://github.com/odoo/odoo/pull/168638 task-3964942 Forward-Port-Of: odoo/enterprise#65385
Original PR description
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. see https://github.com/odoo/odoo/pull/168638 task-3964942 Forward-Port-Of: odoo/enterprise#65385
When a contact is created with an RFC (VAT number) but no country configured, signing an invoice for that contact results in the invoice being signed correctly. However, the PDF shows the partner's RFC, while the XML file shows the generic RFC (XAXX01010101). This discrepancy misleads users into believing their setup is correct, as no error or alert is provided. This commit introduces a non-blocking warning message in the 'Send and Print' wizard for cases where the contact's country is missin
Original PR description
When a contact is created with an RFC (VAT number) but no country configured, signing an invoice for that contact results in the invoice being signed correctly. However, the PDF shows the partner's RFC, while the XML file shows the generic RFC (XAXX01010101). This discrepancy misleads users into believing their setup is correct, as no error or alert is provided. This commit introduces a non-blocking warning message in the 'Send and Print' wizard for cases where the contact's country is missing. opw-3891896 Forward-Port-Of: odoo/enterprise#63255
This commit fixes an issue withthe embedded views inside the columns block in the editor. The embedded views were overlapping the columns on their right meaning that some text could be hidden behind them. To fix this a new rule is added to these blocks so that when they are inside a column block that is not the last one we remove the negative margin-right. This way we preserve their style when inside the right-most column. task-3901864 Forward-Port-Of: odoo/enterprise#63480
Original PR description
This commit fixes an issue withthe embedded views inside the columns block in the editor. The embedded views were overlapping the columns on their right meaning that some text could be hidden behind them. To fix this a new rule is added to these blocks so that when they are inside a column block that is not the last one we remove the negative margin-right. This way we preserve their style when inside the right-most column. task-3901864 Forward-Port-Of: odoo/enterprise#63480
When a document has an attachment, the export done through the general ledger and "Datev + ATCH (zip)" should have a column filled with the guid of the document, which is not the case currently. To solve it, use the helper to get the attachments opw-3984450 Forward-Port-Of: odoo/enterprise#65756
Original PR description
When a document has an attachment, the export done through the general ledger and "Datev + ATCH (zip)" should have a column filled with the guid of the document, which is not the case currently. To solve it, use the helper to get the attachments opw-3984450 Forward-Port-Of: odoo/enterprise#65756
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627 Forward-Port-Of: odoo/enterprise#64538
Original PR description
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627 Forward-Port-Of: odoo/enterprise#64538