Before this commit, many2one values were still returned as pairs
of id and display_name by unity read, whereas they should be
objects with keys id and display_name.
Part-of: odoo/odoo#133617
The recent upgrade to chart.js 4.3.0 has forced us to make our own
plugin to support gauge charts. The plugin was added inside the
o-spreadsheet library which means that we now require chart.js to be
loaded before o-spreadsheet.
Notice we created a `spreadsheet.dependencies` assets bundle but
we don't include it in `spreadsheet.o_spreadsheet` bundle not do we use
it in the webclient code.
That's because `Chart.js` cannot be reloaded after the spreadsheet bundle
is loaded and the plugin was added. Reloading it after would override
`Chart.js` and remove the plugin. To prevent such situation, we
use `loadJS("/web/static/lib/Chart/Chart.js");` which is memoized. The same
call elsewhere in the code base won't actually ovewrite `Chart.js`.
closesodoo/odoo#133369
Task: 3482480
Related: odoo/enterprise#46424
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, when the microsoft sync was reset with the following options:
- Delete from the current Microsoft Calendar account
- Delete from both
An rpc error was encountered:
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url:
https://graph.microsoft.com/v1.0/me/calendar/events/<event_id>
After this commit, the local events are deleted if necessary and
the non-recurring events are deleted on microsoft. We keep the
recurring one to be consistant with
https://github.com/odoo/odoo/commit/29ce2f0451c140cd16ecc26a51260661ede410bcclosesodoo/odoo#133051
Taskid: 3437386
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- only attributes related to products currently visible are
visible,
- duplication of attributes names in the search panel is solved.
task-3367295
closesodoo/odoo#126796
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Preparing the sales catalog to odoo 17 release:
- visual tweaks:
- color of the selected product more appealing,
- removing visual noise (border line),
- adapting dark mode,
- removing add adding spacing and margin where is needed,
Task - 3367295
Part-of: odoo/odoo#126796
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- fix the concurrency bug of removing items with the "Remove"
button not happening sometimes
task-3367295
Part-of: odoo/odoo#126796
Preparing the sales catalog to odoo 17 release:
- some functional additions/improvements:
- adding a button "Back to Quotation" to ease the navigation,
- make the "empty" help message more friendly and add a button to
directly create a product,
task-3367295
Part-of: odoo/odoo#126796
This commit fixes 3 bugs
------
Prior:
Deleting a weekly record from the calendar didn't remove it from the
employee's profile
Steps:
• Have a weekly location for the employee for Wednesday
• Go to the calendar and remove Wednesday location and choose that it's
removed for everyweek
• Check employee card
Current behavior: The weekly location for Wednesday still appears on the
employee profile.
Expected: The weekly location for Wednesday is empty
------
Prior:
Deleting a weekly record from the employee's profile removed all records
from the calendar.
Expected behavior: When a weekly location is removed from the employee's
profile only future records should be removed, the past records should
stay untouched.
------
Prior:
When hr_homeworking is installed, if there is a work location set for
the day it is shown on the employee's kanban card, but when it's not
specified it shows nothing, which can be confusing.
Expected: Show 'Unspecified' when location is not set.
task - 3439421
closesodoo/odoo#133671
X-original-commit: 9212e2ff95be61528cc9d249e6f2baec770b8907
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [this commit], it's now possible to edit a media when it's in a
parent that is not editable thanks to `o_editable_media` class.
Unfortunately, these changes make the new class bypass the potential
`data-exclude` defined in the XML option declaration. So if the target
looks like that:
```html
<img class="o_editable_media odoo"/>
```
and the XML option declaration has a `data-exclude=".odoo"`, the option
will still be displayed. This commit corrects the way the
`o_editable_media` class works, so that it only bypasses the
`.o_not_editable` but not the entire exclude.
[this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
task-3476644
closesodoo/odoo#133663
X-original-commit: f73734557116a348ac14b2724e1380546192ca12
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
- Create new SaaS database and set country to Philippines
Current behaviour:
- Fiscal Country is United States
Expected behaviour:
- Fiscal Country should be Philippines
task-3474384
closesodoo/odoo#133619
X-original-commit: 0f373827ac349bbf3b52360e9b6d8869f595a869
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Adapt SearchBar accordingly to properly keep the highlight effect during
keyboard navigation (cf. removed comments in dropdown.scss).
task-3439226
Part-of: odoo/odoo#133289
The `test_override_signatures` linter is about validating the parameters
of overriding functions. It verifies that when a method overrides another
from a parent model, the new method has a signature that is compatible
with the method it overrides: same arguments, same default values, same
annotations.
Because it also verified annotations, when a parent method was
annotated, all the child methods had to be annotated too. We actually
only care about the annotations when the two methods are annotated, we
don't want to enforce annotations on non-annotated methods.
Note 1: the shortcut to skip `(self, *args, **kwargs)` is broken, the
code has been removed.
Note 2: the code about `parent_class` is dead code that survived a
previous refactor.
Note 3: xdo likes it when I respect flake8-errmsg (EM101-103)
Part-of: odoo/odoo#133049
*:point_of_sale,pos_adyen,pos_online_payment_self_order,pos_restaurant,
pos_sale,pos_self_order,pos_self_order_adyen,pos_self_order_restaurant,
pos_self_order_sale
This PR adds the kiosk to the existing `pos_self_order` module, which
until now has enabled end-users to order their restaurant meals directly
from their smartphones.
We've added the possibility of creating kiosks / totems (devices with
large touch screens) that allow users to order their menu directly
without having to go through a waiter.
Once the order has been placed, the user will be invited to pay either
by adyen, already integrated into this PR, or at the counter.
At the end of the order, the user will receive an order number and his
table number if `service at table` is activated.
Main differences with the Self-order mobile:
- Kiosk shouldn't be accessible publicly
- Kiosk should support payments via card readers
closesodoo/odoo#129562
Design: XLU
Dev: ADGU & MODA
Taskid: 3323163
Related: odoo/upgrade#5024
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
This commit fixes the behavior of those customized buttons, used in
form view footers, aiming at saving/discarding the changes. The expected
behavior is that the dialog closes itself when those buttons are pressed,
which was no longer applied since the rewrite of views in Owl.
Also, the newly created value was not selected after saving the record.
Now, it selects it immediately if a button with special="save" has been
pressed.
A test has been added to verify that dialogs behaves correctly and close
themselves when clicking such buttons.
task-3254368
closesodoo/odoo#133602
X-original-commit: 331c2904e566cc74c46a097b2b1abe79b50d8672
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
In preparation to clean code of models, e.g. by simplifying model
insertion and reducing side-effects in record insertion.
This commit moves the implementation of the `insert()` in discuss
services to the models, and drop support of the service methods
`insert()`. The only way to insert a model is through the store
entry, e.g. `store.Thread.insert()`.
closesodoo/odoo#133509
Related: odoo/enterprise#46499
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue:
In project profitability, `account.move.line` from invoices without
the corresponding sales order with negative amounts where not taking
into account for the computation of the profit margins.
Steps to reproduce:
- Install Sales, Accounting, Project, Inventory
- Create 3 products:
- 1 service (S1), fixed price, creates project on confirm
- 1 service (S2), fixed price, creates nothing
- 1 storable (P), a lot of quantity on hand, invoiced when delivered
- Create an SO with SOL:
- S1 with price 0 (1 qty)
- S2 with price -320 (1 qty)
- P with price 320 (1 qty)
- Confirm SO, deliver P, create invoice
- Confirm invoice > Duplicate > confirm
- Go to the proj.profitability of the SO, notice that the negative
lines were not taken into account, leading to the addition of the
"Other Revenues" section with a positive 320 margin.
Cause:
The domain for the `account.move.line` was excluding lines whos
subtotal was not > 0.
Fix:
Change that domain leaf to be != 0.
Affected versions:
16.0 up to master
Reference:
opw-3389670
closesodoo/odoo#133597
X-original-commit: fc327869651158aee2ca01760606a36a464fa7b6
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Open a product page in edit mode.
- Replace the main image with one of your own.
- Click on the "Remove" button.
-> Nothing happens and the "Remove" button has to be clicked one more
time in order to work properly.
The goal of this commit is to remove the need of the double clicking
operation in order to remove a media. Before this commit, here was the
process that happened at the removal of the main product image:
- `'/shop/product/remove-image'` was called and the field `image_1920`
of the record (`product.product`) was set to `False`.
- A `request_save` was triggered up.
- At the "request save", the `Wysiwyg` performs two main actions:
1) `saveModifiedImages()`: Using the `o_modified_image_to_save` class,
the `Wysiwyg` saves the updated version of the image and sets its new
attachment URL in the `src` attribute before completing the save
process.
2) `_saveViewBlocks()`: in `save_embedded_field()`, the field
`image_1920` of `product.product` is updated tanks to the value saved in
the new created attachment.
The problem here is double: first, a useless attachment is created while
the user wants to delete the image. Second, at the end of the process,
the field `image_1920` of the `product.product` is not set to `False`
anymore.
To resolve this problem, the image is removed from the DOM before the
"request save". Thanks to that, no attachment is created at the "request
save". Moreover, because the image is removed, the field `image_1920` of
`product.product` is set to `False` at `save_embedded_field()` (see
`Image.from_html()`). Note that the rpc call to `remove_product_image()`
has been removed. Indeed, the modification of the `image_1920` field of
the records of type `product.product` and `product.template` is now
handled in `save_embedded_field()`. The `unlink()` of the
`product.image` is kept because the record has to be deleted at the
remove of a secondary image.
task-3111601
closesodoo/odoo#133546
X-original-commit: 00c5a939f622fb90e6d390012c0fcd458fdfe6d1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], some throttle calls have been replaced by debounced
calls. This commit modifies those calls in three cases.
The first case is to adapt the overlay covering when the window is
resized or content changes. Note: to reproduce the problem, you might
have to use a test tour for example, as the last operation has to be
done really quickly.
Steps to reproduce the problem:
- Go on a product page.
- Double click on the product image and replace it by one of your own.
- Quickly click on the "Remove" button to remove the product image.
-> Problem: In the `ReplaceMedia` option, the call to `destroy()` (due
to the change of target) is done after the call to `removeMedia()`.
A race condition appears here as since [this commit], the function
`updateCurrentSnippetEditorOverlay()` (responsible of the destroy of the
options whose `$target` are not in the DOM anymore) is debounced and not
throttled anymore. This is a problem for two reasons:
- We do not want the first call to the function to be deferred.
- We want this function to be executed at least at a certain rate if
there are a lot of `content_changed` events recorded in a short period
of time.
This commit also removes the call to a debounced version of a function
at a `mouseup` event in the context of the `ColorpickerWidget`. Indeed,
while the use of a debounced or a throttled version of a function is
totally justified at a `scroll` or a `mousemove` event, it is not in the
case of a `mouseup` event as the occurrence of this kind of event can
not be very high over a give time period.
Finally, this commit restores the use of a throttled version of the post
animation cover.
This can be justified by the fact that we want the post animation cover
function to be executed at least at a certain rate if there are a lot
transition or animation end events recorded in a short period of time.
[this commit]: https://github.com/odoo/odoo/commit/f4f0f783183507df8227b37fe1234c256325df6d
task-3111601
X-original-commit: 4c9eb9589e81b02945618195fbe12a4dd0ab9a50
Part-of: odoo/odoo#133546
Steps to reproduce the bug:
- Go on a product page of a product with multiple variants but no image
set for those variants. Because there is no image set to those variants,
the variant images fall back on the template image.
- Edit.
- Click on the variant image of the product. (Note that `.o_dirty` is
added to the element).
- Save.
-> The image of the product is not the template image anymore but a
variant image that is the same as the template image.
Because `.o_dirty` is added while clicking on the product image,
`save_embedded_field()` will set the `image_1920` field of
`product.product`. Because the product has multiple variants, the
`image_variant_1920` field of `product.product` is modified see
(`_set_template_field()`).
The problem is that the `o_dirty` class is added on the clicked element.
To solve the problem, the `MutationObserver` responsible for adding this
class is paused when modifying the tooltips. Note that it was introduced
by [1] but it was broken since [2].
[1]: https://github.com/odoo/odoo/commit/9f93fa8e77b11da2fcf60f606784eec49a94778a
[2]: https://github.com/odoo/odoo/commit/8eb0ca54200f0f8e1078bb6a0d507e747ccea122
task-3111601
X-original-commit: 3b8f601f95845d65a515e9c8bb8e25cc17565dbf
Part-of: odoo/odoo#133546
When the editor is displayed in a modal, the floating toolbar needs a
higher z-index than the modal in order to be visible. This is due to the
fact that the toolbar is mounted on the 'body' element (therefore, behind
the modal in terms of z-index).
The mobile toolbar, on the other hand, is mounted as a sibling of the
editable's element, which means it is always visible when the html field
is in a modal, without the need for a z-index. In fact, the mobile
toolbar, being fixed (no auto-hide) and having a z-index higher than
modals, leads to the undersired effect of being visible over modals that
are displayed on top of the html field. An example can be seen in the
Project app, where the editor is inside the task's description tab and a
modal can be opened for the customer.
This commit fixes such undesired visibility of the mobile toolbar over
modals by not applying the z-index to the toolbar when it's not
necessary (when not a direct child of the 'body' element).
task-3263463
closesodoo/odoo#133459
X-original-commit: ae569fd97737bc3fe02f12531857b8cc416c80e6
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit the floating toolbar would scroll over the headers
above the html field, such as the form view header and the web client
navbar.
This commit ensures the toolbar is hidden when it overflows the scroll
container.
task-3263463
X-original-commit: 96d180c7591bcb359c5b74796f39c0e36ea541fa
Part-of: odoo/odoo#133459
Before this commit the floating toolbar position was not being updated
on scroll events in certain scenarios. The problem resulted from adding
the event listener to the incorrect scroll container, which was
calculated only once in the Wysiwyg life cycle, on start.
The calculated scrollable container could be incorrect due to:
- changes in the web client resulting from the swich from read to edit
mode taking place after the Wysiwyg was started,
- changes in the web client resulting from a window resize (particularly
when, in the form view, the chatter switches position from right to
bottom and vice-versa),
- the editor being mounted inside an iframe and the scroll container
being an element in the top document.
- the editor being mounter inside an iframe and the scroll container
being the iframe's root element.
This commit solves the issue by detecting scroll events anywhere in the
document (and in the iframe's document when it applies) and updating the
toolbar position when the editable is a descendant of the scrolled
element.
task-3263463
X-original-commit: 5382c995eecfe2fcea39d9456860b48704645c99
Part-of: odoo/odoo#133459
*: web, website_sale_stock
Since [1], the widgets allowing to edit the different colors of a color
combinations are gone, except the first one. This is because the qweb
rendering calls have been modified to use the new `renderToElement` util
which silently ignores root nodes if there are multiple ones in the
rendered template. In the same way, a specific dynamic snippet and a
stock feature were also broken.
After this commit, those three features will be restored. A crash will
now also occurs in case `renderToElement` is called to render a template
with multiple root nodes (that is actually how the two last broken
features were found, breaking during existing tests). For the first
feature, a specific test has been made too.
[1]: https://github.com/odoo/odoo/commit/6303a3eacdca012649a2ffda627b65c17a7217f1closesodoo/odoo#133068
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This PR adds a panel to consult all attachments of a discuss channel
easily.
task-3476444
closesodoo/odoo#132784
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
before this commit, in the generate payment link wizard,
the copy button is always disabled and user cannot copy
the generated payment link.
after this commit, when there is no warning user can
copy the generated payment link from wizard
closesodoo/odoo#133542
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This component was necessary during the transition phase, when all
actions weren't converted to owl yet. Now, they are, so we can get
rid of this small compatibility layer.
Part of task~3439226
closesodoo/odoo#133489
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commits make a new standalone test for Markup()
The idea is to only flag the usage of Markup inside of runbot if
it is called on the non-constant string.
Markup('<span> %s </span>') % text #should not raise a flag,
Markup('<span> %s </span>' % 'text') #should raise a flag
closesodoo/odoo#131206
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Co-authored-by: Alex Roscav <roal@odoo.com>
*: attendance, expense, holidays
In commit d832fcf, the
`many2one_avatar_user` widget has been added in various places,
sometimes repeating the avatar where it isn't needed.
Some occurrences come next to the avatar's name which is called via a
`t-esc`, but the option `display_avatar_name` is available and has been
used instead.
task-3470340
part of task-3326263
closesodoo/odoo#133150
X-original-commit: 0b268a9e3c31d5b57bb9f60ea93153289d02ddf9
Related: odoo/enterprise#46286
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Allow developers to format integers/float
using "human_readable" options for integer
field (e.G. 500G instead of 500,000,000,000)
Use decimals options to choose how many float
number are displayed.
Let's see in unit test for examples.
task-3418678
closesodoo/odoo#130402
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Aaron Bohy