Friday, November 26, 2021
12 changes · master
Enhancements to existing features
Survey authors can now add placeholder guidance for questions that require typed input. This helps participants understand what kind of answer is expected, improving clarity and response quality.
Original PR description
Purpose ======= As an Interviewer, I want my questions to be as clear as possible. To this end, I would like to be able to detail a bit which kind of answers I expect. Specifications ============ For all the question types that require an input, display a char field "Placeholder" in the Answers tab with a field helper that says: "When set, this text will appear in the field to help participants answer." Then on the survey, display the placeholder in the question input zone. Task-2671388
The Survey app now offers ready-made sample surveys for feedback forms, live presentations, and certifications when users first get started. This helps business users create useful surveys faster by starting from a pre-configured template they can adapt to their needs.
Original PR description
When the user opens the survey module for the first time, the user may find it difficult to create and configure a new survey as there are many options available. To improve the onboarding experience of the user, we will provide a new link on the action helper of the survey module (for the kanban and the list view of the surveys). When the user clicks on that link, the system will open a new modal. The user will then be able to choose a sample to load. Each sample will be pre-configured for specific purposes. We will have: - A sample for the feedback forms - A sample for the live presentations - A sample for the certifications After loading a sample, the user will be able to adapt it to fit their needs. Thanks to the samples, the user can create a survey more easily and more quickly. task-2670605 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The settings screen now avoids unnecessary background work when opening or saving configuration changes. This makes common settings actions noticeably faster and reduces database load, especially in larger Odoo installations with many modules enabled.
Original PR description
Improve the res.config.settings wizard performance, on the python side (focus on `onchange`, `create` and `execute` rpcs). * Avoid modification of non modified settings * Do not fetch unnecessary data: * Use cached methods to avoid verifying n times the existence of a given record * Do not compute requested defaults if not asked by the ORM. Before this PR: on runbot with "all" modules: onchange: 0.6 sec create: 0.53 s execute (call_button): 0.59 s After: onchange: 0.27 sec create: 0.31 sec execute: 0.28 sec and up to 3* less queries -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project duplication now carries over milestones while resetting completion and deadline details, making copied projects easier to reuse accurately. Sales order screens were also adjusted to present status actions in a clearer order, improving day-to-day navigation for users.
Original PR description
The purpose of the commit is to do the generic improvement for the project: So in this commit, do the following changes: - duplicating a project, copy all milestones of the project, and set is_reached and deadline field as 'False'. - change the order of the state button in the sale order form view task-2652943
Changing a customer's price list now shows a warning if that customer has open shopping carts that will not be updated automatically. This helps staff avoid pricing confusion by making it clear when open carts need to be adjusted manually.
Original PR description
It is not always immediately clear to the end user that changing the pricelist on a partner will not change the pricelist for any open carts related to this partner. To clarify, this commit introduces a warning message, indicating that the end user should change the pricelists of these open carts manually if this is the desired effect.
Any open carts that already have the same pricelist as the new partner pricelist are excluded from the search and will not trigger the warning message.
task-2635067This update improves several inventory, delivery, sales, purchase, and product workflows by making fields clearer, filters easier to use, and replenishment actions more reliable. It also fixes confusing links and labels in stock reports and helps prevent setup mistakes such as unit categories without a reference unit.
Original PR description
In this commit: ================================== 1. Added domain to display only product related variants in the product view 2. Added a Trigger Manual filter in the existing filter list of…
In this commit:
==================================
1. Added domain to display only product related variants in the product view
2. Added a Trigger Manual filter in the existing filter list of Replenishment view
3. Added a logic to set deadline date of DO based on the SO deadline date in sale
4. Changed the error message string if the same product record already exists in the replenishment
5. Changed the string of lot_name field in the stock move
6. Fixed Forecast Report breadcrumbs issue
7. Fixed Lost label of product on replenishment report while reserve/unreserve the quantity of product
8. Added logic to force user to set at least one unit as a Reference Unit in UoM category units
9. Changed the string of dhl delivery module from DHL USA to DHL Express
10. Added logic to set default product quantity value in product replenishment wizard
11. Fixed the issue of Manufacturing Order link showing html tag instead of link in replenishment view
12. Added a two view files to delivery module
1. stock_rule_view: to display the propagate_carrier field
2. stock_picking_type_view: to display the print_label field
13. Fixed the issue of Purchase Order link showing html tag instead of link in replenishment view
14. Fixed the issue of showing html tag in line
15. Moved propagate_carrier field to delivery module.
TaskID - 2581265
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCRM reporting now shows all leads and opportunities, even when the separate Leads feature is not enabled. This gives managers a broader view of CRM activity, with clearer default grouping and report columns to understand lead type, stage, and performance.
Original PR description
Purpose
=======
As a Lead Manager, I do not really care about what's in the "Lead Pipeline"
since this does not exist. Instead, I want to keep an eye on all the leads that
entered the CRM to see how well they are doing and how they are spread.
Specifications
==============
- Remove the group on the Reporting
> Leads menu item, this menu can be used with Opportunities only
- Move it below the Pipeline report
- By default, this menu shows all crm.lead :
- no matter the type (lead/opp) but with the filters in the search view
if needed
- no matter if won/active/lost (but again, filters allow me to change that
if needed)
- Default grouped by month creation date
- Filtered on records created this year to avoid displaying 10 years of CRM
usage - already done
=> The difference if I activate leads is that then I have the extra filters, ...
but this is already valid if I'm only working with opportunities
Task-2671372The Planning Analysis report now includes cost measures for allocated and effective hours, making it easier to compare planned work with actual effort. The report layout and graph ordering were adjusted for clearer analysis, and wording around working days was simplified.
Original PR description
Planning Analysis Report - Added 'Allocated Hours Cost' and 'Effective Hours Cost' measures - in the Planning Analysis report. - Removed 'hours per employee' filter and default group by the employee. - Set descending order in graph of planning analysis. - The string of the timesheet_cost field has been changed to 'Working Days' - instead of 'Number of Working Days'. closes odoo#21900 task-2531442
Warehouse users can now add the quantity for a product package directly from a barcode operation line. This reduces extra steps by avoiding the need to open the detailed edit view for each stock move line.
Original PR description
Add a new button for operations in the Barcode app. It allows to add the quantity corresponding to the Product Packaging of the Stock Move Line directly instead of going in the 'edit' view of the Stock Move Line. Task-ID: 2659768
Planning and service workflows were refined to make schedules, task details, and related sales or ticket information clearer for users. The update improves calendar visibility, button placement, staff avatars, and demo planning data so teams can navigate service operations more easily.
Original PR description
planning,industry_fsm,sale_planning,project_forecast,helpdesk_sale_timesheet Purpose of this commit to improve generic UX for service apps. So, In this commit done following changes: - replace 'after' with 'before' in xpath where data_start field added in kanban view of project task in field service app. - assign shifts to different project and SOLS in 'project_forcest' and 'sale_planning' respectively. Add more SOLS to plan for different roles in 'sale_palnning'. - add many2one_avatar widget for resource_id field in form view and calendar view popover of planning.slot model - invisible the state field in calendar view of 'Schedule' and 'My Planning' menu. - move 'I TAKE IT' button to right of the 'PUBLISH' button. - added 'Plain' and 'Draft' legend in calendar view. - move Tickets state button after Tasks state button. task-2652943
Resolved issues and error corrections
When SEPA batch booking is enabled, payment batches now use the batch date instead of each individual payment date. This helps banks process the batch as a single transaction, reducing duplicate statement lines and making reconciliation easier for accounting teams.
Original PR description
Before this commit if payments in batch have not the same date, the bank doesn't apply the batch in one time (even if sct_batch_booking is True). It is an issue because, one batch generate multi statement line (one per payment date), and it is not possible to reconcile. - Go to runbot: - Create a batch payment with 100 payments dated of 12/05 and 150 payments dated of 21/05, with sct_batch_booking = True - Validate the batch - Import XML in bank system - After a few day you import two bank statement line (one date of 12/05 and an other 21/05) - Open the reconciliation widget, select first line (dated of 12/05) select the batch - --> Issue you should un-select all payments dated of 21/05 With huge volume of payment, it is not usefull. This PR force the date of payment. @oco-odoo Note : can be merge in master if needed
Code cleanup and technical improvements
Odoo now calculates certain stored fields before a record is first saved, making it possible to require those values and enforce database rules on them. This improves data reliability across core models while keeping exceptions for fields that still need to be calculated after creation.
Original PR description
Currently, the computed fields are computed after record creation in DB. This means that computed fields cannot be required and that no SQL constraints can be based on those fields. To support…
Currently, the computed fields are computed after record creation in DB. This means that computed fields cannot be required and that no SQL constraints can be based on those fields. To support required and sql constraints on computed (and stored) fields, we need to compute the fields before record creation ... ### Side features/changes ##### `_pre_compute` model attribute Specify a model as `_pre_compute=True` to enable computed fields computation before record creation. Added to make the feature OPT-IN, allowing us to convert models one by one when there is a gain to pre_compute their computed fields. ##### `pre_compute` field attribute Specify fields as `pre_compute=False` to ensure they are computed after record creation * Done by default if any compute dependency is `pre_compute=False` * Done by default if field depends on `create_date/write_date/create_uid/write_uid` * Done manually for part of existing fields (mainly statistics fields) ##### Postpone NOT NULL AND SQL constraints after fields/models computation/setup Column are set to NOT NULL after fields computation in DB to ensure model extension with required computed fields works fine. ##### New Record cannot impact real records And inversely To pre-compute computed stored fields, we instantiate a new record with the values given to the create call. This meant that two records were put in cache for one creation (one real and one new). When a record is created linking to real records in o2m or m2m fields, the inverse was triggered and you could have new records in the relational fields of real records. Example: Create an `account.move.line`, linking to real `account.move` 1, if you accessed the lines from the `account.move`, you would receive 2 records (one new and one real). To ensure the new `new()` call in the `create()` method doesn't impact real records, the inverse of new (resp. real) records changes is not applied on real (resp. new) records anymore. It was already the strategy of the orm, but is more strictly applied from now on. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr