Friday, May 31, 2024
21 changes · master
Enhancements to existing features
Products with instant attributes now appear only once in the preparation display instead of being repeated for every possible combination. When selected, staff can choose the relevant combination from a popup, making the product list easier to scan and use.
Original PR description
Before this commit when a product have attribute in instantly mode, the product was duplicated in the list of products as many times as there were possible combinations. Now, the product is displayed only once and when the user clicks on it, a popup is displayed with the possible combinations. taskId: 3884515 Related: https://github.com/odoo/odoo/pull/163781
The Help menu now sends visitors to a team selection page when multiple support teams are available, instead of duplicating the ticket submission page at different addresses. This creates clearer navigation for customers and helps avoid SEO issues caused by duplicate pages.
Original PR description
Before this PR, clicking on the 'Help' menu would lead to a submit ticket page with a specific link. And, accessing the '/helpdesk' route would also display the same page. It will have a negative impact on SEO In this PR, if there are multiple teams, clicking on the 'Help' menu will redirect users to a page where they can select the specific team they wish to contact, and clicking on a team will take users to the submit ticket page. task-3453870
The task popovers in calendar and map views now display Project and Worksheet Template in the same order as other task views. This makes field placement more predictable for users and reduces small inconsistencies when reviewing field service tasks.
Original PR description
before this PR: - 'worksheet template' and 'project' fields in the calendar/map view popovers of tasks is inorder so that the order is inconsistent with the other views After this PR: - Switched the 'worksheet template' and 'project' fields from place in the calendar/map view popovers of tasks so that the order is consistent with the other views task-3784852
Spreadsheet charts now support more design options, including title styling, axis settings, and dataset colors. This helps users create clearer, more polished charts directly in Odoo spreadsheets without extra manual work.
Original PR description
## Description This task aims to improve the design customization of the charts in o-spreadsheets, adding many customizable options like the title alignment/color/style, the axes configurations, the datasets colors, ... This PR adapts odoo's part to take the changes of o-spreadsheet into account. ## Related Task(s) - Task [3792009](https://www.odoo.com/web#id=3792009&action=333&active_id=2328&model=project.task&view_type=form&cids=1&menu_id=4720) - https://github.com/odoo/o-spreadsheet/pull/3893 - https://github.com/odoo/odoo/pull/166538
Employees now see only open shifts that fit their working hours and time off, reducing confusion and unsuitable self-assignments. The planning screen also gives clearer guidance when no shifts are assigned and displays shift durations based on each employee's working schedule.
Original PR description
[IMP] planning: Improve Front-End UX Before this commit: - The list of open shifts contains shifts for which the employee wouldn't be available anyways because it falls outside of their working…
[IMP] planning: Improve Front-End UX Before this commit: - The list of open shifts contains shifts for which the employee wouldn't be available anyways because it falls outside of their working hours, or during their time off. - A blank screen is displayed when the employee doesn't have any shifts assigned yet. - Shifts are displayed with their real duration instead of the employee working hours. - technically, _prepare_slot_vals in _planning_get inside project_forecast and inside sale_planning is having duplicated code (line 46 - 49 = line 27 - 30 inside sale_planning) and computing again the full title each time by erasing the old title. It is doing 2 extra search calls for each slot. _planning_get is also iterating over the slots 3 times when the 3 modules installed. After this commit: - front-end > open shifts available list: shifts that fall outside of the working hours of the employee or during their time off are not displayed. - front-end view when publishing open shifts but no shifts > list view > "You don't have any shifts planned yet. You can assign yourself some of the available open shifts." (the second sentence should only be visible if there are open shifts available for this employee) is now displayed in no shifts. - front-end > shifts are displayed with the employee working hours duration. - technically, it was replaced by a new refactoring without doing extra work. - technically, u' \U0001F4AC' is replaced by ' \U0001F4AC' for slots having notes due to UP025 (Remove unicode literals from strings https://docs.astral.sh/ruff/rules/unicode-kind-prefix/) task-3186609
Helpdesk ticket descriptions can now support collaboration directly in the ticket form. This makes it easier for team members to work together on ticket details and keep information aligned in one place.
Original PR description
After this PR merge: - implement collaboration feature for description in the helpdesk ticket form view task-3817497
A new Notifications submenu in Configuration lets administrators set default notification behavior for all Discuss channels. This makes it easier to manage whether users receive all messages, mentions only, no notifications, or muted notifications unless a channel has its own specific setting.
Original PR description
Add a sub-menu for "Notifications" in the "Configuration" menu. The "notifications" sub-menu should have the following options to apply to all Discuss channels. Same options as for notifications on each channel: Mute (+choose time period) / All messages = default / @mentions/ nothing This setting should apply to all channels that use the default one unless another configuration has been made for a specific one. split of task-3503901
Planning shift emails now include buttons that let employees self-assign open shifts or self-unassign when allowed. Sharing logic was also improved so internal planning users open the appropriate planning view instead of being sent to the front-end view.
Original PR description
Prior to version 15 we had action buttons in the single shift email of the planning app. Specifically, if an open shift was shared from the planning app, employees could get the open shift assigned…
Prior to version 15 we had action buttons in the single shift email of the planning app. Specifically, if an open shift was shared from the planning app, employees could get the open shift assigned to them through a self-assign button in the email. Similarly, if the self-unassign setting is enabled from the planning app's settings, employees could unassign themselves from their shifts directly from the shift's sharing email through a self-unassign button. This PR re-introduces the two buttons to the shift emails. The code for their logic was never removed so we only reintroduce them in the email template. We also change the way that the planning is shared. Prior to this PR, we would check whether the employee was a planning internal user by checking whether they have a corresponding user and whether that user belongs to the "group_planning_user" group. In the planning app though, there are three types of internal users, ones who can see only the "My Planning" menu, ones who can see other menus and other resources, and planning managers. The former type of planning users do not belong to a specific group. This, resulted in the planning being shared with internal users (the former kind) but only opening in front-end view. task-3791152
Resolved issues and error corrections
Appointment emails now avoid showing a map link when no address is available and hide the resources section when it does not apply. This reduces confusion for customers and keeps booking communications focused on relevant information.
Original PR description
**Before this PR:** While booking an appointment, the outgoing emails contain some irrelevant data in certain conditions: - A 'View Map' hyperlink is displayed after location name even when 'res.partner' has no contact address set. - A 'Resources' title is displayed even when the appointment type is not 'resources'. i.e. There are no resources to display. This PR resolves these issues by tweaking the conditions to display the 'hyperlink' to search location address and the 'resources' section correctly. **After this PR:** - The 'View Map' hyperlink is displayed only when res.partner not only has the location name, but a set location address for the appointment. - The 'Resources' section is displayed only when the appointment type is 'resources'. Task - [3829148](https://www.odoo.com/web#id=3829148&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form)
Code cleanup and technical improvements
This update prepares Odoo’s automated tour tests for a clearer, more consistent way of checking screens and triggering clicks. It mainly affects internal test maintenance, helping reduce ambiguity and future-proofing quality checks without changing normal user workflows.
Miscellaneous changes
Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. Similarly to what is done in document kanban and list controller where updating the document through the inspector works, we activate the parameter multiEdit which solve the problem. Bug 2: How to reproduce: 1. Schedule an activity for a document. 2. Go to activit
Original PR description
Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document…
Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. Similarly to what is done in document kanban and list controller where updating the document through the inspector works, we activate the parameter multiEdit which solve the problem. Bug 2: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Erase the name of a doc and click anywhere to save. No alert pop-up is shown up while saving with an empty name while this is the case when editing the document from the kanban or the list view. Similarly to what is done in document kanban and list view, we add the required attribute to the field name. Technical note: to avoid duplicate a lot of code, we add the test inside documents_kanban_tests.js (while it is testing the update of a document in the inspector of the activity view). Task-3817795 Forward-Port-Of: odoo/enterprise#63038 Forward-Port-Of: odoo/enterprise#59263
The close button in the planning slot portal modal now appears in the correct position. This small visual fix makes the dialog easier to use and presents a more polished experience for portal users.
Original PR description
The button is misaligned in the modal of the planning slot's portal view. This PR will realign it correctly. task-3943384
Fixed an issue where the self-order preparation display could appear blank when opened. This helps staff reliably view and manage incoming orders without interruption.
Original PR description
Before this commit: =========== - When we open the preparation display, it becomes blank. After this commit: =========== - The preparation display works fine. task-3958744
Odoo Studio now shows all available fields immediately when creating a related field, instead of initially limiting the list to many-to-one fields. This makes field setup faster and avoids confusion for users configuring customizations.
Original PR description
SPECIFICATION: When a related field is created with Studio, the list only displays the (M2O) fields. If a field is selected, then all fields become available. Observed behavior: the list only displays the M2O fields Expected behavior: All the fields should directly be available while creating related field in studio . Task-3821059
Original PR description
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities. - `isCheck: true` => Checks that the element is in the DOM. The latter can…
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities.
- `isCheck: true` => Checks that the element is in the DOM. The latter can be disabled.
- `run() {}` => Checks that the element is in the DOM (because this is what is done by default). However, if the element is disabled, the step will be aborted.
In the codebase, we can see a lot of `run() {} //it's a check` and `isCheck:true`. However, the behavior is not exactly the same. What's more, there are 2 ways to do "the same thing". In order to clarify the turns API, it was decided to no longer put an action (step.run) by default. (Previously, the default action was the "click" action).
From then on, it is no longer necessary to stipulate `step.isCheck: true` nor `run() {}`.
The corollary is that now, you must explicitly write `run: click`, if you want the click action to be triggered on the target.
This commit sets the stage for making this change.
https://github.com/odoo/odoo/pull/167376This reverts commit 819ed2a64d0f11f33190af0c804955e380242968. opw-3955626 but there are many others Forward-Port-Of: odoo/enterprise#63484
Original PR description
This reverts commit 819ed2a64d0f11f33190af0c804955e380242968. opw-3955626 but there are many others Forward-Port-Of: odoo/enterprise#63484
Steps to reproduce: - Install `website_helpdesk` - Edit the help form to add a field of type 'Email CC' - Fill the form and for the 'Email CC' put a random mail Issues: The ticket is created but doesn't have any subscribers. The reason is that since the supplied mail in `mail_cc` is not related to any internal user test we will hit the continue in the `create` method. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#
Original PR description
Steps to reproduce: - Install `website_helpdesk` - Edit the help form to add a field of type 'Email CC' - Fill the form and for the 'Email CC' put a random mail Issues: The ticket is created but doesn't have any subscribers. The reason is that since the supplied mail in `mail_cc` is not related to any internal user test we will hit the continue in the `create` method. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#L508-L509 Because of this continue we will skip the code in charge of subscribing the partner to the ticket. https://github.com/odoo/enterprise/blob/ee506c2ab3e7b39831aed0af2142f8f7e4ba02ba/helpdesk/models/helpdesk_ticket.py#L512-L513 opw-3922047 Forward-Port-Of: odoo/enterprise#62875
The problem is that the message ``` This invoice will be paid using direct debit and is only sent for informative purposes. sent for informative purposes ``` is displayed even in invoices that doesn't use Direct Debit after a studio change. Steps: - install `account_sepa_direct_debit` - install `web_studio` - Edit `Invoices` report on studio - Save - Try to print an invoice report - SDD (Sepa Direct Debit) message will be displayed even if this invo
Original PR description
The problem is that the message ``` This invoice will be paid using direct debit and is only sent for informative purposes. sent for informative purposes ``` is displayed even in invoices that…
The problem is that the message
```
This invoice will be paid using direct debit and is only sent for
informative purposes. sent for informative purposes
```
is displayed even in invoices that doesn't use Direct Debit after a studio change.
Steps:
- install `account_sepa_direct_debit`
- install `web_studio`
- Edit `Invoices` report on studio
- Save
- Try to print an invoice report
- SDD (Sepa Direct Debit) message will be displayed
even if this invoice doesn't use SDD
This inconsistency was due to two errors in the report generated by SDD
```xml
<p t-if="o.sdd_mandate_id">
<span>
<p>
This invoice will be paid using direct debit and is only
sent for informative purposes.
</p>
<p>
Please do not pay it manually, the payment will be asked to your bank to be processed
automatically.
</p>
</span>
</p>
```
A `<p>`/`<span>` can't contains another `<p>`
as defined here https://html.spec.whatwg.org/#the-p-element or https://html.spec.whatwg.org/#the-span-element `<P>`/`<span>` can only contains "Phrasing content" (https://html.spec.whatwg.org/#phrasing-content-2) `<div>` and `<p>` for example are not phrasing content
opw-3908411
Forward-Port-Of: odoo/enterprise#63345**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned. **Expected behavior:** With this specific configuration, pickings with the same product should all be changed when a different destination is scanned. **Steps to reproduce:
Original PR description
**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some…
**Current behavior:**
If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned.
**Expected behavior:**
With this specific configuration, pickings with the same product should all be changed when a different destination is scanned.
**Steps to reproduce:**
1. In the Internal Transfers picking type, configure the barcode settings like so:
`Source Location: Mandatory Scan`
`Product: True`
`Destination Location: After each product`
2. Create some new internal location (e.g., .../Stock/shelf)
3. Create a new batch picking with 2 internal transfer pickings for the same product
4. Go to the batch operation barcode menu, select the created batch picking
5. Scan the source location, scan the first product code and then manually add the second picking quantity with the add quantity button, scan the newly created internal location
6. Observe that the last picking destination location has changed and the first has not- furthermore trying to change the second's destination location via scan does not work (manual changes via the edit button/form still possible)
**Cause of the issue:**
The method of changing destination does not account for this setup, so there is no specific handling for it. Only the selected line will be modified by a new destination scan.
**Fix:**
Extract the line modification code into a new function and override it in the batch_picking module to change the entire current batch of lines that have been scanned (that all have the same product).
opw-3733870
Forward-Port-Of: odoo/enterprise#62201Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enter
Original PR description
Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enterprise#62965 Forward-Port-Of: odoo/enterprise#62710
opw-3921760 opw-3889677 Forward-Port-Of: odoo/enterprise#63241 Forward-Port-Of: odoo/enterprise#62859
Original PR description
opw-3921760 opw-3889677 Forward-Port-Of: odoo/enterprise#63241 Forward-Port-Of: odoo/enterprise#62859
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positio
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: [3714696](https://www.odoo.com/odoo/2328/tasks/3714696?cids=1) Forward-Port-Of: odoo/enterprise#63454 Forward-Port-Of: odoo/enterprise#63316