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
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
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.
Update MO qty compute the quantity already processed
but it includes the by_product moves.
This commit add a filter in order to only consider the
move with the final product.
Since mrp/stock refactoring by-product tracked
was not handled by the code. The best way to
handle it would be to add a section in the
product produce wizard. However we can't modify
the model in 11.0.
Thus this commit generate a move line for each by-product
but without lot/SN.
! This commit should be revert in future version once
the by product pass through the produce wizard
Before this commit, when you were entering search mode en settings view,
enterprise label would lose its style. (even when leaving search mode by
removing search text)
Now, the style remains.
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
Andrew Latham