In some conditions, a x2many field can be considered
as modified by the webclient when in fact there is
no change in 'meaningful' stored fields.
In this case, on save, an empty list of magic commands
will be sent to the server, potentially triggering
unexpected recomputations.
Steps to reproduce:
* install sale_stock & sale_management
* create a new storable product
* create a new SO
* create a new line with this product
* Confirm the SO
* Set or Update the SO delivery date (Other info tab)
* Save
-> In the chatter, you will notice an useless tracking
value being printed for the SO Total, with identical values
before and after update.
Cause
Since the server received an empty list of commands for
the `order_line` field, this triggered a recomputation
of the total amounts of the SO, even though there were no
effective changes in the lines.
Solution
Do not send empty command lists for x2m fields.
This will avoid unexpected recomputation and also improve
performance since the fields were recomputed for 'nothing'
closesodoo/odoo#155549
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Bug
===
Since c5b87e130b , the Date / Datetime
are not formatted the way they suppose to be. So the value is not
correct (it contains the timezone, etc).
Because of that, the string "Invalid Date" is stored in database
instead of "YYY-mm-dd" when we change the default value in the
definition.
Task-3774178
closesodoo/odoo#155749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The commit 7452f855f05251a5458ddb4d654b03be1b179d40 was fixing the
problem in a simple way. It however wasn't good enough of a fix as we
discovered we were triggering too many onChange after the forward port.
So we revert commit 7452f855, and backport 5ffc604 from 17.1. It adds
a method on the model to reset the validity of a field.
It was not what felt the best, but as it is working and we just want to
fix the problem in stable, we go for it.
opw 3680495
closesodoo/odoo#156139
X-original-commit: 2fa3fd751a968a15a76d322c53241022b4b18ef3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
User settings is used to store user's preferences, in web we use it
to store the home menus apps order and in mail for various settings like
push to talk key, discuss sidebar preferences, etc.
Before this commit, the `setUserSettings` method from the user service
overrided all the previous key that has not been changed because it
kept only the changed keys returned by the backend.
Leading to preferences being lost during the session when reordering the
home menu apps.
With this commit, we keep the previous keys that have not been changed.
Steps to reproduce:
- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
"id": 1,
"user_id": {
"id": 2
},
"is_discuss_sidebar_category_channel_open": true,
"is_discuss_sidebar_category_chat_open": true,
"push_to_talk_key": false,
"use_push_to_talk": false,
"voice_active_duration": 0,
"volume_settings_ids": [
[
"ADD",
[]
]
],
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
"voip_username": false,
"voip_secret": false,
"should_call_from_another_device": false,
"external_device_number": false,
"should_auto_reject_incoming_calls": false,
"how_to_call_on_mobile": "ask",
"is_discuss_sidebar_category_whatsapp_open": true,
"onsip_auth_username": false,
"livechat_username": false,
"livechat_lang_ids": [],
"is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
"id": 1,
"homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```
closesodoo/odoo#155902
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, if a SelectionField was used in a kanban view
alongside the HandleField (enabling re-sequencing, i.e. drag&drop),
the "select" element couldn't be edited. This is because the d&d
feature calls preventDefault on almost all "pointerdown" events
occuring in the card, and the "pointerdown" event is the one that
opens the select.
There's no usecase in 17.0, but there's one in master, in the
product document kanban view.
We fix this in 17.0 which is the version that introduced the kanban
version of the SelectionField.
closesodoo/odoo#155827
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Current behaviour
- when we access the daterange picker it was observed that the apply button
appeared flatter and was not vertically centered.
Expected behaviour
- add h-100 on buttons container to ensure they are vertically centered and no
longer appear flatter
- add close button in which action is similar to pressing ESC or clicking
outside the popover
Task-3624556
closesodoo/odoo#148812
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce:
============
- on Planning create new shift
- select a template
- change the end date
-> the end date is reset to the template value
Problem:
========
- `end_datetime` and `start_datetime` have the same compute method
- `template_id` depends on `start_datetime` and `end_datetime`
- so changing `end_datetime` triggers the compute method of `template_id`
that will read `start_datetime`
- reading `start_datetime` triggers the compute method of `end_datetime`,
that will check if `template_id` is set and if so, will take its values
-------
why the compute method of `end_datetime` is triggered ? :
-------
- `start_datetime` is not protected from recomputing, at this
line : https://github.com/odoo/odoo/blob/saas-16.3/odoo/models.py#L6746
we only protect the fields sent by frontend (only `end_datetime`)
- frontend doesn't send `start_datetime` as it was not changed
Solution
========
as ORM fix can't be made in stable, we send `start_datetime` in the `onchange`
query even if it's unchanged to make sure both fields are protected
opw-3693206
closesodoo/odoo#155705
X-original-commit: 7081372e721387da983621b3dd2986ae0872e4c8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Before this commit, in a grouped kanban view with progressbars
and an aggregate field, after clicking on a bar to filter
records, the aggregate value was always 0 (at least when grouped
by a many2one or date(time) field).
This was due to a mismatch when trying to find the value of the
aggregate in the web_read_group result, as when grouped by a date
or datetime field, the key is `fieldname:granularity`, and we were
looking for the fieldname only. And for the many2one case, we were
comparing a pair [id, display_name] with an id.
This commit fixes the issue. It also fixes the mocked version of
read_progress_bar in the MockServer, s.t. we can correctly
reproduce the scenario in tests, as in the previous version, keys
in the returned object weren't computed the same way as in the real
read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A
similar fix has been done in [1]. This allows us to introduce a
test when grouped by many2one, which doesn't work as of 17.0.
[1] fd759f18d056844c486a68d0c394df5a03e789f0
closesodoo/odoo#155701
X-original-commit: 69b1809ed763d03560983bb0e4c996946dd694c5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since Odoo v16, we also use grid in the form layout (inner group).
In a group we use the CSS `grid-template-columns` with the value of:
* `fit-content(150px)`: for the first column (TLDR: col max 150px)
* `1fr`: for the second column (TLDR: take the "remaining" max space)
```css
.o_form_view .o_inner_group {
grid-template-columns: fit-content(150px) 1fr;
}
```
These rules at the first glance seem correct.
But due to "big word"/language, some unbreakable text is overflowing,
to avoid this, we have added the `text-break` BS class.
So now all text can be "squash"/wrap if there is no space available.
The problem is when we have a text be too long and unbreakable in the
second column, the label (first column) is squashed to see only one or
two characters.
In our case, the bug happens when we upload a file with a big filename
to an "Attachement" (`many2many_binary`) field.
On the `many2many_binary` field there is a custom CSS rules:
```css
.o_attachment .caption {
white-space: nowrap;
}
```
that force the text to not wrap on the next line, and so the grid takes
the width of the file name as its min value for the width of the
second column, and "squash"/wrap the first column.
This commit fixes the issue by allowing the second column to be smaller
than the `max-content` width using the css `minmax(0, 1fr)`.
Steps to reproduce:
* Open "Marketing automation" app
* Create a New campaign ("New" button)
* Click on "ADD NEW ACTIVITY"
* Select the "Mail Template" field
* Create and edit a "Mail Template"
* Click on the "Options" tab
* Upload an attachment with a long name
=> BUG, all labels (first column) are "squashed"
Note:
* the `text-break` class is equivalent to:
```css
.text-break {
word-wrap: break-word !important;
word-break: break-word !important;
}
```
* when we use `Xfr` (X a positive numeric value `1fr` in our case)
outside a `minmax()` notation, the GRID specs[1] specifies that it
should be converted to `minmax(auto, Xfr)`.
* also the `auto`[2] in the case of `minmax(auto, Xfr)`the value
represents the largest minimum size (in our case, the file name).
[1]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-flex
[2]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-auto
task-3644267
closesodoo/odoo#155650
X-original-commit: dbf1794799f2be54e0a0da7719cde3e5069fcdd9
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps:
- Open Timesheets
- Go to To Validate > All Timesheets
- Pivot View is rendered
Issue:
The validate button is not rendered when the pivot view is loaded
Solution:
The changes introduced in these files are aimed at enhancing the customization
and flexibility of the Pivot component in the web application. By adding the
buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer
template, developers can dynamically choose the template for
rendering buttons within the pivot view. This change is particularly beneficial
for scenarios where different button layouts or styles are required based on
specific use cases or user preferences. Additionally, the introduction of a
default value for buttonTemplate in the PivotView configuration ensures a smooth
fallback mechanism if a custom template is not explicitly provided.
Overall, these adjustments contribute to a more adaptable and extensible
Pivot component, catering to diverse application requirements.
Task-3623493
closesodoo/odoo#155547
X-original-commit: f7fa6d66758b7ccbb0ae44e9f977177e6b29da6e
Related: odoo/enterprise#57591
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
With this commit, overriding the `onWindowClick` function from `dropdown.js`
becomes much simpler. Previously, it necessitated overriding the entire function,
but now it can be done with minimal effort by just overriding this specific part.
task-3717014
closesodoo/odoo#155326
X-original-commit: edf3c7f5c566f530bed2f243a6f78fcf7d1196d2
Related: odoo/enterprise#57471
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
On the contact kanban view, add as much tags as possible. The point is to make the right hand
part of the kanban card as tall as possible.
Before this commit, the image (on the left hand side) of the individual partner was taking all the space
in the y-axis, which was on purpose, but the cropping of the image made it so that the image
lost is sense: a face was too much cropped, or, if the image did not have sufficient pixel density, it was
pixelized.
What is specific to 17 that is barely applicable in earlier versions, is the changes in the display of many2many tags
in the kanban record: they now take more space and at a faster pace.
After this commit, we constrain that image to a maximum height and centering it.
opw-3748585
opw-3751016
closesodoo/odoo#155359
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
During the revamp (https://github.com/odoo/odoo/pull/138670) the
classes `.o_event_hatched` and `.o_event_striked` were moved.
The `o_event_hatched` works on day, week, and month
view but not in Year view of the `hr_holidays` module where the events
all look like they have the same status. The `o_event_striked`
was removed by mistake.
To fix this issue, we move the `.o_event_hatched` where it isn't under
the `.fc-event` selector (because this one doesn't exist in Year view),
and we put back `o_event_striked`.
task-3617333
part of task-3575827
closesodoo/odoo#144208
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.
In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.
This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.
We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.
A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.
Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.
=> An error dialog was displayed.
The same issue happened with a nested menu instead of a mega menu.
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc
task-3614926
opw-3741670
closesodoo/odoo#155019
X-original-commit: 48f0c4203ceb5e770fed6193bd6382690b1b62fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*account,hr_expense,purchase,repair,sale,spreadsheet_dashboard_*,web
In Chile, "Untaxed Amount" has its own special term that isn't used in
Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [Chilean customer
changed what term should be once fw-port was at v17]. Therefore
everywhere that it appears (in a .pot file), we ensure that the es_CL
localization uses this term.
Also untranslated terms from the es_CL.po files that were edited have
been removed since they add no benefit and make it harder to read the
file (we expect to only add terms to the file, not translate every
term for Chile).
opw-3670297
closesodoo/odoo#154473
X-original-commit: d1d4d30ef402ce835cba892459fdceadfc9944e1
Related: odoo/enterprise#56853
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit, calling _applyCommands with a lot of commands
DELETE or UNLINK on a StaticList already containing a lot of
commands was very slow. This happened for instance in the Automated
Rule form view, click on "Add an action", and in the dialog form
view, select a "mail" type, e.g. "Add followers". In that form view
there's a many2many field "available_model_ids" which contains at
first almost all models of the database (LINK commands). Switching
to a "mail" model restricts those models to the ones inheriting
from the thread mixin, i.e. it generates a lot of UNLINK commands.
On runbot, in represents 1000+ LINK and UNLINK commands. This
could take several seconds.
With this commit, we no longer iterate over all commands when
applying UPDATE, DELETE or UNLINK commands. Instead, we generate
at first a mapping of record ids to their own commands, and we
then have a quick access, given a record id, to the list of his
commands, which is small in comparison to the whole list of
commands. After iterating over all commands, we generate the new
list of commands and we update this.records and this._currentIds
to do the necessary cleanups (i.e. removing records and ids for
which we received DELETE/UNLINK commands).
task 3599674
closesodoo/odoo#154568
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Consider models A and B such that B inherits from A (with _inherits),
and a form view of A with a one2many field that inverses the many2one
"delegate" field from B to A. When adding a new record in the one2many,
onchange() crashes while trying to update the cache of an empty parent
record.
The situation is caused by how onchange() initializes the new record of
model B, and the fact that the form provides a value for the delegate
field. The new record is actually initialized with an empty value for
the delegate field, which causes the code to crash. The fix simply
consists in updating the parent record only if is nonempty.
opw-3744514
closesodoo/odoo#154735
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Steps to reproduce:
- Go to Documents activity view.
- Click on Schedule activity.
- Perform multiple clicks on any record.
Issue:
The 'Schedule Activity' wizard opened as many times as the record was clicked.
As a result, even after successfully scheduling an activity on that record,
the user still faced multiple open wizards remaining and had to manually close
each one of them.
Fix:
This commit introduces a method `executeOnceAndClose` which makes use of a
flag 'busy' to ensure that the `onSelected` function is called only once and
hence exactly one `Schedule Activity` wizard is opened, despite clicking a record
more than once.
closesodoo/odoo#154442
Task: 3721404
X-original-commit: 19cc5ea3cf2c8fcf742ba5ab9b4b82305d81d555
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes a pretty specific issue within autocomplete behavior
where the change event after clearing the value is prevented.
Steps to reproduce:
- go to an empty autocomplete and click on it
- start typing a search with results
- click on the first result
- without focusing out, clear the input and finally click out
No change event is triggered on click out in this case so the cleared
value is not updated in the end and saving the record will keep the
non cleared value.
The t-on-mousedown.prevent in the dropdown was mainly used to keep the
focus on the input after selecting a value for the autocomplete. This
introduces a side effect: when one starts typing on the initially empty
autocomplete, the browser keeps the initial value of the input in memory
until it is focused out (and therefore blurred). When the input is
focused out, it will compare the current value of the input with the
stored initial value and decide to trigger a change event based on the
comparison between the two values: if these are different, the change
will trigger. In our case, since the mousedown event on a search result
is prevented, no focus out will happen and therefore the browser will
still wait for the next focus out to trigger the eventual change event.
But since we clear the input before focusing out, the two values are
empty and no change event is triggered which introduces the issue.
To fix it, we remove the t-on-mousedown.prevent of the template and
manually avoid triggering the onInputBlur method with a flag to keep
the previous behavior and we finally focus on the input programatically
after selecting a value.
task-3734818
closesodoo/odoo#154448
X-original-commit: 9d3d5d937e37ab6ef0c393e11cfb449f2897f6c1
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
This commit follows [1], which attempted to fix CORS errors
occurring when we access the `cssRules` property of stylesheets,
to detect scss compilation errors and display a warning to the
user.
[1] doesn't seem to be enough, as we faced another source of CORS
errors. Indeed, in non-secure http, the error is raised even if the
origin is the same.
We never want this access to crash anyway, as it's a nice to have
feature, and if reading `cssRules` is forbidden, there's nothing
the user can do anyway. For those reasons, we decided to simply
protect the code with a try/catch.
[1] odoo/odoo#152696
opw 3746910
closesodoo/odoo#154347
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Issue:
------
On the calendar application, it is not possible to create a 15-minute event
directly from a selection using the mouse.
An event with a default duration of one hour is created.
Cause:
------
The fullcalendar library detects two events:
- a date selection
- a click
The date selection is correct, but the size of the "rectange" is the same
(15 minutes is the smallest unit in terms of size).
As a result, a click using a default time is detected.
Solution:
---------
We can use `preventDefault` to block the second event (the click)
because the event is the same.
Note:
-----
This fix is safer than patching the `FullCalendar` library
(which may change in future versions).
opw-3743945
closesodoo/odoo#154135
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, `.bg-view` was set to `.o_notification`. This was
creating an issue in the front-end where `.bg-view` doesn't exist,
making the background of the notification transparent and ultimately
causing readability issues. Issue introduced in [1].
This commit changes the way we apply the background from a utility
class approach to a SCSS approach. That way, we can easily override
in `website.scss` with the `$body-color` of the website.
task-3716367
[1] 4e1f0b8ea522accae4860937c2fb3815281e8483
closesodoo/odoo#154081
X-original-commit: f8f8d2905db633cfaaa93b6cd163f4ab55dc4c8f
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate developer mode
3- Navigate to any storable product
4- Click on 'Replenish'
5- Click on 'developer bug' and Choose 'Set Defaults'
6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save
Current behavior before PR:
When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI.
Desired behavior after PR is merged:
It is handled now from the UI side that the format that is been sent is the server valid format of datetime.
opw-3692472
closesodoo/odoo#154209
X-original-commit: 6dc46639935fdc175b2d094b58ef4e66c68466b0
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Description:
When searching with a domain that contains a relational field whos
comodel is `res.users`, with a *pathological* domain of `not ilike`
`'some_string'`, the ORM will call a `_name_search` on `res.users`
with no limit to resolve the leaf when calling `_where_calc`.
The current implementation in the `web` module overrides the
`_name_search` to implement a spec to propose the current user as a
first suggestion, but to do that it first execute the query
(the list conversion), and then manipulates the list of ids to insert
the current user first. (1c2ce8c213)
On large databases with many `res.users`, where the condition matches all
users besides 1, this is a probably Seq.Scan on the `res_users`
table. Then this gigantic list of `ids` will be injected by the ORM
into the main query to satisfy the original domain. This incurs not
only bandwidth costs, but also usually leads to bad plans, ending up
most likely into a Seq.Scan on the original table.
The worse of it, in the case of a `web_search_read`, there is a
`search_count`, so this whole fiasco is repeated once more.
The nail in the coffin, is that the result isn't even needed, when
resolving a comodel's `_name_search`, we care about the subset, the
internal order is irrelevant.
Solution:
The ORM calls the `_name_search` without a limit, while in general the
`name_search` is called with a limit from the front-end, therefor we
can use it as a discriminant -> If no limit, don't suggest `uid` first.
Affected versions:
saas-16.3 -> master (saas-17.2)
Reference:
task-3610657
closesodoo/odoo#154149
X-original-commit: 83aa46a4ab88c0226b1aa1dc36671d3208a0835a
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to
"Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and
thus are skipped inside `computeReportMeasures` unless they are passed
in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is
passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure.
This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
closesodoo/odoo#153967
X-original-commit: 76178cd61ba10ff29b24183edb550c54b319a230
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce the bugs:
- Install the e-commerce on your website.
- Go to the "/shop" page.
- Click on "Edit" to enter edit mode.
- Click on the "Customize" tab.
- Choose "Cards" for the "Style" option.
- Enable the "Product Description" toggle.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to exit edit mode.
- Bug 1: The product description and the price in the product cards are
not visible.
- Bug 2: The scrollbar below the category buttons has the same color as
its background.
- Click on the "Mobile Preview" button in the backend navbar.
- Click on the "Filters" button on the page to show the offcanvas.
- Bug 3: The text color in the offcanvas is not visible and the
background color of the inputs is the "body" background color instead of
the "offcanvas" background color.
opw-3570774
closesodoo/odoo#153930
X-original-commit: add2b9273e90e3940ee52eee4ff42afa46c18a20
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website_sale
Steps to reproduce the first bug (popover):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Hover over the cart in the navbar to make the popover appear.
- Bug: All the popover texts are not visible because they are white and
the background is white.
Steps to reproduce the second bug (extra price badge):
- Install the e-commerce on your website.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Bug: The text of the "extra price" badge is not visible because both
text and background are white.
These two issues existed because the text color of those elements
depended on the body's background color. With this commit, the text
color for those elements is now determined by their respective
backgrounds.
This commit is a follow-up to this commit [1]. We also add the handling
of the text-muted color to ensure it remains visible if a modal has a
dark background while the body background color is light. Before this
commit, we only handled the opposite case (dark body and light modal).
This commit also fixes the text color of the button in a file input of a
form when the background color of the <body> is dark. Similar to the
other elements fixed in this commit, the text color of this button could
be invisible because it was the same color as its background.
[1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7
opw-3570774
X-original-commit: 0c2806576e85106d06f4275c9204e664f69793d8
Part-of: odoo/odoo#153930
The string value of an empty array is `""` which is falsy. Prior to this commit,
if all optional columns headers were disabled in a list view, it would result in
a reset of those when the view is mounted the next time, instead of keeping them
disabled like in prior versions.
task-3692178
closesodoo/odoo#153831
X-original-commit: e600ed2fa2f2e612dfca20872356ae926dde0a54
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Versions
--------
- 17.0
- 17.1
- master
Steps
-----
1. Go to Settings / Manage Languages;
2. select your current language;
3. set First Day of Week to something other than Sunday;
4. go to Time Off app.
Issue
-----
Weeks in year overview still start on a Sunday.
Cause
-----
Commit 52dae7a2f0 hardcoded `firstDay` to
Sunday for the `hr_holidays` module. This was a workaround to some
issues with `fullcalendar`'s week number calculations.
Solution
--------
Remove the hardcoded `firstDay`, and add a custom week numbering
function to be used on week, month, and year calendar views for
consistent numbering that allows for different first days of the week.
The function returns the ISO week number of the Monday nearest to the
configured first day of the week, i.e. the following Monday when first
day is set to Friday, Saturday or Sunday, the previous Monday if first
day is set to Tuesday, Wednesday or Thursday.
There were 3 main considerations for deciding a week numbering method:
1. no exisiting setting for users to decide on a method;
2. the ability to pick a first day of the week independent of locale;
3. the version of `luxon` used being unable to factor in locale.
Addendum
--------
This commit doesn't fix the issue with group-by week numbering in list
view. These stem from `babel`'s inconsistent locale defaults and
inability to take user-configured first day of the week into account.
opw-3668175
closesodoo/odoo#148623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, to render the table, the project task list
view computed the list of selected records once for each cell,
and then iterated over that selection to check whether selected
tasks were all associated with the same project (to set the
stage_id field readonly if not). However, computing the selection
requires to iterate over all records, so the rendering was O(n^2).
As a consequence, the rendering of (not so) large tables was very
slow (~1s for 80 records).
With this commit, we compute only once for the whole table whether
the selection contains records from different projects.
closesodoo/odoo#153611
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit's purpose is to fix the re apparition of personnal stage on
the todo app when personnal stages are deleted one after the other.
Step to reproduce:
-login as Marc demo
-open todo
-delete any personnal stage without any todo in it
-delete any personnal stage with at least one todo in it
The personnal stage deleted first is now present again in the kanban
view. Note that it is only a frontend bug. The record has been correctly
removed from the db, and any action with it will trigger a cache miss
exception and reloading the view completly will removed those ghost
stages definitly.
Source of the problem:
The problem is that the deletion is only reloading the view completly
when a record with child data is removed. More precisly, the
_deleteGroup function of the dynamic list triggers an rpc call to update
the config of the component only when a record with child data is
deleted, and that data need to be switched to another record, while when
it is an empty record, the record is simply removed from the group
field of the list. The issue is that there is thus a mismatch between
the group in the list.config.groups and the list.group. And when the
config is updated, only the list.config.groups is used to update the
config, meaning it potentially still contains element that were already
deleted.
Solution:
Doing a check up on the list.group to ensure that any deleted element is
also removed from the config when an update is triggered.
Note: I dont why Mitchel admin did not trigger the bug. Code wise, it
should happends no matter the access right of the connectedd user.
Version affected:
17.0+
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#142536
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Previously, when exporting its state so that it could be restored later,
the relational model would export its config. The problem is that
because this config is a reactive object, it keeps a reference to the
components that may need to be notified by that reactive object. This
exported config was then stored on the next controller, which would be
retained by the next config, etc.
This commit fixes that by exporting a raw version of the config.
Part-of: odoo/odoo#153654
This PR fixes 2 issues with discuss navigation:
1. Broken backwards navigation when going back and forth from the live
chat session history.
2. Broken backwards navigation when trying to access the same thread
than the current one.
Steps to reproduce 1:
- Open the command palette
- Go to the live chat session history view
- Click on one of your channels
- History back => leads to the session history view
- History forward => leads to discuss
- History back => stays on discuss, history is broken
This occurs because the active id is not passed in the action context
when navigating backwards which leads to the URL being pushed again in
history (URL without active id is different). The active id should be
put in the context when available.
Steps to reproduce 2:
- Go to discuss
- Click on the active thread
- History back => stuck on discuss, cannot navigate backwards anymore.
We should not push in history when accessing the same thread than the
current one.
task-3422516
closesodoo/odoo#153094
X-original-commit: 029b79ad7dc28aab83289e7c3ebd4cc0dcc5d609
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Before this commit:
When the user creates new stages or groups in Kanban view and adds new tasks
with particular states and then if the user clicks on any colour in the
progressbar then the filter gets applied on all the groups or stages.
Observerd Behaviour:
The filter is applied on all the groups or stages.So, if we click on a colour
in the progressbar suppose colour Green to filter out Approved task(s) of a
particular stage then in that stage or group only the Approved task(s) would be
visible. Also the filter would get applied on all other stages or groups created
at that time. In those stages all the task with that state would be visible and
rest of them would get blurred.
Steps to produce:
- Install `Project` and add a new project in it.
- In the newly created project add some new stages or groups, each consisting
some new tasks.
- Give some states to those tasks through project state selector
(for eg: Approved, Changes Requested).
- Click on any particular colour in the `Progressbar` of any particular group or
stage.
Expected Behaviour:
When the user clicks on any colour in the progressbar then it should filter out
only those tasks which are associated with that color/state and only in that
particular group or stage.
Reason:
https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114
group.serverValue results as Undefined. Because when the data is being prepared
here:
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231C11
there is no serverValue provided. So, whenever a group is getting created
here serverValue `Undefined` as value.
https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25
Note:
- There was a need to change the function name from
`getServerValueFromGroupData` to getGroupServerValue as now now this function
calculates serverValue while the data is being created and not when the data is
already created.
- The function is exported into another file as this function defines the basis
to calculate serverValue and there is a necessity to calculate serverValue while
data is being created.
Task-3620697
closesodoo/odoo#149694
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When reading values in reactive objects, Owl's reactivity system will
return reactive versions of the sub-objects to allow tracking reads in
depth, so that changes to values in deep object hierarchies can still
cause components to render themselves if needed.
Luxon objects are immutable. Since they cannot change and values inside
them cannot change either, tracking reads within luxon objects is pure
overhead.
This commit makes luxon objects non reactifiable by setting the
Symbol.toStringTag property on the luxon classes, which is what Owl uses
internally to determine if objects can be made reactive. It will also
cause some of these objects to serialize to more specific strings
instead of just [object Object], eg [object LuxonZone].
closesodoo/odoo#153540
X-original-commit: ac58cb22cd8b275f89bf387a6cea8144ce26ee65
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Have a grouped list view s.t. there's a group with enough records
to have a pager in the group. Go to the second page of that group.
Then, apply a filter such that there's only a single page remaining
in the group. Before this commit, no record was displayed, because
the previous offset wasn't reset to 0 it should have been. With
this commit, the offset is recursively reset, so we correctly
display the records of the first page after a reload.
closesodoo/odoo#153494
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this PR, the `test_complete_chatbot_flow_ui` would sometimes fail
when checking if the user can add a reaction to a message.
There are two issues:
- This step uses the `contains` helper and specify the live chat `ShadowRoot`
as the target. However, the `contains` helper uses a mutation observer
that observes the light DOM thus, changes in the shadow root are not
correctly observed.
- The target passed to the `contains` helper is the `ChatWindow` DOM
element but this element can be unmounted in-between.
This PR fixes this issue.
fixes runbot-56670
closesodoo/odoo#153382
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results.
Sometimes however the number of results can exceed the maximum number of
arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them
afterwards with the selector, we find all the elements that match the
selector in the closest `<body>` parent and then we keep only those
contained inside `$from`.
opw-3703963
closesodoo/odoo#153161
X-original-commit: 2667c8d42c5ac18257975e166a2aea254416e3fa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
This commit fixes an issue caused by the way we use onInput props in Knowledge to
fetch articles depending the current search value. Since we start from an empty
string in the input again, it make no sense to display the choices previously
fetched with a search value no longer displayed in the UI. The only way to display
the correct items is to update the input value, then put an empty search to fetch
accordingly.
This is clearly an issue, when the onInput props is used to fetch the content of
the SelectMenu, depending of the search value. The UI obviously display an empty
search, and filter accordingly, but without fetching the items corresponding to
the empty search value.
A test was added as well to assert SelectMenu can be used for this purpose without
forgetting to call onInput again when clearing the search value in beforeOpen.
closesodoo/odoo#153072
X-original-commit: ca417f171b1bd2dd567beed7bc0e1fcaba6c8a4c
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes the style applied to the o_select_menu_sticky elements. Since the
fix from commit (1), the text cursor is shown when hovering those elements. This was
without considering the fact that this class is mainly used to display elements on
top of other elements of the component.
This includes usages with the bottomArea slot, that can be used with a DropdownItem.
Because of the changes from the commit previously named, the focused color was no longer
applied, and it was showing the wrong cursor when hovering.
1) 53466e152bb819524b2890866bea4cbdd9091275
X-original-commit: 8ecc6f2a960494f01a745f21a24c3cc57614ad86
Part-of: odoo/odoo#153072
Commit [1] moved (almost all of) the code of formatFloat from
views/fields/formatters.js to core/utils/numbers, to make it
accessible in the frontend. A formatFloat function was kept in
formatters.js to handle the false case, which makes no sense in
number utils, but is useful for fields. However, a lot of imports
have been updated to use the numbers.js instead of formatters.js
(i.e. they no longer benefit from the support of false), whereas
they are actually formatting field values, so they should have
kept using the formatFloat from formatters.js
This commit adapts the places where the formatFloat to use must
come from formatters.js, not numbers.js.
[1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8
task 3722043
closesodoo/odoo#152810
Related: odoo/enterprise#55919
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
This commit solves an issue where sample data would be erased when the
user switches from a view with no sample data to another that should
contain them. This commit also removes unnecessary usage of nextTick in
assets loading.
Steps to reproduce:
- go to project and open one
- enter a no match filter and save it as favorite
- reload
- switch from kanban to calendar view and switch back to kanban
- after the fix, sample data should no longer be erased from kanban
task-3701143
closesodoo/odoo#152666
X-original-commit: a8ff1465c6c31240d06c98fa5d61e146b3908cf0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
