Wednesday, February 3, 2021
19 changes · master
Enhancements to existing features
The contact form layout now keeps sales-related information together by moving the delivery carrier field away from the salesperson and sales team fields. This makes the form easier to scan and helps users find related sales details more quickly.
Original PR description
This commit keeps the sales related fields together in a contact form view by moving 'property_delivery_carrier_id' field out of in between 'user_id' (Sales Person) and 'team_id' (Sales Team). Task Id : 2445997
Email, phone, and website fields now only respond when users click the actual text, not the empty space beside it. This prevents accidental actions like opening an email client or dialing prompt while preserving long-text display behavior.
Original PR description
As the clickable area issue is also found in URL widget same as email widget we solved the issue by wrapping the anchor tag within a container div tag. Here, the overflow class will be on the container div which will do it's job to prevent the long strings from breaking the UI, and the anchor tag being its child, will not be the full width, thus limiting the clickable area. And in this commit some qunit test cases for phone widget is also changed as it is extended from email widget. task-id: 2345974
The system version number has been updated to mark the next alpha release in the master branch. This helps teams and stakeholders clearly identify builds, plan testing, and track progress toward the upcoming release.
The HR appraisal application has been renamed from "Appraisal" to "Appraisals" across the app switcher, menus, and settings. This provides clearer, more consistent wording for users throughout the interface.
Original PR description
PURPOSE Rename the app "Appraisal" into "Appraisals" Everywhere! App Switcher: https://drive.google.com/file/d/1zkZ3C1dE8-yvCUs1ochEcyJ_gL57ImIm/view?usp=drivesdk Appraisals App: https://drive.google.com/file/d/1eBaQOM4a7AIRSJCyL5OlLksIHWECi7Gr/view?usp=drivesdk Appraisals settings: https://drive.google.com/file/d/1P87sBTYN5-BhHVPU7j_CmBulRV5pehtZ/view?usp=drivesdk App => https://drive.google.com/file/d/1YkGI_NQ_NW-TcPIxzeL4V_fF3wHS5wfd/view?usp=drivesdk SPECIFICATIONS all given changes are updated. LINKS PR https://github.com/odoo/enterprise/pull/15422 Task-2414131
The VoIP module’s automated tests were updated to match recent changes that reduce the clickable area for phone, email, and URL fields. This helps ensure the calling interface behaves consistently and avoids accidental clicks in everyday use.
Original PR description
in this commit some test cases for phone-widget in voip is changed. task-id: 2345974
The contact form layout for Mexican electronic invoicing has been adjusted so sales-related information appears together. This makes the form easier to scan and helps users find related sales settings in one place.
Original PR description
This commit keeps the sales related fields together in a contact for view by moving 'l10n_mx_edi_external_trade' field at last, instead of after 'user_id' (Sales Person). Task Id : 2445997
This update adds and refreshes automated checks that protect key Helpdesk, Timesheet, Sales, and Field Service billing flows. It helps ensure the right sales order items are used, prevents invalid timesheet links, and keeps multi-company and billable project behavior reliable.
Original PR description
Purpose ====== The main goal of this PR is to write and update some unit tests about the changes made in Task-2388500, Task-2409761 and Task-2424382 to keep the functional features. ## Helpdesk App…
Purpose ====== The main goal of this PR is to write and update some unit tests about the changes made in Task-2388500, Task-2409761 and Task-2424382 to keep the functional features. ## Helpdesk App ### Determined Sales Order Items in ticket and timesheets When we create a ticket and set a customer who has a Sales Order with product services Sales Order Items ( = Sales Order Lines (SOLs)) then the SOL in the ticket is the one of latest SOLs if it is prepaid service and remaining_hours > 0. Otherwise, the SOL is False. For the timesheets in the ticket, the SOL on these ones are computed as the tasks when the pricing type in the project is equal to "Task Rate". That is, the SOL of each timesheet is the one set on the ticket. ### A timesheet cannot be linked to a task and a ticket A timesheet cannot be linked to a task and a ticket at the same time. Thus, we create a unit test to check if it is the case. ### Miscellaneous - Restore a step in helpdesk tour. ## Field Services App 2 tests have been created to check: - if the 'timesheet_product_required_if_billable_and_timesheets_and_fsm_projects' sql_constraint is raised when we try to erase the timesheet_product_id in billable fsm project. - if the pricing type of fsm project is only defined as "Task Rate". ## Miscellaneous Update the multicompany test, because this test used the project.task.sale.order wizard, this wizard has been removed (because it is unused). task-2439304 Related PR in Community: odoo/odoo#65146
Cohort view exports now use more descriptive file names that include the cohort context and the related model name. This makes downloaded files easier for users to identify, organize, and share without opening them first.
Original PR description
The purpose of this task is to clean up and provide clear export
file names.
Before this commit, When exporting data:
- from a cohort view, the file is named '<model description>Cohort'
After this commit, Name of the different export files as follows:
- for cohort view quick export, the file is named as
'Cohort of <model description> (<model technical name>)'
Task-Id: 2237840
PR: #15579Miscellaneous changes
When changing the bank account by the outstanding account of a payment, invoice's payment_state should be recomputed by the orm. So, when writing `account_id` on the liquidity line, `is_matched` must be recomputed on payment (`_compute_reconciliation_status`). Then, if reconciled to some invoices, `payment_state` must be recomputed as well (`_compute_amount`). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65420
Original PR description
When changing the bank account by the outstanding account of a payment, invoice's payment_state should be recomputed by the orm. So, when writing `account_id` on the liquidity line, `is_matched` must be recomputed on payment (`_compute_reconciliation_status`). Then, if reconciled to some invoices, `payment_state` must be recomputed as well (`_compute_amount`). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65420
Followup to odoo/odoo#65314: turns out there's a bunch of other leave requests in the file which will eventually fall on a weekend, and will likely break due to the new validation in 14.0: - `hr_holidays_sl_al` in March 2021 because April 17th, 2021 is a saturday. - `hr_holidays_cl_mit_2` in June 2021 because June 5th, 2021 is a saturday. - `hr_holidays_sl_vad` in September 2021 because September 25th, 2021 is a saturday. - `hr_holidays_sl_kim` in April 2021 because May 1st, 2021 is a satu
Original PR description
Followup to odoo/odoo#65314: turns out there's a bunch of other leave requests in the file which will eventually fall on a weekend, and will likely break due to the new validation in 14.0: -…
Followup to odoo/odoo#65314: turns out there's a bunch of other leave requests in the file which will eventually fall on a weekend, and will likely break due to the new validation in 14.0: - `hr_holidays_sl_al` in March 2021 because April 17th, 2021 is a saturday. - `hr_holidays_cl_mit_2` in June 2021 because June 5th, 2021 is a saturday. - `hr_holidays_sl_vad` in September 2021 because September 25th, 2021 is a saturday. - `hr_holidays_sl_kim` in April 2021 because May 1st, 2021 is a saturday. - `hr_holidays_sl_kim_2` in March 2021 because July 3rd, 2021 is a saturday. Solution ======== Instead of hard-coding month-days, move to the first monday after the original date e.g. if we were looking for the 20, now get the monday after the 20. In relativedelta terms, `weekday=0` is "the next monday" (inclusive of today) (the `MO` constant is a better alternative but we're not exposing these to safe_eval in the XML import so it's not an option). The date is then formatted inclusive of the month-day rather than hard-coding one. One nit is for the end date: the next wednesday may come before the next monday if we're on TU or WE. So we need to first jump to the next MO *then* to the WE after that, which makes the code a bit longer (and more redundant). Note that this means the end date is now "the wednesday after <the start date>" rather than being a literal 2 days later or whatever. The PR updates all the 1-day and 2-day intervals, it also updates the 3 days inclusive (those over 3 which include start and end dates rather than without) including those updated by #65314 for clarity / coherence of small intervals. Longer intervals are left untouched, although we may eventually want to update them so `number_of_days` computations are more reliable. Redundancy issues ----------------- There are a bunch of redundancies / verbosities which don't seem easy or possible to remove: * While lxml does resolve entities by default it doesn't load DTDs (let alone validate them), aliasing various datetimes & deltas as entities is not an option, not to mention for security reasons we'd rather stop resolving entities entirely than allow custom ones. * While it's possible to define nested safe_eval'd `context` on nodes, the evaluation context for *those* contains neither datetime nor relativedelta, so storing a bunch of constants in the (environment's) context and using that in the expression is not an option either. * Leaving `date_from`/`date_to` off of some records breaks some, possibly because some other field necessary to properly compute *them* is missing @tivisse would you happen to know which off the top of your head (or have an alternate explanation)? Other changes ============= * Removed explicit settings to `number_of_days` and explicit calls to `_compute_number_of_days`, seems redundant and unnecessary as the compute works fine as long as we let it. * While at it, updated the calls to `action_approve`: moved them next to the corresponding record (instead of being on the other side of the file) and used direct references to the subject records rather than complicated searches. * Also updated two leave allocations to be created validated OOTB instead of manually calling action_validate as that's what's being done elsewhere in the file. Forward-Port-Of: odoo/odoo#65380
In a multicompany environment, when a expense is created from the expense email alias, the expense account is computed with SUPERUSER context, so depending on the SUPERUSER set company, we could get a mismatch of expense and employee's company and the account one, wich causes a subsequent error when trying to post the expense. Steps to reproduce: - You should have at least two companies. - The admin will be in company 1 - And the employee will be in company 2 - It should be po
Original PR description
In a multicompany environment, when a expense is created from the expense email alias, the expense account is computed with SUPERUSER context, so depending on the SUPERUSER set company, we could get…
In a multicompany environment, when a expense is created from the expense email alias, the expense account is computed with SUPERUSER context, so depending on the SUPERUSER set company, we could get a mismatch of expense and employee's company and the account one, wich causes a subsequent error when trying to post the expense. Steps to reproduce: - You should have at least two companies. - The admin will be in company 1 - And the employee will be in company 2 - It should be possible to create expenses from email. What are the steps to reproduce your issue? - The employee send the expense to the expenses alias. - The expense is created with the employee's company and the expense product (it doesn't matter if it's the default one). - Add it to an expense report and try to post it. What is the current behavior that you observe? - When we try to post the expense an error raises as the account in the expense is from another company. - The expense account was created with the context of the company the SUPERUSER was in. What would be your expected behavior in this case? - The expense account and taxes should be created with the employee's company context opw-2412436 cc @Tecnativa TT27015 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65369 Forward-Port-Of: odoo/odoo#63188
The payment token name was fixed in two parallel PR that were merged the same day without conflict: https://github.com/odoo/odoo/pull/61844 and https://github.com/odoo/odoo/pull/61888 This commit cleans up the dict of token creation. taskid: 2409461 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62593
Original PR description
The payment token name was fixed in two parallel PR that were merged the same day without conflict: https://github.com/odoo/odoo/pull/61844 and https://github.com/odoo/odoo/pull/61888 This commit cleans up the dict of token creation. taskid: 2409461 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#62593
Example to reproduce: ISSUE 1- Drop the "Cover" snippet and try to remove the background image. Clicking on image button has to be done 3 times to land on the correct result: - First click removes image, but not filter and leaves both buttons checked - Second click removes the filter and unchecks its button. - Third click unchecks the image button. It should be one click to remove image, filter and uncheck both buttons. ISSUE 2- Add background image to "Cover" snippet by setting i
Original PR description
Example to reproduce: ISSUE 1- Drop the "Cover" snippet and try to remove the background image. Clicking on image button has to be done 3 times to land on the correct result: - First click removes…
Example to reproduce: ISSUE 1- Drop the "Cover" snippet and try to remove the background image. Clicking on image button has to be done 3 times to land on the correct result: - First click removes image, but not filter and leaves both buttons checked - Second click removes the filter and unchecks its button. - Third click unchecks the image button. It should be one click to remove image, filter and uncheck both buttons. ISSUE 2- Add background image to "Cover" snippet by setting image url in 'Add URL' input => background removed. 1- When trying to enable the option 'bg_filter_toggle_opt' after a click on image button, the 'getBgImageURL()' returns '/' as a valid background url since converting to relative url [fullURL.href.slice(fullURL.origin.length)] returns '/[search][hash]' as result; 2- The override for '_applyOptions()' method in 'BackgroundOptimize' will always change the background url even if the chosen image is not optimizable. The goal of this PR is to prevent _applyOptions() from setting background-image values if image is not optimizable. This filter will solve the first issue since empty values (badly parsed by getBgImageURL()) won't be added as background urls. task-2312878 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#62984
To reproduce: Just create an invoice with no product_id in the line. **Error 1:** First a traceback was happening. ``` AttributeError: 'bool' object has no attribute 'replace' ``` After fixing that: **Error 2:** ``` Fixed the above error then an error code 2883. 'Es obligatorio indicar la unidad de medida del ítem - Detalle: xxx.xxx.xxx ticket' ``` After fixing that: If no product_id then usnspc code can not be set then making it conditional will help to be consistent g
Original PR description
To reproduce: Just create an invoice with no product_id in the line. **Error 1:** First a traceback was happening. ``` AttributeError: 'bool' object has no attribute 'replace' ``` After fixing that: **Error 2:** ``` Fixed the above error then an error code 2883. 'Es obligatorio indicar la unidad de medida del ítem - Detalle: xxx.xxx.xxx ticket' ``` After fixing that: If no product_id then usnspc code can not be set then making it conditional will help to be consistent gathering all from the line and not from the product_id.** attributes. Forward-Port-Of: odoo/enterprise#16043 Forward-Port-Of: odoo/enterprise#16021
l10n_pe_edi: When an error comes from SUNAT the read cdr process was passing a faulty state and the digiflow state was incorrectly set to warning when it was errored This causes that the state was sent to **sent** when it was actually faulty. cc @jco-odoo Forward-Port-Of: odoo/enterprise#16035 Forward-Port-Of: odoo/enterprise#16025
Original PR description
l10n_pe_edi: When an error comes from SUNAT the read cdr process was passing a faulty state and the digiflow state was incorrectly set to warning when it was errored This causes that the state was sent to **sent** when it was actually faulty. cc @jco-odoo Forward-Port-Of: odoo/enterprise#16035 Forward-Port-Of: odoo/enterprise#16025
As the result of the cache was only depending on the params in the key, there is no reason to clear the cache on the create/write/unlink. Clearing the cache is a performance hit for the entire server. See discussion https://github.com/odoo/enterprise/pull/15297#issuecomment-769197396 Forward-Port-Of: odoo/enterprise#16034 Forward-Port-Of: odoo/enterprise#16017
Original PR description
As the result of the cache was only depending on the params in the key, there is no reason to clear the cache on the create/write/unlink. Clearing the cache is a performance hit for the entire server. See discussion https://github.com/odoo/enterprise/pull/15297#issuecomment-769197396 Forward-Port-Of: odoo/enterprise#16034 Forward-Port-Of: odoo/enterprise#16017
Forward-Port-Of: odoo/enterprise#16085
Original PR description
Forward-Port-Of: odoo/enterprise#16085
…lization report **odoo ticket nr: #2444349** Issue - Lines in Profit&Loss report for swiss localization (Compte de résultat) are duplicated. How to reproduce - Install l10n_ch_report before application of the commit in PR #5443 - Pull the last revision of odoo enterprise after PR was merged - Upgrade l10n_ch_report with new code - Print/Display Profit&Loss report - Most of the lines are duplicated Explanation - Issue appears on existing database only, du
Original PR description
…lization report **odoo ticket nr: #2444349** Issue - Lines in Profit&Loss report for swiss localization (Compte de résultat) are duplicated. How to reproduce - Install l10n_ch_report before…
…lization report
**odoo ticket nr: #2444349**
Issue
- Lines in Profit&Loss report for swiss localization (Compte de résultat) are duplicated.
How to reproduce
- Install l10n_ch_report before application of the commit in PR #5443
- Pull the last revision of odoo enterprise after PR was merged
- Upgrade l10n_ch_report with new code
- Print/Display Profit&Loss report
- Most of the lines are duplicated
Explanation
- Issue appears on existing database only, due to this commit: #5443
- In report configuration duplicated lines have parent_id referencing to the line "= Bénéfice / Perte"
Root cause of the problem is that in xml file the line defining parent_id is removed: https://github.com/odoo/enterprise/pull/5443/files#diff-f8bf972b676e31a1df740f53a77d9484e76715ebbb180de5405e73a8a7871316L751
instead of removing the line only the value should have been removed.
As the records already exist in the database, module update will not remove the value in the parent_id field. So although the ine “= Bénéfice / Perte” was moved to the bottom and shouldn’t have children anymore, the reference parent_id still exists on each report’s line and is removed only when module is reinstalled, not at the time when module update takes place.
Solution
- Keep parent_id field in the xml, but remove the value.
Forward-Port-Of: odoo/enterprise#15871https://github.com/odoo/enterprise/pull/14329 fixed the template crash but displays an "Unknown Token" when no token is provided. taskid: 2409461 Forward-Port-Of: odoo/enterprise#15045
Original PR description
https://github.com/odoo/enterprise/pull/14329 fixed the template crash but displays an "Unknown Token" when no token is provided. taskid: 2409461 Forward-Port-Of: odoo/enterprise#15045