Versions:
---------
- saas-16.3
- saas-16.4
Steps to reproduce:
-------------------
1. go to a list view which starts with a numerical value;
- e.g. with developer mode enabled:
Settings > Technical > Scheduled Actions
2. group by any element.
Issue:
------
The width of the `o_group_name` elements is around 40px, not enough for
the names to be displayed.
Cause:
------
`list_renderer.js` calculates the `colspan` of `o_group_name` elements
based on the first occurence of a value that can be aggregated, i.e.
any numerical value. If this happens to be the first column, the
`colspan` is set to 1, leading to their width being the same as the
first column containing checkboxes. An update in saas-16.3 had forcibly
set these to 40px by adding the `!important` rule:
```scss
.o_list_record_selector {
width: 40px !important; // Force to 40px regardless by the font-size
}
```
Solution:
---------
After consulting the person who introduced the rule, we agreed that
removing it would be the easiest fix, unlikely to introduce any new issues.
opw-3459598
closesodoo/odoo#133521
X-original-commit: c89c94192685c989b65eb6b483b4120aa312252c
Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
luxon and moment are both used in the solution, but these two libraries
facilitate the manipulation of dates. It was decided to replace all uses of
moment with luxon so we can then remove moment.js from the code and lighten
the assets.
task-3391739
closesodoo/odoo#133144
Related: odoo/enterprise#46447
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Since 605943b5ea, the modification of a POS config while a session is open with that config is prevented with the error message "Unable to modify this PoS Configuraton because you can't modify Payment Methods while a session is open".
Steps to reproduce:
- Open a POS session
- Open the settings page of the POS config of the opened session
- For example, enable "Set Maximum Difference", then click on the "Save" button.
The error message "Unable to modify this PoS Configuraton because you can't modify Payment Methods while a session is open" is shown.
The fix consists in replacing the "invisible" property of the payment methods field by "readonly", as it was before the 605943b5ea commit.
closesodoo/odoo#133711
Task-id: 3487621
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.
closesodoo/odoo#133637
X-original-commit: d57bffae3b13a58580dc82db878ce8809878ff04
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Since [1], many tickets were created because of a crash preventing any
action in edit mode. This actually occurred in most databases were
snippets were saved previously (which probably is most old-enough ones).
Steps to reproduce on a fresh DB:
1. Enter edit mode
2. Drag and drop a snippet which contains an image, like "Text - Image"
3. Click on the image once (a tooltip asks to double click)
4. Save the snippet (not the page, floppy disk icon in the right panel)
=> You cannot do anything in edit mode ever again.
This is actually a combination of 2 bugs:
A. On step (3) in the steps above, the image receives the
"aria-describedby" attribute related to the tooltip... and it never
disappears (if the page is saved, the attribute is saved with it).
When saving the snippets we should probably clean such problematic
attributes to be sure anyway too.
B. Because of [1], the snippets saved by the customers and which
contain the problematic "aria-describedby" attribute are now the
source of a crash: we try to hide the related tooltips... even
though there is none, which causes a crash.
This commit focuses on fixing (B). (A) will need to be fixed later,
probably in an earlier version anyway.
[1]: https://github.com/odoo/odoo/commit/095721a9cace476c3eae445c7abd8f8b458aea36
opw-3475051
opw-3481944
opw-3482170
opw-3483220
opw-3483829
opw-3483837
opw-3484069
opw-3484647
opw-3484950
opw-3485343
opw-3485612
opw-3485623
opw-3485704
opw-3486096
opw-3486425
... and many more
closesodoo/odoo#133707
X-original-commit: 824be46dded7efacf2a351b78e723aa9e205b60d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This function became useless at some point, after the views and
actions have been all converted to owl.
closesodoo/odoo#133699
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Steps to reproduce:
- Create a product in KIT
- The product and components must be AVCO rated.
- Sell product, confirm delivery and post the invoice
Bug:
the journal entries are not reconciled.
the lines are gouped by product but in this case the products don't match
on the stock side it's the components and on the invoice it's the kit
Fix:
match components stock moves of kits to the kit product
opw-3208169
closesodoo/odoo#133683
X-original-commit: 376e3cd31427a6715dd86af91755baca733d94ef
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When installing point_of_sale and loyalty modules, then creating an eWallet program, the user gets an error that prevents him from creating the program.
Steps to reproduce:
- Install point_of_sale and loyalty
- Open the settings of the default POS Shop
- Click on the "Gift cards & eWallet" link (under "Promotions, Coupons, Gift Card & Loyalty Program" setting)
- Click on "New" to create a new program
- Change "Program Type" to "eWallet"
- Set a name for the program, then click on the Save button (cloud button)
The error "Split per unit is not allowed for Loyalty and eWallet programs." is raised.
This error is due to the reward_point_split hidden and not modifiable by user field of loyalty.rule that is not correctly set.
The fix consists in correctly setting reward_point_split for new eWallet programs.
closesodoo/odoo#132631
Task-id: 3474750
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Interac is the most popular Canadian debit card system [1]. To support
Interac payments in Stripe two changes were made [2]:
- "interac_present" was added as a payment_method_type when creating
the payment intent, and
- Interac payments are never captured
interact_present should only be added if the Stripe account being used
is Canadian [3] and transactions take place in CAD [4]. If either of
these is not true Stripe will return an error when creating the
payment intent. Stripe Terminal doesn't support non-native currencies
[5], so checking the currency should be enough, but to be extra
defensive we also check the country on the company before adding the
payment_method_type. [6]
To stop capturing we check the type on the payment_method and bypass
captureAfterPayment. We also add a check on canBeAdjusted because
these payments cannot be adjusted later on.
A known limitation is that it won't be possible to refund customers
via Interac. This requires an API call (not possible via Stripe
Dashboard) and isn't feasible in a stable release. Refunding needs to
happen with cash.
Testing this is not possible with a physical reader since Stripe
refuses to send Interac test cards to non-Canadian addresses. Instead
a simulated reader was used [7]. When developing this simulated reader
discovery was explicitly enabled in the code:
await this.terminal.discoverReaders({simulated: true})
Afterwards Stripe Terminal can be configured so that the next
transaction it simulates is an Interac one. To do so the following was
executed in a browser console:
posmodel.payment_methods[{ID}].payment_terminal.terminal.setSimulatorConfiguration({testPaymentMethod: 'interac'})
This only affects the next transaction, subsequent transactions will
use the default card_present again.
[1] https://www.interac.ca/en/content/business/interac-by-the-numbers/
[2] https://stripe.com/docs/terminal/payments/regional?integration-country=CA#create-a-paymentintent
[3] {'error': {'code': 'card_present_type_not_supported',
'message': 'The interac_present source type is not supported in US.',
'request_log_url': 'https://dashboard.stripe.com/test/logs/xxx',
'type': 'invalid_request_error'}}
[4] {'error': {'code': 'card_present_currency_not_supported',
'message': 'The interac_present source type with currency usd is '
'not supported in CA.',
'request_log_url': 'https://dashboard.stripe.com/test/logs/xxx',
'type': 'invalid_request_error'}}
[5] https://support.stripe.com/questions/stripe-terminal-country-and-currency-availability
[6] Ideally the supported payment type should be determined by the
payment_icon_ids m2m on payment.provider. But since pos_stripe
currently doesn't use that field this approach was chosen.
[7] https://stripe.com/docs/terminal/payments/connect-reader
opw-3376103
closesodoo/odoo#133694
X-original-commit: d6296af29653eb46df0dff9b6a87ee6e93486a0d
Signed-off-by: Joren Van Onder (jov) <jov@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Since 3c62ca1eb9, if the `_rec_name` value
is False, `name_search` and `name_create` will return a tuple of
(<id>, False). This is an invalid response for the web client,
which triggers a JS traceback.
Instead of using the old behavior (returning an empty string, resulting
in a partially invisible row in the Many2one selection),
use the same fallback as when the `_rec_name` doesn't exist.
Since `display_name` should never be Falsy anymore, remove part of the
test_mail_message_values_fromto_long_name that covers the
Falsy `display_name` case.
task-3424154
closesodoo/odoo#133691
X-original-commit: 0cb9e66edd9b7142a6e56bc6ee6491e6d6047e51
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
With the latest iot 23_07 image update the wifi connection was unusable.
We correct the activation of the wifi hardware of the raspberry with rfkill unblock all
closesodoo/odoo#133668
X-original-commit: c85497da60fbbc4b663d7de90c91de9068f25479
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This PR updates the few last occurrences of calls to the web_search_read method such that they now call unity_web_search_read, and replaces the implementation of web_search_read by the unity one.
This PR also removes the /web/dataset/search_read controller which was basically an indirection to the web_search_read method.
Part of task~3179751
closesodoo/odoo#133617
Related: odoo/enterprise#46566
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
*project,spreadsheet
The unity version of web_search_read will soon replace the older
one, so this commit prepares the work by adapting the remaining
calls to web_search_read s.t. they call unity_web_search_read
instead.
Part-of: odoo/odoo#133617
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>
Levi Siuzdak (sile)