The image of the form view is set to be `image_medium`. However, the
method `image_resize_images` which is called during create or write
won't resize the image provided.
Therefore, the `image_medium` is not resized, leadnig to potential
issues if the user uploaded very large images.
We change the view to `image`, so that all images are properly resized.
opw-776943
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.
Fixed issues
* Tasks link redirecting to a Task reporting view not allowed
to project user; link is not available only for project
managers;
* Whole : trigerring the menu that should be displayed only
for project managers as it is displayed empty otherwise;
This commit is XMO approved.
In 9.0 and 10.0 if anglosaxon accounting is active, creating a vendor
bill should generate the following entry :
Debit:Stock Input
Credit:Payable
But due to this fix: e9d6dcf16f
Debit:Expense
Credit:Payable
This reverts commit e9d6dcf16f to keep the same behavior in 11.0.
opw:777837
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
Before this commit, switching chart of accounts (namely from SKR03 to SKR04 in german accounting), "old" values of the res_config_settings were kept, including default taxes.
These default taxes being inexistent in the target chart of account, the installation crashed.
After this commit, the installation succeeds as the wizard responsible for the installation is updated
OPW 777217
closes#20323
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
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.
There was a leftover explicit conversion to bytestrings during the
parsing of HTML email parts.
This translated into a parse result with `msg_dict['body']` as a `bytes`
instance in Python 3, instead of the expected text type.
Coercing the result of etree.tostring() with UTF-8 encoding to a
native string should preserve the semantics in both Python versions
without this side-effect.
+ simplify another instance of native string use
The Qweb render method returns a strign encoded in byte.
As we want to dump this into a json string in iap.charge,
we need to decode it properly in UTF-8, before the dump.
This problem appeared in Python3.
Before this commit, the input quantity would have a max qty attribute set even
if the product was not set as check inventory (inventory_availability set to
always or threshold).
- Set inventory_availability to never in a product
- Order more than 1 quantity
- The sale option popup will set input quantity to 1
Now, it will check and force max quantity only for product with threshold or
always as inventory_availability.
Before this commit:
The style of the Optional labels in portal's form was written in website_sale
module.
Problem is portal can be installed without website_sale.
- Install website module
- Go to /my/account
- Every labels are in bold as if they were mandatory
Now:
Portal's optional label's style is in portal module.
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)
The stock_move_line view for finished product on MO was
the classic one which shows lot_name and other useless stuff
This commit improve it by using the lot_id instead and a new
view that only contains relevant information for the end user.
Christophe Simonis