Thursday, October 12, 2023
9 changes
Enhancements to existing features
This update reduces the amount of generated CSS used by accounting and marketing automation screens. It should make pages slightly lighter to load while keeping the visual appearance and behavior unchanged.
Original PR description
On a runbot all database, moving from 2.15MB to 1.95MB (uncompressed) of CSS. task-3546717
Odoo now lets teams create reusable activity plans for more business records and launch them for several records at once. This makes follow-up workflows easier to configure and faster to apply across areas such as HR, CRM, projects, subscriptions, documents, field service, and reporting.
Original PR description
Generalize the hr.employee activity plan to any model, allowing to create activity plan that can be launched on any model. The activity can now be created in batch by selecting multiple record in the…
Appraisal screens now rely on employee fields that automatically show the right employee records based on the user's access level. This helps keep appraisal and feedback workflows aligned with permissions while reducing manual view configuration.
Original PR description
In the community counterpart of this PR, we change the employee custom fields to stop using always 'hr.employee.public' as the relation, but dynamically decide which relation it should use depending on the group that the current user has. Also, we allow forcing a relation by passing it as an option in the view. So, this commit removes the relation of the fields that would benefit from having this feature of showing different records depending on the user group. task-3524305
Time off records now track changes to the payslip state in the activity log. This gives HR users a clearer history of payroll-related status updates directly from the employee leave record.
Original PR description
The Payslip State field will be tacked in the chatter so that it will be helpful for the user. task: 3506642
Odoo now loads the rich text editor only when it is actually needed, helping the backend open faster for users. The update also makes the supporting assets available ahead of time to keep automated processes and tests more reliable.
Original PR description
[IMP] knowledge: lazy load wysiwyg In order to improve the loading time of the odoo backend, only load the wysiwyg before starting an html_field. task-3493014
Field service teams can now use the newer product catalog experience when adding products to service tasks and related sales lines. This makes product selection more consistent with sales workflows while preserving the specific update behavior needed for field service operations.
Original PR description
Purpose of this PR: Sales team implemented a new catalog option to select product to add on a Sale Order (https://github.com/odoo/odoo/pull/106382) We want to replace the actual FSM stat button…
Purpose of this PR: Sales team implemented a new catalog option to select product to add on a Sale Order (https://github.com/odoo/odoo/pull/106382) We want to replace the actual FSM stat button product by an access to this catalog ## Details about the implementation: ### Original product.catalog architecture product.catalog view is created in the *sale* module (odoo/addons/sale/views/product_product_views.xml) this product.catalog is using the js_class 'sale_product_kanban' to represent the kanban records of each product (odoo/addons/sale/static/src/js/product_catalog/kanban_view.js) as well as a new componant sale_order_line.js (present at the bottom of the product kanban card, displays the actual number of products in the SOL ) 'sale_product_kanban' record uses RPC call on a specific route to update and fetch informations about the product, this routing is handled by the controller (odoo/addons/sale/controllers/[catalog.py](https://catalog.py/)) The product.catalog view is then inherited by the *sale_stock* module to add the on Hand quantity of product ### Modifications made: Added a new controller with a new route to update the fsm product, this is because the logic of updating a SOL line from the sale module is quite different from updating a sale order line from the industry_fsm module, we just created a new method/route sale_product_catalog_update_sale_order_line_fsm_info which is called by the new kanban_record class we also inherit the method `sale_product_catalog_get_sale_order_lines_info` just to update the context with the task_fsm_id Added the task-id to the product_catalog/kanban_record env Adapted industry_fsm tours accordingly Task-3343547 Community PR: https://github.com/odoo/odoo/pull/127161 Upgrade PR: https://github.com/odoo/upgrade/pull/4887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A fillable Danish accounting procedure PDF has been added to the Documents accounting app. This helps Danish businesses document accounting procedures in line with updated government guidance and compliance expectations.
Original PR description
The Danish Tax Agency and the Danish Business Authority are launching an updated common standard chart of accounts. For the accounting act, we need to provide a way to support the function that users can enter an accounting guide for the individual account This commit adds a text file of danish accounting procedure in documents_account, following the strucure from Danish government's documentation task-id: 3531476
Two country-specific payroll accounting test modules are now excluded from the default automated runbot installation. This helps keep automated testing environments lighter and avoids loading extra payroll components unless they are explicitly needed.
Original PR description
*: test_l10n_(ch, us)_hr_payroll_account Prior to this commit, the modules `l10n_ch_hr_payroll`, and `l10n_us_hr_payroll` were automatically loaded on the runbot because these modules depend on `test_l10n_ch_hr_payroll_account` and `test_l10n_us_hr_payroll_account` respectively. In order to avoid overloading these modules on the runbot, we have added `installable: False` in the manifest file on `test_l10n_ch_hr_payroll_account` and `test_l10n_us_hr_payroll_account`. task - 3501382
The Mongolia VAT report is now handled in the Community edition and uses the standard tax tag reporting approach. This keeps the report aligned with Odoo’s common reporting framework and makes it easier to maintain across editions.
Original PR description
- The VAT report was moved to the Community repo Community PR: https://github.com/odoo/odoo/pull/134590 Upgrade PR: https://github.com/odoo/upgrade/pull/5122
Generalize the hr.employee activity plan to any model, allowing to create activity plan that can be launched on any model. The activity can now be created in batch by selecting multiple record in the list view and then clicking on a "clock" icon in a row similarly to the batch records update (selecting multiple records allows to change for example their name in batch in the list view). We implement also that functionality for the plan, allowing to launch a plan on multiple records at once. We also centralize the launching of activity or activity plan through either the "Activities" button in the chatter or the "clock" button in the view list. Scheduling activity is now taken in charge by a wizard that can schedule a single activity as well as a plan. We add/update tests for checking that the wizard is launched with the right record selection (on a single record or a batch) and add tests for checking the wizard itself. The plan can be defined through an added menu in the technical admin menu but also through configuration menu added in the module crm, project. Technical notes: In the added wizard, to determine that there is a error, we introduce the has_error field because we cannot use easily the error field for that. Indeed, to determine that there is no error, we have to compare it to "<p><br></p>" (more precisely <p><br></p>) which is not handy and may change in the future. This is because when we write False on field error and read it after, we get "<p><br></p>". Instead, we centralize this weird comparison in the model in the compute method of has_error. The ActivityListPopover still displays the activity of the record on which it has been triggered but the button to schedule activity will launch a wizard that create activities in batch for the selected records if more than one was selected. For that, the ActivityListPopover component receives now an additional prop: resIds (selected records) on top of the resId prop (record on which the popup has been triggered). Note that when the line that trigger the popup is not selected, the batch mode is disabled to avoid confusion. We convert the custom plan implementation to use the generic one. As the generic one can define plans for multiple model. We use the check dedicated_to_res_model == 'hr.employee' to activate the specific feature for hr.employee. Indeed, that field contains the model name when the plan is applicable only for one model. Task-3390865