Tuesday, December 20, 2022
20 changes · master
Enhancements to existing features
The web module now provides clearer typing information for the RPC service settings object. This is an internal quality improvement that helps developers use the service more reliably without changing business workflows.
Original PR description
This better expose the settings object when using the RPC service
Resolved issues and error corrections
Opening calendar provider settings in Studio no longer triggers a crash. The change replaces a fragile click handler with a dedicated widget, making configuration forms more reliable for users customizing their calendar setup.
Original PR description
Remove the t-on-click used in form view as it crashes when opened with studio. Instead we use a dedicated `<widget/>` task-3090960
Payment screens now correctly show the currency symbol after a recent interface change caused it to disappear in grouped views. This helps users quickly understand payment amounts and currencies without confusion.
Miscellaneous changes
Before this commit, some tag would not display correctly in the tag list of project eLearning This commit fixes this behavior Forward-Port-Of: odoo/odoo#108224 Forward-Port-Of: odoo/odoo#108041
Original PR description
Before this commit, some tag would not display correctly in the tag list of project eLearning This commit fixes this behavior Forward-Port-Of: odoo/odoo#108224 Forward-Port-Of: odoo/odoo#108041
Original PR description
With recent JS change on "group" the currency symbol was missing. By adding the currency_id field invisible in the arch the problem is solved. Task-id:3089285 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mass mailing editor no longer shows a duplicate option for changing button background colors. This reduces confusion for users by keeping button color customization in the intended place only.
Original PR description
Commit [1] introduced a "custom" type of button as the only type of button whose background color we are allowed to change. But the option to change any button's background color exists in mass_mailing so we end up with the same option in two different places. This removes that previously existing default option. [1]: https://github.com/odoo/odoo/commit/a010c91b5ee119cf54ed1a68a6ea06b2bc5f3978 task-3096806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a crash that could occur in Studio when displaying formatted social post content. The field now uses the correct read-only behavior, improving reliability without changing how users edit or publish posts.
Original PR description
There's no reason to inherit from TextField here as the PostFormatterField only t-out a formatted value, and does not allow edition. Worse, inheriting from TextField produces a crash in studio. TextField expects to have the ref to its textarea, but that extension does not set that ref. This has been detected by the clickbot test.
Before this commit: after calling the `init_from_JSON` of the order line, the `pack_lot_ids` would be changed. It will cause a problem if this function is called before sending the JSON to the backend or saving it. The solution is to copy its value and prevent it from changing. opw-3088922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108266 Forward-Port-Of: odoo/odoo#108214
Original PR description
Before this commit: after calling the `init_from_JSON` of the order line, the `pack_lot_ids` would be changed. It will cause a problem if this function is called before sending the JSON to the backend or saving it. The solution is to copy its value and prevent it from changing. opw-3088922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108266 Forward-Port-Of: odoo/odoo#108214
Steps to reproduce the bug: 1. Drag and drop the "image - text" snippet. 2. Click on the image => you have a double overlay which appears (one on the column with handles and one on the image without handles), this is good, that's what we want: the ability to control the column width but as the image has options, it should be framed with an overlay too to indicate what you are editing in the right panel. 3. Hover the column options => good, only the overlay of the column remains in prev
Original PR description
Steps to reproduce the bug: 1. Drag and drop the "image - text" snippet. 2. Click on the image => you have a double overlay which appears (one on the column with handles and one on the image without…
Steps to reproduce the bug: 1. Drag and drop the "image - text" snippet. 2. Click on the image => you have a double overlay which appears (one on the column with handles and one on the image without handles), this is good, that's what we want: the ability to control the column width but as the image has options, it should be framed with an overlay too to indicate what you are editing in the right panel. 3. Hover the column options => good, only the overlay of the column remains in preview mode (without handles / buttons). 4. Hover the image options => good, only the overlay of the image remains in preview mode (without handles / buttons). 5. Stop hovering the panel => the double overlay should be restored but that's not the case: only the column one remains, even though the image options are still displayed in the panel. When we introduced the possibility to display 2 overlays at the same time in this commit [1], we added a loop to search for the overlays to display since there can now be several. But in a later commit [2], we added a `break` in this loop, which no longer allows displaying more than one overlay when necessary. [1]: https://github.com/odoo/odoo/commit/9bbe5be3fb0d995374a369851df3641979d8e553 [2]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29 task-2919164 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#96762
Step to reproduce: - Create an invoice with a product - confirm it - go to the product and change the uom Issue: Traceback Cause: https://github.com/odoo/odoo/blob/51ead4b2d52e0faec2065b475dac7f376328c425/addons/uom/models/uom_uom.py#L155-L159 Solution: Prevent the user to change the uom of a product if this one is used in an invoice opw-3039419 Forward-Port-Of: odoo/odoo#108062 Forward-Port-Of: odoo/odoo#107553
Original PR description
Step to reproduce: - Create an invoice with a product - confirm it - go to the product and change the uom Issue: Traceback Cause: https://github.com/odoo/odoo/blob/51ead4b2d52e0faec2065b475dac7f376328c425/addons/uom/models/uom_uom.py#L155-L159 Solution: Prevent the user to change the uom of a product if this one is used in an invoice opw-3039419 Forward-Port-Of: odoo/odoo#108062 Forward-Port-Of: odoo/odoo#107553
- base.view_base_module_uninstall - base.base_module_install_review_view_form - base.base_module_install_review_view_form were the only 3 views in which a node was set outside the `<form>`, `<tree>`, `<kanban>`, ... node. ```sql master-all=# SELECT name FROM ir_ui_view WHERE type != 'qweb' AND inherit_id IS NULL AND arch_db ->> 'en_US' not ilike '<' || type || '%'; name --------------------------------------- Uninstall module base.module.install.request.view.form
Original PR description
- base.view_base_module_uninstall - base.base_module_install_review_view_form - base.base_module_install_review_view_form were the only 3 views in which a node was set outside the `<form>`, `<tree>`,…
- base.view_base_module_uninstall
- base.base_module_install_review_view_form
- base.base_module_install_review_view_form
were the only 3 views in which a node was set outside the `<form>`, `<tree>`, `<kanban>`, ... node.
```sql
master-all=# SELECT name FROM ir_ui_view WHERE type != 'qweb' AND inherit_id IS NULL AND arch_db ->> 'en_US' not ilike '<' || type || '%';
name
---------------------------------------
Uninstall module
base.module.install.request.view.form
base.module.install.review.view.form
(3 rows)
```
These were introduced by odoo/odoo#99438.
The goal was to set these warnings on top of the form view, with no margins for a better UI.
While this serves an understandable purpose,
not having <form> as the root node causes issues:
- First, as seen in the above revision, it requires to have to specify the view type in the XML data file, because the view type is guessed from the root node of the view
```diff
<record` id="view_base_module_uninstall" model="ir.ui.view">
<field name="name">Uninstall module</field>
<field name="model">base.module.uninstall</field>
+ <field name="type">form</field>
```
- Second, in the view post-processing, some implementations
are based on the root node of the view,
and not having `<form>` as the root node for instance makes
the view not editable, or not pass the `readonly`, `required`
attributes from the Python model.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1146-L1147
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1375-L1379
We could use the view type from the model itself,
instead of the root node, to determine the type of the view,
but then you wouldn't be able to use attributes set on the view node,
such as `editable="1"`, to determine if the root/view node is editable
or not.
https://github.com/odoo/odoo/blob/7b9bd9d37731fae724dc5d91da656dab70aa9ad4/odoo/addons/base/models/ir_ui_view.py#L1352
Because the `<form>` node wasn't the root node in the uninstall form view, the modifiers attributes (`readonly`, `required`) were not passed from the field python model to the view,
and the Studio fields
`custom_views`, `custom_reports`, `custom_models`, `custom_fields` were editable in the view, while they shouldn't as those are readonly computed fields.
A constraint will be added in master, to prevent developers to create views with as root node something else than the view type. The constraint is not added in stable 16.0 to avoid to suddenly raise a constraint exception for modules from the community and customers in production databases.
closes #107947
Forward-Port-Of: odoo/odoo#108073*: website_form The fields of a form that are mandatory because of the model they need to be used in cannot be removed. When such a field is selected, the remove button displays a tooltip giving this information. Disabling the overlay button is done by removing the specific class - which makes the event selector not linked to the button, but also impacts the applied CSS rules. This commit adds an `o_disabled` CSS class upon disabling the button. The tooltip is put on a `span` that wr
Original PR description
*: website_form The fields of a form that are mandatory because of the model they need to be used in cannot be removed. When such a field is selected, the remove button displays a tooltip giving this information. Disabling the overlay button is done by removing the specific class - which makes the event selector not linked to the button, but also impacts the applied CSS rules. This commit adds an `o_disabled` CSS class upon disabling the button. The tooltip is put on a `span` that wraps the disabled button because tooltips cannot be shown on disabled elements. Steps to reproduce: - Drop a "Form" block. - Select the "Phone Number" field. - The overlay's delete icon has a reddish background. - Select the "Your Email" field. => The overlay's delete icon had a dark gray background instead of a reddish one. task-2950433 Forward-Port-Of: odoo/odoo#107574 Forward-Port-Of: odoo/odoo#98292
This commit adds a step in the click all test: for each view, enter and leave Studio, to ensures that the view doesn't crash in Studio. With the migration of views to owl, a lot of views worked fine, but crashed when entering Studio. Those issues have been solved now, and we want to ensure that this no longer happens in the future. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed
Original PR description
This commit adds a step in the click all test: for each view, enter and leave Studio, to ensures that the view doesn't crash in Studio. With the migration of views to owl, a lot of views worked fine, but crashed when entering Studio. Those issues have been solved now, and we want to ensure that this no longer happens in the future. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#107211
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108238
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108238
**Current behavior before PR:** In Email Marketing's Mail Body, The Powerbox is opened below the cursor, even when there's not enough space between the cursor line and the window's bottom. As a result, a part of the Powerbox cannot be seen. **Desired behavior after PR is merged:** Now, the Powerbox opens itself above the cursor line if it's too close to the window's bottom. Task-3037435 Forward-Port-Of: odoo/odoo#108283 Forward-Port-Of: odoo/odoo#104960
Original PR description
**Current behavior before PR:** In Email Marketing's Mail Body, The Powerbox is opened below the cursor, even when there's not enough space between the cursor line and the window's bottom. As a result, a part of the Powerbox cannot be seen. **Desired behavior after PR is merged:** Now, the Powerbox opens itself above the cursor line if it's too close to the window's bottom. Task-3037435 Forward-Port-Of: odoo/odoo#108283 Forward-Port-Of: odoo/odoo#104960
[FIX] note: fix the export all xlsx report error When the user exports the note records, an error is raised because the `__count` key does not exist in the result of the `read_group` method. Steps to reproduce: ------------------ - Go to the Notes - Click on the list view of notes and filter group by Stage. - Click on the export all button to print the excel report and see the error. Expected behavior: ----------------- The data should be exported in `csv` file. Current behav
Original PR description
[FIX] note: fix the export all xlsx report error When the user exports the note records, an error is raised because the `__count` key does not exist in the result of the `read_group` method. Steps to reproduce: ------------------ - Go to the Notes - Click on the list view of notes and filter group by Stage. - Click on the export all button to print the excel report and see the error. Expected behavior: ----------------- The data should be exported in `csv` file. Current behavior: ---------------- An error is raised when the user wants to export the data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108325 Forward-Port-Of: odoo/odoo#105698
In a grouped kanban view with progressbars, click on a progressbar to filter a column, and then click on the "+" icon of that column to quick create a record (e.g. in a project). Before this commit, the buttons ("Add", "Edit" and trash icon) overlapped the bottom of the card. This is due to special rules applying when a progressbar filter is applied. Those rules aim at grouping non filtered out cards on the top, s.t. the other ones (e.g. a dragged&dropped card) are displayed below.
Original PR description
In a grouped kanban view with progressbars, click on a progressbar
to filter a column, and then click on the "+" icon of that column
to quick create a record (e.g. in a project). Before this commit,
the buttons ("Add", "Edit" and trash icon) overlapped the bottom
of the card.
This is due to special rules applying when a progressbar filter is
applied. Those rules aim at grouping non filtered out cards on the
top, s.t. the other ones (e.g. a dragged&dropped card) are displayed
below.
It was decided that this grouping isn't really wanted anymore. For
instance, it could lead to weird UX if the filtered column contains
a lot of records, as the dropped one would appear at the bottom,
i.e. would not be visible for the user.
This commit thus simply removes those rules, which fixes the issue.
Forward-Port-Of: odoo/odoo#108265TaskID: 3105242 Forward-Port-Of: odoo/enterprise#35098
Original PR description
TaskID: 3105242 Forward-Port-Of: odoo/enterprise#35098
## Current behaviour Creating work entries in non-belgian company for an employee that is working part-time, whos calendar schedule creates credit times fails. ## Expected behaviour Work entries should be generated correctly ## Steps to reproduce - Install hr_payroll, hr_work_entry_contract - create a new resource calendar of 20 (the name is 20 hours, but just duplicate the default one and make sure you change the Sunday instead of Friday) - update default resource calendar (of 40hr)
Original PR description
## Current behaviour Creating work entries in non-belgian company for an employee that is working part-time, whos calendar schedule creates credit times fails. ## Expected behaviour Work entries…
## Current behaviour Creating work entries in non-belgian company for an employee that is working part-time, whos calendar schedule creates credit times fails. ## Expected behaviour Work entries should be generated correctly ## Steps to reproduce - Install hr_payroll, hr_work_entry_contract - create a new resource calendar of 20 (the name is 20 hours, but just duplicate the default one and make sure you change the Sunday instead of Friday) - update default resource calendar (of 40hr) from Sunday - Thursday 10:00 - 18:00 hr - Create a contract for a Test employee (which is not associated with any user) where the working schedule is a calendar of 20hr and enable the part-time tab set the schedule to 40hr/week - Click on the "Work Entry" smart button -> stacktrace (Check video in ticket logs for more detailed setup) ## Reason for the problem There is a key `is_credit_time` in the values used to create the credit times for the contract. But that field is only defined in the `l10n_be` payroll module localisation. ## Fix Remove the key `is_credit_time` during creation in `hr_payroll` module and re-add it in an override in the `l10n_be_hr_payroll` module. ## Affected versions - 16.0 - master --- opw-3088250 Forward-Port-Of: odoo/enterprise#35044
Before this PR, the next invoice date was updated at invoice confirmation. It would bring issues when several draft invoice would be created manually by salesman and then deleted. The next invoice date would remain in the future. taskid: 3082618 Forward-Port-Of: odoo/enterprise#35014 Forward-Port-Of: odoo/enterprise#34482
Original PR description
Before this PR, the next invoice date was updated at invoice confirmation. It would bring issues when several draft invoice would be created manually by salesman and then deleted. The next invoice date would remain in the future. taskid: 3082618 Forward-Port-Of: odoo/enterprise#35014 Forward-Port-Of: odoo/enterprise#34482
Before this commit, some tag would not display correctly in the tag list of project timesheet synchro This commit fixes this behavior Forward-Port-Of: odoo/enterprise#35069 Forward-Port-Of: odoo/enterprise#35003
Original PR description
Before this commit, some tag would not display correctly in the tag list of project timesheet synchro This commit fixes this behavior Forward-Port-Of: odoo/enterprise#35069 Forward-Port-Of: odoo/enterprise#35003