Wednesday, February 3, 2021
25 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
Exported files from list and pivot views now use readable names based on the business label of the data, rather than generic or technical-only names. This makes downloaded reports easier to identify, organize, and share.
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 pivot view, the file is named 'table'
- from a listview, the file is named after the model technical name
After this commit, Name of the different export files as follows:
- for list view quick export and standard record export, the file
is named as 'model_description (model technical name)'
- for pivot view quick export, the file is named as
'Pivot of model_description (model technical name)'
Task-Id: 2237840
PR: #64123
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-prThis update adds automated checks to ensure timesheets, project tasks, and sales order links continue to calculate correctly across different billing setups. It also removes an unused sales-order creation flow, reducing maintenance while preserving expected invoicing behavior.
Original PR description
Purpose ====== The goal of this PR is to write some unit tests about the changes made in Task-2388500, Task-2409761 and Task-2424382 to keep the functional features. ## Determined Sales Order Items…
Purpose
======
The goal of this PR is to write some unit tests about the changes made in Task-2388500, Task-2409761 and Task-2424382 to keep the functional features.
## Determined Sales Order Items in task and timesheets
These tests check if the Sales Order Items (SOL) computed in task and timesheets are the ones expected based on the pricing type defined in the project.
- Check if the SOL in task is the same than the one in project when we create a task in project which has a pricing type to project rate or employee rate.
- When the pricing type is employee rate and we timesheet, check if the SOL on these timesheets are the one expected, that is:
- If the pricing type is employee rate and there are some mapping for employees, normally when we timesheet for an employee in the mapping, we should have the SOL defined in the mapping for this employee in the timesheet.
- If we timesheet for an employee who is not in the mapping then we should have the SOL of the current task.
- When the pricing type is task rate and we defined a customer who has some SOs with services products in project, if we create a task in this project then we should have the customer defined in the project and the one of latest SOLs if it is prepaid service and remaining_hours > 0. Otherwise, the SOL is False.
- When the pricing type is employee rate or project rate and the customer, SO, SOL is defined in the project, if we change the customer then the SO and SOL should be False if the customer in the project is different that the one in SO selected.
- If the pricing type is employee rate then when the customer changed in the project, the SOL in each mapping should also be removed.
## Remaining hours for prepaid service products
This test checks if the remaining hours is correctly computed in project.task when the Sales Order Item in this task contains a prepaid service product.
## Tour JS to check features in the UI
A tour js has been created to check the process with the UI. The steps are the following:
- Go to the Sales App,
- Create a sales order for Brandon Freeman for instance,
- In this Sales Order, we take a prepaid service product (we created this one in a unit test in python as we must not use the demo data to realize the JS tour) and the quantity ordered is 10 hours,
- Check the product_uom field is set on 'Hours',
- Confirm the Quotation to create the Sales Order,
- Go to the Project App,
- Create billable project to timesheet for Brandon Freeman,
- Create task in this project and add a timesheet into it,
- Show in this task that we can see the Sales Order Item linked to the createed timesheet, because this field is hidden by default.
- Go to the Settings menu and then Projects submenu.
- Create a project, and show the three different configurations to invoice services in a project. That is:
- Task rate
- Project rate
- Employee rate
## Miscellaneous
The `project.task.create.sale.order` model has been removed because the wizard is unused since these 3 tasks have been merged.
task-2439304
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prImproves the Project app experience by clarifying labels, preventing unwanted navigation from task assignees, and using clearer bookmark icons for projects. It also tightens visibility of sharing, overview, and sales order buttons so users only see actions appropriate to their role and access rights.
Original PR description
Generic improvements have been made to improve the Project App and its onboarding. ## Web module - kankan examples modal: change the 'use this for my kanban' button into 'use this for my project'. To…
Generic improvements have been made to improve the Project App and its onboarding. ## Web module - kankan examples modal: change the 'use this for my kanban' button into 'use this for my project'. To do this, a small change is made in the web module to use the options variable called `applyExamplesText` to change the label of the button in project app. - A private method called `_getFavoriteIcon` is added in `FavoriteWidget` to easily change the icon based on the boolean value when we override this widget in another module. ## Project App For project.task model: - the label of the priority label has been changed from "Priority" to "Starred". - the user_id field should not be clickable in form view. For project.project model: - the fa-star icon has been replaced by the fa-bookmark and fa-bookmark-o icons in the kanban view. - When the user is the 'Project User', the 'share' button and 'project overview' stat button are hidden in the project form view. - the 'sales order' stat button is only visible to users who have at least the `sales > all documents access right level` in project form view. task-2440564 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 pricelist item form has been reorganized to make pricing setup easier to understand. Price calculation options are now more prominent, application settings are placed more logically, and formula-based pricing includes clearer dynamic guidance.
Original PR description
PURPOSE Improve the current price list line from view for clarity Current: https://drive.google.com/file/d/16OL4pEkZtad8nEDgXGvlNeEPvNemVDPO/view?usp=sharing SPECIFICATIONS after changes form view is looking accordingly. - Fixed price https://drive.google.com/file/d/1hH4gsY_yp60lyXTHtmyV2WKKgkLuAdYq/view?usp=sharing - Discount https://drive.google.com/file/d/1texFQGj7ph-6CtQ5YtiEx2eZVkmaPSq8/view?usp=sharing - Formula https://drive.google.com/file/d/170et8hNGpK_aNPpL6akmzSKwP6QJFEvU/view?usp=sharing LINKS PR https://github.com/odoo/odoo/pull/63733 Task-2373068
Website editors can now rename custom snippet blocks after saving them, instead of being stuck with the original name. New custom snippets also receive a default generated name, making it easier to save quickly and organize content later.
Original PR description
Before this commit custom snippets name was specified on save and there was no way to modify their name afterwards After this commit custom snippets are assigned a default name on save but can be renamed afterwards task-2374802 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
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: #15579Studio’s model configurator now creates richer default views when users enable common options during app creation. Monetary models get a ready-to-use graph view with sample data, and pipeline-style models get colored Kanban cards with a color picker, helping teams build clearer apps faster.
Original PR description
this commit improves the model configurator - when the monetary value option is enabled at model creation, it activates the graph view with sample data. - added the colorpicker and colored cards feature on the kanban when the pipeline stage option is enabled at model creation, task - 2348422
Miscellaneous 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