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>
Before this commit, the PoS unnecessarily loaded all product packaging,
even if their corresponding products were not loaded in the PoS due to
the limited product loading option. Adding to this inefficiency, the
`add_packagings` function would only include those packagings whose
associated products were available in the PoS, making the loading of
all packagings pointless. The optimal approach should focus on loading
only those packaging whose products are already loaded into the PoS.
Also, if you scan a product packaging that was not loaded in the PoS,
it won't fetch it from the server.
opw-3436019
closesodoo/odoo#133559
X-original-commit: f2eb06c2089da27a0dfdc5e569fe50e65103ee8a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Related to previous commit c07181b20b,
this commit fixed missed remplacments of this.env._t by _t, also
replace one occurence of _lt (not exist anymore) and replace remainings
core._t.
closesodoo/odoo#133503
Related: odoo/enterprise#46496
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Current behavior:
When you settle an order in the PoS and completely validate it, the
remaining moves from the original sales should be cancelled.
However, it was not the case because we were not adding all the picking
in the `waiting_picking_ids` list. And so when we were checking this
list we were not cancelling all the moves.
Steps to reproduce:
- Setup multi-step routes (Inventory > Settings > Multi-Step Routes)
- Change the configuration of the warehouse to use the multi-step routes
- Create a sale order for any product and confirm it
- Open the PoS, and settle the order you just created
- Validate the order
- Go back to the sale order, and check the state of the delivery
- Only one picking has been cancelled
opw-3390529
closesodoo/odoo#133547
X-original-commit: c57b8286e3dedb75db68f27fc514224f6ba8d1c1
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
For loyalty programs of type 'coupons' with no rules defined,
the points were not being calculated correctly in the PoS.
The pointsForPrograms function was returning an empty list [] when
no rules exist. This caused _getRealCouponPoints to skip calculation.
This commit checks the program type and returns the points
if it is 'coupons'.
opw-3457550
closesodoo/odoo#133445
X-original-commit: 25ff280dfbec7e6d6f1c0a345e1902a2ab5c0774
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, in an editable list view grouped by a many2many
field, it crashed when the user tried to add a new record, because
the default value set in the context was wrong (it was an id, but
it must be a list of ids, containing a single id, the one of the
group where we want to create a record).
As this is a master fix, this commit takes the shot to refactor a
bit the way we extract information from groups returned by
webReadGroup, s.t. everything is now computed directly (before,
the serverValue was computed in the datapoint, which didn't allow
us to use it in the context). We can also get rid of the context
handling in kanban (where the bug wasn't present), as it is now
correctly generated in the model for everyone.
closesodoo/odoo#133420
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the ORM computation for account_account's root_id field, the root_id
will be set to NULL in the db if the code doesn't evaluate to True in
Python. This means that if the code is the empty string '', the
corresponding root_id will be False and the account will not be shown
under any root subsections in the chart of accounts, only the All
section (which makes sense). In normal use empty codes can't happen
because the UI doesn't allow it. The database does, which means it can
occur in certain corner cases.
The account root view computation is inconsistent with the ORM
computation and it will generate an empty account root with id 0 for an
account with an empty code ''. This account root can't be referenced by
an account because if the root_id is False, there is no reference and if
the root_id is 0, you'll get a traceback when loading the chart of
accounts. A read_group call will be done that filters on non-NULL root
id's (like 0) in account_account, but the ORM will then interpret that 0
value as False. This means the read_group call ends up returning a
boolean instead of a tuple for that line, which causes a traceback when
the tuple is expected.
So to summarize, this change prevents an account root that can't be
referenced from being generated in the obscure corner case where the
code is ''. It aligns the logic of the account root view computation
with that of the ORM computation.
I didn't keep the check on NULL from the original query, because the
code is a required field.
closesodoo/odoo#114279
Signed-off-by: William André (wan) <wan@odoo.com>
Don't do it only at install.
closesodoo/odoo#133505
X-original-commit: 359f3ac3075f4b79e830ebe33fded49f3e8febcb
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Christophe Monniez