- replace order summary by a dropdown like mobile view
- remove 'Pay With' title
- match 'Choose delivery method' style with 'Choose payment method'
- make order summary sticky so that 'Pay now' is always accessible
task-3741412
closesodoo/odoo#154035
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
People may have used a m2m where we don't really want a m2m relationship.
Task-3605612 (WhatsApp: Fix header / upload / reporting usage)
closesodoo/odoo#160332
X-original-commit: 910e41baf0d6ab558c53d41e511b3f10bf9860ad
Related: odoo/enterprise#59987
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Deleting a partner may take a long time because odoo has to check an
entire table to find few records or no records at all that reference the
partner and set it to null.
So we are adding an index btree not null to speed up the deletion of
partners.
closesodoo/odoo#160184
Task-id: 3759406
Related: odoo/enterprise#59932
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Having the VAT VIES Check valid field directly next to the VAT number
as an inline element becomes unreadable, so we wrap it add padding and text-nowrap
closesodoo/odoo#159332
Signed-off-by: William André (wan) <wan@odoo.com>
This commit reverts odoo/odoo#133504, as it was deliberating access to private
event information to uninvited administrators in the calendar view. Only the
event organizer and its attendees must be able to fetch private events information.
In addition, two tests have been added to: 1. ensure the confidentiality of
private events from uninvited administrators and 2. prohibit uninvited
administrators from edit the information of any event, private or not.
task-3837646
closesodoo/odoo#160308
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
The `website_livechat.chatbot_redirect` tour checks that the chat bot
still works after redirection. The tour waits for the chat bot message
that indicates the redireciton was made. Since the tour restarts the
bot to test two differents flows, this message is already present
before the second redirection occurs. The tour should instead wait for
two occurences of this message the second time.
closesodoo/odoo#160296
X-original-commit: cfdcdc405751e2d8d81dbbec34894d3da9c005ef
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
This commit improves the UX of the color picker's hex input in two ways:
- If the user enters a hex color without the "#" symbol, it's
automatically added.
- As soon as a valid hexadecimal color is entered in the input, the
colorpicker updates, and the color is applied to the target element.
task-3747408
closesodoo/odoo#157034
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit, clicking in the area below the "Hex color" input
would close the color picker. This was annoying when entering a value in
the "Hex color" input and then clicking below to confirm it.
After this commit, the color picker no longer closes when clicking on
its background.
task-3747408
Part-of: odoo/odoo#157034
Steps to reproduce the issue:
=============================
- Go to website and open editor
- Click on the 'Contact Us' button
- Change the color of the text
- error
Origin of the issue:
====================
`HistoryReverCurrentStep` will call `observerFlush` which will mark
`_toRollback = true` and in `_observeOdooFieldChanges` we will update
the html with `withoutRollback` but this only works only if
`_toRollback` is `false`.
Solution:
=========
We need to rever the step without rollback too.
task-3770287
closesodoo/odoo#156461
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This route is no longer used in our code and it tries to read templates
that are no longer existing, leading to a crash if called manually.
closesodoo/odoo#160277
X-original-commit: 130ac07ccf14cca3d9dd4e0cd897e00d1c0b6055
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
In `ir.model.data` model, there is no SQL constraint which is
ensuring that the `name` field can not contain `.` (dot)
So when loading the translations to database if the xmlid's `name`
contains dot then `xmlid.split('.')` will split it more than 2 parts.
Which will cause issue during saving it to database as it is expecting
2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts
with `maxsplit=1`
closesodoo/odoo#160228
X-original-commit: a1ae06f499b183db69b7e763a2803a079f540a77
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
If an error happens when a website page is being saved, the error
message was displayed as a popup on the edited block.
Since [1] that error was not displayed anymore because the call to
`ir.ui.view`.`save` from `this._rpc`, which wrapped errors into a
message, was changed to `this.orm.call`, which raises errors in their
original form.
This commit adapts the error handling to expect an actual error instead
of a message.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
task-3599890
closesodoo/odoo#155071
X-original-commit: 7d5aeabebbc56ac22d06e8291e1cf58b62d4defe
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, when the clickbot detected an error dialog, it
stopped the test and throw an error saying that an error dialog was
detected. This information is not enough to check why, and how, the
error dialog was produced.
Now, we also log the content of the error dialog as well as all the
information of the last rpc that was in error.
closesodoo/odoo#160103closesodoo/odoo#160272
X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This is done together with an enterprise commit in order to avoid creating mail alias automatically on journals imported via FEC files, in France. Indeed, such files could contain journals with different codes but same name, each of which would try creating an alias with the same name, raising an error.
OPW 3813584
closesodoo/odoo#160168
X-original-commit: 16c305dd3ceda91a84ae073dc1252891bf7af390
Related: odoo/enterprise#59921
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Issue:
- When printing a Payment Receipt the name
"INV0001" is added to the title.
Steps To Reproduce:
- Accounting > Vendors > Payment
- create new payment and print payment receipt.
Solution:
- The issue was using a self-closing <span> tag and
incorrectly placing the INV0001 placeholder outside it.
- I placed INV0001 within an opening
and closing <span> tag for correct dynamic content replacement.
opw-3820212
closesodoo/odoo#159915
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.
Steps to reproduce:
-------------------
* Go to the **Contacts** app
* Select any contact (ex: Azure Interior)
* Under **Contacts & Addresses** select Add
* Select **Invoice Address**
* Write the address then **Save & Close**
* Go to the **Point of Sale** app
* Add items
* For customer, select the contact we just modified
* Select **Payment**
* Select any payment method
* Select **Invoice**
* Validate
> Observation: The invoice address is not used
Why the fix:
------------
We observe a discrepancy between the sale and pos output for the same workflow.
* Sale
* Sale order form: `Customer` -> Azure interior (Has a field for invoice address)
* Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address)
* PoS
* PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address)
* Account move form: `Customer` -> Azure interior
In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move.
In the sale workflow, the move is created with `invoice_vals_list`
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207
Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address.
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004
With `partner_invoice_id` computed as follows:
https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342
Thus, we also send the invoicing contact address as partner_id when creating the move in pos;
opw-3797434
closesodoo/odoo#160154
X-original-commit: ab904c7e06f481f28cd581b9e677d0db9bf608f1
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
If user had less than 1 point, which is equivalent to 1 quantity of set
currency, on gift card and eWallet, they could not use it due to not enough point on
Gift Card and eWallet for claiming reward.
opw-3667934
closesodoo/odoo#159984
X-original-commit: 64711a9152b6bb661392882d3403c194f5990fbc
Signed-off-by: anko-odoo <anko@odoo.com>
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell
in spreadsheet, instead of zero.
closesodoo/odoo#159148
Task: 3827502
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Follow-up of [1] which changed code in stable in such a way it could
break when the function was used in a way it was not intended to in
some custom code. Note that the function could also be used by giving a
string selector to it, that will not work anymore: but instead of
crashing, this commit will just make it do nothing (it is only about
adding a button loading effect anyway).
[1]: https://github.com/odoo/odoo/commit/8bd51d060a48378652ae10c57a1949c3bb7d78declosesodoo/odoo#160253
X-original-commit: d703125766d27ff33659c38fa50c2266f5f3dabb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Standard `sale` tax flows rely on `_get_tax_included_price_unit`,
whereas part of `website_sale` flows do, while another part relies
on `_fix_tax_included_price_company`, which doesn't handle some
advanced cases (fiscal position mapping of price_included taxes).
This commit drops the use of `_fix_tax_included_price_company` in
website_sale, to only use the newest API of `_get_tax_included_price_unit`,
supposed to handle more cases.
Also makes all taxes computation go through a single entry point,
`_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product),
but not in `_get_sales_prices` (/shop page).
opw-3700803
original commit : 662ea281515156a781ab68079d0123ea45ebf40f
closesodoo/odoo#160198
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
separate the true computation of the tax value from the computation of the base unit price (uom & curr conversion, ...).
That way, the risks of unwanted side-effects is reduced when the base unit price is already computed (sale, website_sale).
Also allows preprocessing the taxes mapping, which doesn't have to be done multiple times when we compute different amounts for the same product/template.
original commit: bc79770d1e00cf86a46002d633afd8b32921610b
Part-of: odoo/odoo#160198
Before commit:
Long user names in direct messaging search are not wrapped, leading to
UI display issues.
After commit:
Resolved the issue where long user names were not properly wrapped in direct
messaging search. Now, when a user name exceeds the allotted space, it is
truncated.
Task-3748791
closesodoo/odoo#160141
X-original-commit: eaf0e073ef8689629541de33e9bcf167f0e6b8e8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Install MRP
- Enable packages and multi-step routes
- Enable two steps manufacturing
- Create a component and a product
- Create a BOM for the product and add the component
- Make an MO for 100 units of the product
- Go to the picking and make a move of 20 units of the component with a
destination package
- Put in pack
- Create the backorder and validate the transfer of the remaining
components
- Go back to the MO
Issues:
Units reserved is wrong. The problem is when we are unpacking, we were
using result package inside the key. But what we want is to remove
quantity from the package the quantity originate from.
opw-3759006
closesodoo/odoo#160091
X-original-commit: 1cc04382f7ebaaa68ebe9313f1cd6b1284e13665
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Steps to reproduce:
- Install Accouting and Expenses
- Activate "Analytic Accounting" in Accounting settings
- Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans"
- Create an analytic plan with the following line:
* Domain: Expense
* Applicability: Mandatory
- Create an analytic account from the plan via "Analytic Accounts" smart button
- Create an expense without analytic
- Create a report from it
- Submit it to manager
- Try to approve it
=> An expected Validation Error will raise:
"One or more lines require a 100% analytic distribution."
- Go to "Expenses / Expense Reports" (list view)
- Select the created expense report
- Try to approve it
Issue:
The report will be approved even if there is no analytic configured on it.
Cause:
"validate_analytic" option is not passed in the context when approving the
report from list view as it is done in form view.
opw-3806787
closesodoo/odoo#160143
X-original-commit: f25a1192454b988f90d454ad9a2706de1415a2ee
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Issue:
When applicant retakes the survey, we only see the first answer of the applicant
from -Consult Interview- smartbutton from the applicant form.
Desired behavior:
We should see the latest answer
closesodoo/odoo#159833
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.
However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.
The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
the minimum delay that made Google give us good page scoring but it
may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?
Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:
- The reasonable risk we take merging this in stable (we considered
merging in a more recent version but it is needed for some specific
projects and many websites would benefit from this improvement).
- Any custom code that added behavior on buttons to be available during
lazy loading... will just wait for lazy loading with a loading effect
too now. This should be a good compromise as, again, that lazy loading
is cached and should not take too long anyway.
Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).
Overall:
- This should not impact (neither improve nor worsen) most websites that
are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
experienced from bad internet connections.
Related to task-3770362
closesodoo/odoo#159680
X-original-commit: 6aeebe47dd552144fabd42ddb190021f1499e38a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
As a preparation for the upcoming improvements in the lazyloader, this
moves the code around a bit. This will ease the review later. This
also actually removes code that was totally useless in that moved code.
Related to task-3770362
X-original-commit: aef5a7631723f3e26425427a963c1a0dd7b6d133
Part-of: odoo/odoo#159680
In the future, we might want to make most utils available in the non
lazy JS bundle part. We are also considering moving the Bootstrap lib
and some more in there. This commit is about moving the strict minimum
to be able to improve the lazy loading behavior in stable: the DOM utils
that allow to make async handlers and create button loading effects when
we click on them.
This also means that those utils were adapted to not use jQuery and
other non available utils.
Related to task-3770362
X-original-commit: 2e922105d8714704b3db94966defc922297e2ab6
Part-of: odoo/odoo#159680
The warning message when you have a half-day off confirmed while the
duration of this leave's type is daily is moved
towards the bottom of the sheet to avoid overlap between this
message and the ribbon.
And to improve the readibility of the dialog view, the scroll bar is
removed when it's not needed.
closesodoo/odoo#159454
Task: 3820211
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- Install l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Product: [any product with UNSPSC Category set]
- Confirm the invoice
- Go to the portal preview of the invoice
- Download the invoice from portal
Issue:
1) On the invoice, the CFDI document has been generated and processed
without notice.
Downloading an invoice from portal should only download the invoice.
2) There are 2 buttons on the portal: "Download" and "Print".
The "Print" allows to print the invoice, even if it has not been
generated and sent yet.
Cause:
When downloading an invoice from portal, we are going through the
"Send & Print" wizard (without displaying it) with only "Download"
option checked.
However, some localization (e.g. MX) may add specific options that
are checked by default (e.g. CFDI), which triggers the corresponding
flow.
Solution:
1) Make sure that all options of "Send & Print" wizard are deactivated,
except "Download".
Download existing invoice documents or generate a temporary Pro Forma
document when downloading invoice from portal.
2) Remove "Print" button from portal view.
opw-3821371
closesodoo/odoo#159255
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Versions
--------
- 17.0
- saas-17.1
Steps
-----
1. Have `calendar` and `hr_homeworking` installed;
2. go to Calendar;
3. try to set a location by clicking on a date column.
Issue
-----
Odoo Client Error.
Cause
-----
The `onDayRender` function calls `onDateClick` to create a record,
passing an `info` object lacking the `jsEvent` attribute.
Solution
--------
Use `this.props.createRecord` instead.
closesodoo/odoo#159060
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Install Invoicing
- Create a product with $0 cost (e.g. Product X)
- Create a vendor bill:
* Vendor: [any]
* Invoice Lines:
- Product: [none]
- Label: [anything]
- Price: [any]
- Taxes: [any]
=> The displayed "Untaxed Amount", "Taxes" and "Total" are correct
- Save the vendor bill
- Edit the invoice line of the bill
- Add Product X
=> "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected
- Change Price to 100 manually
Issue:
"Untaxed Amount", "Taxes" and "Total" stay at $0.
Upon save, "Untaxed Amount" is correctly set to $100, but "Taxes" stays at $0.
If "Units of Measure" option is activated in the Settings (available with Sales,
Purchase or Inventory app), the user will be in "uom.group_uom" and the issue will
not happen.
Cause:
When the user isn't in "uom.group_uom" group, "product_uom_id" field is
declared after "price_unit" field in the view.
Due to that, adding a product in the invoice line and changing the price to $100,
will first set "price_unit" to $100 and then set "product_uom_id" that will trigger
"_compute_price_unit" method where "price_unit" is recomputed to $0 (its cost).
Solution:
Move "product_uom_id" field before "price_unit" field in the view as it is the case
when the user is in "uom.group_uom" group.
opw-3750740
closesodoo/odoo#156447
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Have an x2many with several pages containing a field with a
readonly modifier (in the view, not in the field definition), e.g.
`readonly="1"` in the arch. Have an onchange that returns an
UPDATE command for a record that isn't in page 1 (so a record we
haven't read), with a value for that readonly field. Before this
commit, the value was sent in the UPDATE command, even though
readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly
expressions, as they can depend on other fields, which we didn't
read if the record is in a page we didn't browse to yet. However,
"static" expression like `"1"`, or `"context.get('something')"`
can totally be evaluated, and they should. This is what this commit
does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2"
- Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save
- Change quantity to 2
- Save
=> Invalid Operation
opw 3819253
closesodoo/odoo#160129
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to Reproduce
- open project
- open project settings and mark task dependencies
- open task
Issue
- The title is super far from the left.
Cause
- Every field have the same width.
Fix
- We fix the width of priority and state.
task-3761269
closesodoo/odoo#159949
X-original-commit: 96f225fee0e9b7b0213a5e63f261d3e8b8ace2bd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This traceback arises when the user changes the date with a new employee
of no contract, while creating a new Work Entry.
To reproduce this issue:
Install "hr_work_entry_contract"
1) Open payroll and create a new "Work Entry"
2) Select Work Entry Type as Unpaid and create a new employee
3) Now try to change the date
Error:- 'KeyError: False'
On the '_get_duration_batch' method, when the user creates a new employee
without a contract, the calendar remains an empty recordset.
which leads to the traceback from the below lines.
https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
After applying this commit will resolve the issue by making code more robust and
give default value.
sentry-5095168051
closesodoo/odoo#159958
X-original-commit: dff6e723580162044d25e98e0394d28e00bab520
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When a background video and an animation coming from the left or the
right are on a page at the same time, there sometimes is a horizontal
scrollbar that appears for no reason. It can happen at any screen size
but more frequently near 1000px and below. This issue seems to happen on
Chrome only.
It seems to be a race condition between the calls to the `_adjustIframe`
function in the `backgroundVideo` public widget. Indeed, this function
is called when the video is added in the DOM and each time the screen is
resized. When an animation is played, it triggers a resize of the window
when it is over, which therefore calls `_adjustIframe`.
When the animation comes from the right/left of the screen, the animated
element is translated from outside the page; the page width is therefore
bigger but its overflow is prevented. When the video is loaded, the
loading placeholder is removed. Depending on the time it takes to it to
fully load, if the animation ends before it, the iframe is adjusted
before the placeholder removal, leaving the iframe wrongly adjusted when
it is finally removed.
Note that it is hypothetical, as everything refreshes when inspecting
the DOM, making the scrollbar disappear. But this proves that no element
is really overflowing, so it seems to be a value refreshing issue.
This commit adds a call to `_adjustIframe` when the video has loaded, to
make sure its dimensions are recomputed/refreshed, preventing the
scrollbar to appear.
Steps to reproduce:
- Drop a "Text-Image" snippet.
- Set a background video to it.
- Add the "On Appearance" > "Fade" > "From Right" animation to the image
column.
- Save and then resize down the screen to 1000px or below.
- Refresh.
=> When the video is loaded, a horizontal scrollbar may appear. If not,
refresh until it does.
opw-3487117
closesodoo/odoo#159817
X-original-commit: 6035874e61d2bb1cecc339c4006cdcb6b4084b5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077
closesodoo/odoo#159264
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Remove 'videocall_location' when not sent by Google, otherwise the local
videocall will be discarded.
closesodoo/odoo#159111
X-original-commit: b56cd52bdd73c193d98fa334e80b363218cc13b9
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Activate "Reception Report" feature
Create a SO for a storable product, confirm.
Create a PO for the same product.
Confirm the PO and check the delivery, open the "Allocation" report
Assign the Product to the delivery of the SO.
Go back to the PO and cancel the order, delivery of the SO will be cancelled.
Issue: Currently the user cannot modify this behavior as the
`propagate_cancel` checkbox is unaccessible
opw-3733512
closesodoo/odoo#159940
X-original-commit: c2059c8d2f9d8f6648a577f2dd44360d699f03cf
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Follow-up of [1]. Commit [2] refactored the way we check if an option
update needs to trigger a page reload: if the option is marked as a
page option (`data-page-options="true"` on the option's main `<div>`),
then it will reload whatever the method used if there is a `reload`
parameter. Note that this `reload` parameter does not make much sense
anymore, it should be reviewed/removed in master.
Problem: [2] made a mistake in its implementation, pushing an array
instead of concatenating it. This worked by chance, as instead of asking
"does this option method requires a reload", it was asking "does this
set of option methods requires a reload"... and in that case, the code
is fallbacking on retrieving common parameters, which `reload` likely
is without custo. This could have been fixed in master only. Given the
very low risk of breaking anything critical updating this code, it was
chosen to prevent a potential crash in custo (which could occur as we
give a wrong parameter type to a main method) and allow overrides to
make `reload` a specific parameter for a specific method without the
need of `data-reload` added in the DOM.
[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-70f7fe38208aa7fe678f18e329d3c11b70065dee723921352b6005774e8bab53R456closesodoo/odoo#159927
X-original-commit: 337fbdc35ee0da2ae9d0a524a8b084c959949c78
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
if there the new_hire_field is False, an error appear. This Commit will check that the field is not false
closesodoo/odoo#159859
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Current behavior:
When you refund an order that was paid with bank and so not rounded,
the refund is rounded wich result in a difference between the original
order and the refund.
This also happens when the original order was paid with multiple
payments and one of them was not rounded and the other was. The refund
will be rounded as one single payment. This also results in a difference
between the original order and the refund.
Steps to reproduce:
- Setup a rounding method with a precision of 5.0
- Create a product with a price of 138.0
- Open the POS and add the product to the order
- Pay the order with 2 payments, one bank of 55 and one cash that will
be rounded to 80.
- Validate the order
- Go in the backend and refund the order
- The refund will be rounded to 135.0
opw-3701574
closesodoo/odoo#159395
X-original-commit: cdae1e34eddccd5ce098c79d845a8fc2658c0175
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
In case we want to search on other fields than name or default_code,
or eventually on the descriptions, we need to reverse the domain
that is built using AND and OR operators from osv.expression which
is something we would prefer to avoid anytime.
By adding a hook to add custom domains, it allows to search on whatever
extra fields we would like to search on.
closesodoo/odoo#159340
X-original-commit: 54c0b97594fb1f489163e993afd0df12cf877501
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The numpad in the PoS was sometimes handling events when it was not
supposed to, leading to unexpected behavior. This was due to the fact
we did not check if there was a buffer holder for the numpad before
triggering the event handler. The check is now done by adding a check
in the _onKeyboardInput method.
closesodoo/odoo#159951
X-original-commit: d05220d797978b5f31f574c532c6a5a117b9f5b9
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, if there was an error, the PoS stays on
the loading page which was confusing for the user.
owp-3834647
closesodoo/odoo#159710
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Make formatsSpecs heritable to allow programmers adding new inline options
closesodoo/odoo#159293
X-original-commit: 7b61bb654c587e624655904ee5d978e531c70f7b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Some tests on dynamic variants mechanism didn't pass on test
without demo data due to odoo/odoo#143543.
closesodoo/odoo#159933
X-original-commit: 12fe7400d58ef12d78a54e3b12d04c28a9564982
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Steps to Reproduce
- open project
- create a project and allow timesheet
- open timesheet and change encoding method to days/half days
- create a task in the project and set allocated time
- open portal view of the task
Issue
- There is no label for allocated time.
Cause
- Condition was added in this commit 82a85d42c86cffcd6e96b0712c8ff9a221f25d87
to show the label if encoding method is not in days.
Fix
- We apply the label for both encoding method of timesheet.
task-3761269
closesodoo/odoo#159939
X-original-commit: d7140c14d29d7e667a11dd0f92fe07117044feed
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Dheeraj Pandey (padh) <padh@odoo.com>
Before this commit:
The `<br>` tags copied from external editing software's were remained unchanged.
After this commit:
Implement breaking element at <br> during HTML paste to adress unwanted
<br> elements introduced by external editing software's or the OS.
This ensures consistent and correct behaviour for all commands.
Note that this change does not break `<li>`, `<blockquote>`, and `<pre>`
elements.
task-2936891
closesodoo/odoo#159875
X-original-commit: 94161376b296140e430d034ac79a40127a567457
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Lina (liew)