When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
Suppose a bank statement of 11$ and a tax 10% price_included.
The result shown by the reconciliation widget is
D | C
11 |
| 10
| 1
that is correct. However, after clicking on validate, the result is
D | C
10 |
| 9.09
| 0.91
because the taxes are recomputed python-side and the values of the account.move.line are
amount = 10, tax_id = 10% incl. Then, the tax is recomputed on 10 instead of 11$.
-opw: 776644
5afb5ecd04 rewrote the tax computation
in both account and point_of_sale to fix complex tax computations but
it no longer allowed negative prices in the point of sale.
opw-778013
For instance, open a list view with enough records so that there is
a scrollbar, scroll, open a record of the bottom of the list and go
back using the breadcrumbs: the scroll position should be restored.
Before this rev., it wasn't the case: the scroll position was reset
to the top of the list (i.e. to 0).
This was due to the form renderer which manually triggered the event
DOM_updated on the main bus to ensure that textareas were correctly
autoresized. However, this wasn't done at the right place, and it
impacted the way scroll positions of views were saved/restored.
Indeed, this was only necessary when switching from readonly to edit
mode, i.e. when the form view was actually already in the DOM, but
not at each rendering as they may be performed outside the DOM (and
in this case, the DOM_updated event is triggered by the view_manager
when the view is really appended to the DOM).
Note that this whole scroll mechanism relying on the DOM_updated
event will probably change soon in master, with the refactoring of
the upper part of the webclient.
Set the round_globally method on the company.
Have an invoice with several lines and some of them having two (or more) taxes.
See the OPW 775501 for exact numbers.
It is a practical example case where
round(0.003 + 0.004) = 0.007 ~ 0.01
BUT
round(0.003) + round(0.004) ~ 0.00 + 0.00 = 0.00
Before this commit there could be a difference between amount_residual and amount_total on invoices.
This was because the two amounts are based on something different:
AMOUNT RESIDUAL
It computed in function of account_move_lines of the invoice.
For such an invoice the structure of those lines would be 1 line per tax + 1 line in the receivable account
Here the amount tax of each line is rounded before the addition.
In summary, the total amount of each tax are rounded and then added to each other
AMOUNT TOTAL
It is computed in function of the on-the-fly computation of the taxes with two cases:
- round per line: obviously each invoice_line gets its taxes rounded before addition, which isn't problematic as regards to the previous paragraph
- round globally: Here lied the problem. the rounding of the tax_line_ids was made **after** each tax amount was added to each other, which contradicts the above argument
After this commit, we round tax_line_ids before their addition, it is rather logical and matches the expectation one can have reading the tooltip of the rounding method field
>> If you select 'Round per Line' : for each tax, the tax amount will first be computed and rounded for each PO/SO/invoice line and then these rounded amounts will be summed, leading to the total amount for that tax.
If you select 'Round Globally': for *****each tax*****, the tax amount will be computed for each PO/SO/invoice line, then these amounts will be summed and eventually ***this total tax amount*** will be rounded <<
OPW 775501
After this commit, it is expected that the behavior of sale.order and purchase.order won't be the same as the invoice in the same conditions.
See PR #20349 for an explanation
issue: When reorder each line trigger an onchange on the line (if they are an
onchange linked to the field) and one onchange per line on the parent.
Adding an option doNotNotifyChange to avoid the trigger on the parent.
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
The button "Pay Now" is clickable by default. So each time a new delivery carrier is selected,
the button "Pay Now" will be cickable when the delivery carrier is updated.
Before the fix, the button "Pay now" was available even the checkbox "Policies and conditions"
were not checked because the deleted code was applied after the one checking the policies and conditions.
opw:771418
You start with an MO with a quantity of 2 with routing and we
produce just 1. At least one of the components is tracked by lots.
When we update the MO to a quantity of 1 again, the temporary
stock.move.lots continued to exist which led to processing a the consume
d move of e.g. 1 piece with 2 pieces of the quants processed when
posting inventory.
A test is added in order to avoid this case
opw-767526 and opw-772786
We try to avoid to take the inactive move lots. While they are normally
already filtered through the split, we had a case when you update the
quantity of the mo, that the split would not separate them.
With the new views, we mainly focused on making them work. But we also
need to be able to handle unusual cases, such as some RPC failing. An
example of such a problem was the following:
- a form view with a one2many with an onchange
- edit mode, change a field in the one2many, click elsewhere
- the onchange triggers, calls the server
- it may happen that the server fails with a ValidationError
- the onchange deferred fails, the line in the one2many is restored to
the value known by the list renderer, which is the previous value (but
the new value was applied to the model)
- we now have a 'corrupted' state: clicking on save will send the
invalid value, even though the UI displays the previous one.
We solve this problem in this commit by making sure that the onchange
deferred returned by the _performOnchange always succeed (or stays
pending). If the rpc fails, the deferred will succeed with an empty
dictionary. This means that the list renderer will be updated with the
value from the model.
Note that it may not be intuitive that a failure in the onchange is not
seen as an error from the perspective of the _performOnChange, but I
think that it still makes sense:
- the validation/network errors are not really a concern of the UI. The
UI just display the values entered by the user.
- if an onchange fails (for example, because of a coding error), we do
not really want to prevent the user from working.
Also, when the onchange is performed, the initial change was already
applied to the local data. Rollbacking them would be a more difficult
task.
Note that we also improve the mock server in this commit, to allow
mocking failures.
The session get_file method should return the value from the
ajax.get_file method, otherwise we lose information (this is necessary
to be able to react properly to the fact that the download was blocked)
Before this commit:
Multiple widgets for the same field on the same view (V11.0 settings) would not
retrieve the correct label but all of them.
Now:
We now retrieve the correct label instead of all of them
Before this commit, a portal user would land on /web after login in with oauth.
He would then just see the "Website" app.
He should then click on it to land on website instead of landing directly on it
after login in, which is not convenient, especially since theses users doesn't
know Odoo (in case of sale customers manually created for instance).
Now, if users has no 'base.group_user' right, it will be redirected to the
website directly instead of /web.
We had an interesting bug with the field many2many_checkbox: in some
cases, it could cause a crash, because it could not find an element in the
localdata.
To reproduce this, start with a non empty field many2many checkbox, then
uncheck them twice.
The reason is that the datapoint of type 'list' that represents the
current value is actually modified, and the replace_with operation
assumed that it could find the localID by looking into its data. I have
the feeling that a more complete fix is to make sure that the datapoint
is not modified (in its 'data' key), but is modified in its '_changes'
key. However, this would probably be a bigger change.
- Create a tax included of 21 %
- Create a product sold 7.00, set the 21 % tax
- Add the product in a SO
Amount w/o tax: 5.79
Amount tax: 1.22
Total: 7.01
We defer the base rounding to the end of the method so that the rounding
doesn't impact the tax computation of included taxes.
Complement of 6e46ba7b46
opw-777221
This use case was not correctly managed as the function evaluating if the
value has changed compares datetime and date.
This triggered an issue if the widget `date` was set on the field `date_order`
on a purchase order for example ; it was not possible to create a record as
the datapoint was set `dirty`.
This rev. ensures that a `field_changed` is not triggered if the day is the same
on a date widget.
This rev. also adds support of `datetime` fields on date widget, which appears
to be a valid use case.
Fixes https://github.com/odoo/odoo/issues/20311
Before this commit, the image was directly built without using the corresponding
template, which set some properties on the image (class, width, etc.).
- Create a product attribute, e.g. 'Recommanded Age'
- Create several values for this attribute
- Try to associate more than attribute value to the same variant =>
contraint which prevents to do it
We should allow this use case as long as the product attribute doesn't
create a variant.
opw-776344
- Activate multi-company, create companies A and B
- Set 2 companies on a user
When a message is sent (for example, thanks to the chatter), the
notification email always contains the logo of the same company,
whatever the company of the user or the company of the object.
This is a complement of commit 7a03f9ce93, applied to notifications.
Closes#20088
opw-772405
Before this commit, when on a mail.template form, click on the Preview smart button.
A wizard popped up with two buttons, as the default for form views.
First this made no sense since the wizard doesn't represent a model that can be modified
Second, the button discard was unable to close the wizard.
After this commit, only a discard button is present which does its job.
Before this commit, Sale order and invoice notification email templates broke when doing any action on them (duplicating, open preview etc...)
This is because the model is saved during those operation, and the css style gets converted to inline style.
The table tag present in those templates, was wrongly associated with the bootstrap rule for tables, collapsing their border, hence the break of the templates.
After this commit, we force the borders not to collapse, and the templates don't break
OPW 774323
This is a hotfix/hack for a conflict between website_sale and
website_quote, on the field website_description.
The conflict happens when both modules are installed.
Fixes#20118
Completes rev 333a236
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
When double-clicking on a link/button, the link dialog is opened. The
problem was that the "btn" class is sometimes used on non-link elements.
While this should not be, the editor can easily be adapted to this.
When a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
Christophe Simonis