Friday, May 31, 2024
13 changes · master
Enhancements to existing features
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
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
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