Daily updates from Odoo
Monday, September 5, 2022
14 changes
Enhancements to existing features
The Belgian payroll test setup was adjusted to match updated access rules for selecting an HR Responsible. This helps keep payroll quality checks aligned with the intended restriction that only users with HR Officer rights appear in that role.
Original PR description
The HR Responsible domain was adapted in odoo/odoo#99540 to only show users with HR Officer rights. task-2959207
The Sign app template screens have been streamlined by removing less-used menu options, making advanced template settings easier to reach, and moving field type management into Settings. A new setting lets businesses control who can manage template access, improving administration without cluttering everyday workflows.
Original PR description
- remove the "delete" button with the base.group_no_one gruop from the sign.request kanban view (accessible through form if needed, and archive should be promoted) - delete the menu "Properties" on…
- remove the "delete" button with the base.group_no_one gruop from the sign.request kanban view (accessible through form if needed, and archive should be promoted) - delete the menu "Properties" on the sign.template kanban dropdown (replaced below) - add a button (secondary) at the right of the "tags" and at the left of the "saving" indicator that takes you the form view of the template - remove the "Edit Fields" stat button from the form view of the sign.template (I just reversed the logic, you now go from the field edition to the advanced properties instead of the opposite) - create a new group "Manage template access" that can be enabled through the Sign Settings for the whole db have the (remaining) fields "group_ids"' and "user_id" of the sign.template model visibility be controlled by that group in the template form view and in the template edition view - unhide the tab "Fields" from the debug mode in the view sign.template.form - delete the menu "signature requests items" completely - remove menu "Field Types", but add an equivalent action to access them from the Settings (see screenshot "Field Types") - add a help string/tooltip on the field "tip" on model sign.item.type: "Hint displayed in the signing hint" task-id : 2871447
This update improves how Odoo prepares and reuses back-office screen layouts, reducing repeated server work when users open views. It should make everyday navigation noticeably faster, especially in areas with complex screens or many available actions, while preserving user access rules and translations.
Original PR description
The master plan finally comes to an end. Thanks to: - odoo/odoo#87522 refactoring `load_views`, - odoo/odoo#94337 refactoring `common.Form` to prevent changing invisible fields in unit tests using…
The master plan finally comes to an end.
Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
on back-end views.
The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.
The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...
Not including the groups in the cache key allows:
- to have less cached versions,
(otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
(with the current cache key,
there is nothing to fetch from the database to compute the key)
Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
- parsing arch from/to string with etree is fast,
- removing the `groups=` nodes using etree is fast,
- adding the `create="False"`, `write="False"`, `delete="False"` on the view
root node according to the access right of the user on the model is fast.
This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.
Timing tests are available on the community pull request odoo/odoo#99417The Belgian Balance Sheet report no longer includes control lines. This makes the report cleaner and easier for businesses to read while aligning it with the intended reporting format.
Original PR description
This PR removes the control lines from the Belgian Balance Sheet Upgrade: https://github.com/odoo/upgrade/pull/3859 task-id: 2928459
Message notification previews were updated to use the newer channel-based structure. This keeps the mail interface aligned with the current messaging model and helps ensure future improvements are easier to maintain.
Original PR description
Community: https://github.com/odoo/odoo/pull/99342 Part of task-2948676.
The SEPA Direct Debit payment provider setup was updated as part of a broader redesign of payment provider cards. Removing the old description content helps keep the payment provider overview cleaner and more consistent for users.
Original PR description
This commit is part of the rework of the kanban view payment acquirers. Task-2841718 See: - odoo/odoo#98345 - https://github.com/odoo/upgrade/pull/3803
The payroll dashboard layout has been refreshed so cards, spacing, and related controls look more consistent across the application. This improves readability and gives payroll users a cleaner, more polished experience without changing core payroll functionality.
Original PR description
Prior to this PR, there was unnecessary scss. Also the design changes make all the dashboard cards consistent with the others and fix the wrong spacing. Community PR: https://github.com/odoo/odoo/pull/98770 task-2924487
New menu entries make it easier for users to find and access signing documents, including employee contract signing documents. Request lists now show more useful information, and signer status display has been corrected for right-to-left language layouts.
Original PR description
…equest views New menu entries make it easier to access your documents. Request views are more useful with added information. task-2946351
Customers can now use third-party express checkout options, such as Apple Pay and Google Pay through Stripe, directly from the cart when shipping with supported carriers. Delivery rates can be calculated with partial address details, reducing checkout friction while still keeping full address checks for actual delivery; a USPS address validation issue was also corrected.
Original PR description
Impacted modules: delivery_bpost, delivery_dhl, delivery_ups, delivery_usps One will now be able to pay using third parties express checkout (e.g. Apple Pay, Google Pay) from the cart. At the moment, only Stripe will support this flow. Some delivery carriers check if all the required fields are available before computing the rate, even if those fields aren't required for computing the rate (although they are for delivering the goods). If we only have partial information about the delivery address but still want to compute the rate, a context key will ensure that we only check the required fields for a partial delivery address (city, zip, country_code, state_code). See also: - https://github.com/odoo/odoo/pull/88374 - https://github.com/odoo/documentation/pull/2392 task-2754209
Project forms now show key setup options like billable work, timesheets, and planning more directly, while removing the worksheet option from the simplified project view. Task document actions also better carry over the customer by default, reducing manual data entry and improving day-to-day project administration.
Original PR description
…project Purpose of this PR to improve generic usage of project app. So, in this PR done following changes: - in project_project_view_form_simplified: - removed 'worksheets' option - displayed the billable/timesheets/planning options in the project form view - add default partner in document stat button action from task form view task-2821488
Field service users can now enter decimal quantities when adding products to a job, such as litres of oil or hours of cleaning. This makes product usage more accurate by respecting each product’s unit of measure precision, reducing manual workarounds and billing inaccuracies.
Original PR description
Currently, cannot allow entering decimal numbers in 'add products'. Can now be done. Use Case- Service of Generator Set Service Includes- Oiling, Bore Piston Work, Cleaning Employee- Administrator => Timesheet Starts => Add Products 1. Engine Oil = 2.877 Product Configuration- Engine oil => Consumable , UOM - litre , Rounding Precision- 0.001 2- Gaskit- 1 Product Configuration- Gaskit => Storable , UOM - Units, Rounding Precision- 1 3- Cleaning- 5.566 Product Configuration- Cleaning => Service. UOM- Hrs, Rounding Precision= 0.01 closes odoo#22155 task-2674426
This change adjusts an internal performance test to account for an additional check related to link previews in messaging. It helps keep automated test expectations aligned with current behavior, with no direct impact on day-to-day users.
Original PR description
Extra query to fetch link preview status. https://github.com/odoo/odoo/pull/82641
This update simplifies subscription contracts by allowing only one invoicing rhythm per contract, making renewals, upsells, and billing easier to understand and manage. It also fixes issues that could create duplicate invoices or duplicate active contracts, improves rental and subscription setup, and adds clearer contract status information for users.
Original PR description
This PR aims to deeply change the behavior of sale_subscription following https://github.com/odoo/enterprise/commit/e09167bbbd5f4b731624af05831dfdcdab56828b and…
This PR aims to deeply change the behavior of sale_subscription following https://github.com/odoo/enterprise/commit/e09167bbbd5f4b731624af05831dfdcdab56828b and https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd We decided to revert one behavior of these commits. We will only allow one invoicing periodicity per contract. Having the possibility to have several different periodicity per contracts had several drawbacks: - It brings a lot of code complexity - From a functional point of view, it can be difficult to have a global point of a view on a client contract when several renewals and upsell happened. - It is not a primordial need. This PR updates sale_temporal, sale_subscription* and sale_renting* and bring several fixes. [IMP] sale_temporal: create recurrence object and fields from sale order lines ------------------------------------------------------------------------------------------------------- Before this PR, https://github.com/odoo/enterprise/commit/e09167bbbd5f4b731624af05831dfdcdab56828b and https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd introduced the product pricing records linked to sale order lines. It was inspired by the rental module and seemed fitted for subscription. Unfortunately, after some deep testing, we came to conclusion that this design was not the best suited for subscription management. We decided to move back the start_date and next_invoice_date to sale_renting as sale.order would carry these value in sale_subscription. This commit introduces a few changes: - We needed a new type of records: sale.temporal.recurrence. It is defined by the duration and unit that were previously defined on the product_pricing. We could not used uom because it would be impractical to deal with time UOM. One month do not always contain the same number of days and a year do not always contain the same number of days. Creating recurrence specific UOM would be quite complex to use as it should not be mixed with existing time UOM. - As some SO now have a longer duration (rental, subscription), we added a new field: internal note to help the user to centralize the information about the contract. - As the pricing override the pricelist item price value, we decided to display the information on the pricelist view to help people to configure their pricelist rules. [IMP] *sale_subscription*,partner_commission: Save recurrence on the sale.order and not the line --------------------------------------------------------------------------------------------------------------------------------- In this PR, we adapt the sale_subscription's modules to the changes in sale_temporal. Most of the changes consists to move the recurrence from the line to the sale.order. The next_invoice_date and start-date is now stored on the SO. The recurrence_id field is a sale.temporal.recurrence record and it defines the periodicity of the sale.order. The next_invoice_date is directly derived from it. We also decided to move the pricing_id field to the sale_subscription module because it was not useful in rental. This commit introduce also a big change in the invoicing of subscription. Before this PR, the payment_mode field on a sale.order.template would define if the recurring invoices should be: manual: created manually by the salesmen draft_invoice: created in draft validate_send posted and sent success_payment: paid with a payment token and then sent. Remove the payment_mode field on sale.order.template -------------------------------------------------------------------------- After this PR, recurring invoices are created and posted if there is no payment token on the sale.order and charged with automatic payment if the payment_token is present. It bring more flexibility and allows a customer to don't save his payment method if he don't want to. [FIX] *sale_renting*: Apply change to sale_temporal to sale_renting ------------------------------------------------------------------------------------------ *sale_renting* module are updated to rely on the sale.temporal.recurrence records. The sale.order.line don't have the next_invoice_date value. Only the return_date remains for rental lines. [FIX] sale_subscription: payment update next invoice date for auto_invoice --------------------------------------------------------------------------------------------------- Reproduce: - automatic_invoice setting is set - Create a draft subscription with a valid payment token - Send the quotation to the customer - Customer sign and pay the sale order --> Two invoices are created. - One during the sale flow (_reconcile_after_done --> _invoice_sale_orders) - The other invoice is created when the invoicing cron of subscription run. It happened because the next_invoice_date was not updated after the first invoice. After this commit, the next_invoice_date can be updated from 3 locations: - In _create_invoices on sale.order when the automatic payment by token is disabled. - In reconcile_pending_transaction on sale.order for subscriptions with valid token It ensures that the next_invoice_date is only updated once the payment succeed to avoid proving a service when the customer has no valid payment method. _invoice_sale_orders on payment.transaction for the first invoice with automatic payment when a valid token is saved on the order. We tried to override _create_transaction in the portal to use a proper callback_method to reuse reconcile_pending_transaction but after that, _reconcile_after_done and _invoice_sale_orders are called by the sign code and the sale order is invoiced twice. [FIX] sale_temporal: compare abs value when looking for the best pricing -------------------------------------------------------------------------------------------------- Before this commit, the lowest price would be selected to return the best pricing rule. When negative price are set, the highest 'discount' would be returned each time. jackpot ! Various ---------- - Improve the amount of information logged in the child contract when creating a renew or an upsell. - fix close button. Before this PR, the close button canceled the SO but when it needs to be closed with a reason. - Before this PR, nothing prevented a quotation to be confirmed when there was already a confirmed quotation for a subscription. This would create two running contract for the same client. This commit prevent it by raisong an error when the salesmen try to confirm the second quotation. - Add some badge information to help understand if a SO is renewed, renewing, upselling, a renewal or an upsell. taskid: 2942621
The website appointment menus now better populate the main website menu content area, including links that point users toward the embedded appointment experience. This makes appointment-related pages easier to find and navigate from the website menu.
Original PR description
task-2889981