On a PO linked to a purchase tender, changing the quantity on a PO line
will trigger a recompute of the unit price. However, this recomputation
will take into account the unit price of the supplier pricelist, not the
unit price on the purchase tender.
opw-690483
When the purchase tender of a PO refers to a blanket order, the price
unit used to create/update the order lines doesn't take into account the
potential difference of UoM.
When returning an item by entering an orderline with a negative quantity
you got a warning message asking you to confirm a large payment
amount. Introduced by 5a3d9ce9ce.
Closes#13777
If you validate an order it will be sent to the backend. If you then
close the POS frontend somehow before clicking 'Next order' this order
will be reloaded from localStorage when reopening it. This is
problematic because it allows the user to then modify this order and
validate it again. Everything will appear fine but in the backend this
new, modified order will be ignored as it has the same pos_reference as
the one that was sent initially.
The deeper underlying issue is that there exists a brief timeframe where
the same order can exist twice in the db: both as 'order' and
'unpaid_order'. To ensure this does not happen this fix removes the
order from the unpaid orders after it is saved as a validated order.
Fixes#13538
This way you don't have to wait the 5 seconds, or click the "ok" button
to return the the kiosk mode to be able to scan the next badge.
Note: listener is disabled if a warning message is displayed.
+ small code/comments cleanup
Before the fix, the tax base amount is computed only for a complete
invoice line. However, depending on the tax sequence and their inclusion
in the base amount, the tax base amount might be different for the
various taxes of an invoice line.
We keep track of the base amount for every single tax, and refactor the
`_compute_base_amount` to take these values into account.
opw-691177
Closes#13819
Recent refactoring of the parallax changed the snippet option JS and
attached a callback on a editor element but forgot to detach it if
the parallax snippet is removed. This added a bug which broke the
editor every time a parallax snippet was removed.
When registering a payment on an account invoice with an automated
action which adds a follower "On Creation & Update", the function
recompute was triggered(due to the field residual_company_signed)
and the same followers was added two times for the invoice.
The fix avoid to unlink and create the same followers several
times(because it was the case with the function "_add_follower_command")
opw:690939
Before this commit, the one2many widget was not displayed if no data.
That make some form (notebook) empty while the user don't click en edit to see the widget appear.
Eg: stock picking 'Initial Demand' tab
Courtesy of @ged-odoo
Before this commit, create a blog post since the backend raise
an error because the post_date is False.
It should never arrive, since it is a compute field that is the
publish date or fallback on the create_date.
But because set post_date, change the published_date, the depend from
publish date cannot be triggered again since it change the post_date.
So _set_post_date don't trigger _compute_post_date. And call it manually
will make 'max recursion depth python'.
The 'hack' to update publish date, without retrigger the _compute_post_date
and set post_date manually, is to use the _write method that don't trigger
all depends fields.
Courtesy of @rco-odoo
This commit closes#13829
The form widgets did not apply the 'style' attribute to the result of
the rendering. Because of that, many small adjustment were no longer
possible. This commit makes sure that it is indeed done.
The following configuration leads to different results:
- Deferred revenue: 12 entries, 1/month, prorata temporis, 1000€,
date 15th of October
- Asset: 12 entries, 1/month, prorata temporis, 1000€, linear, date
15th of October
Deferred revenues and assets should give identical results.
opw-690034
This is required in order to have those bank journal items appearing afterwards in the bank statement reconciliation widget (blue line) for reconciliation.
This revert the fix made on 7bdd4de and replace it with a proper one that do create an account entry from stock_input to stock_output on a dropship move. That way, we avoid the manual change of account on supplier invoice. See the whole discussion on odoo#12687
Before this commit, the inventory by lot/pack/serial/... was only visible
if you switch quickly between res_config and adjustment inventory... once
the vaccumn clean the osv memory, the options was ignored.
Same issue with the _get_string_qty_information function.
Force the name to the default value '/', to avoid an eventual 'default_name' in the context to set it to '' which cause no number to be given to the account.move when posted (which is totally wrong).
Setting the value of a one2many field (`rec.line_ids = ...`) converts the new
recordset to a list of commands, and passes it to `write`.
Currently the list of commands is like: `[(5,), (0, 0, vals), (1, id, vals), (4, id), ...]`.
Notice that the command `(5,)` is inappropriate here: it deletes all the
existing lines of the record. Reintroducing the same lines with `(4, id)`
commands crashes, because the corresponding `id` is no longer in database.
The fix serializes the recordset as a list of commands like
`[(6, 0, ids), (0, 0, vals), (1, id, vals), ...]`.
Only the lines that are not kept will be deleted in this case.
- Create a deferred revenue type > 3 depreciations, one every month
- Create a deferred revenue with this revenue type
- Odoo generates a depreciation board with 3 entries > one should be
done in October, one November, one in december
- Generate your deferred revenues entries UNTIL 31st of december
Odoo create the 3 depreciations but they all have the 31ST of december
as accounting date > the dates of these accounting entries should be the
date defined on the depreciation board.
opw-690970
When deinstalling a module, the server deletes its records when possible.
There is an issue when deleting a record is not possible: deleting its xmlid
will introduce duplicate records when the module is installed again. Therefore
one should not delete its xmlid.
Commit e11f23b701 split the website
customize_template_get into web_editor and website ones. This split
was not perfect and commit 20861b482a
tried to make it work... but did not made it totally and added an
indirect dependency to website module in web_editor...
As the final result is wrong and inconsistent and that the previous
9.0 implementation was already ugly, this was not possible to make
a consistent full-stable fix.
This commit tries to make a fix as stable as possible (the main method
name did not change, the arguments did not change, their purpose is
the same, ...) which makes the code work and be less ugly. However,
the function returns are now slightly different (and JS depends on it).
It returns only valid view information (not header stuff which is not
related to anything and the inherit_id value is now a combination of
the inherit view id and name). Also, a new private method has been
created.
Also, the method contained code which was deprecated since saas-6 but
was never removed (and never broke anything "by chance").
In master these methods will be refactored to make more sense.
After this commit,
- chinese custom date are supported
- Possibility to specify the custom datetime format and not only dateformat.
Withtout it, impossible to import a date column and datetime column at
sametime with custom format.
- Add test to check import date with custom format
- Fix translation where error messages was in the source.
This commit fixes#13783 and closes#13803
Courtesy of @odony for the review ;)
Old versions of Odoo did not correctly manage message_id of mail messages.
Thread formation was based on information present in References and/or in
In-Reply-To of replies to emails. Message-Ids could contain model and
res_id of a record. Thread formation was done using this information.
However commit 8253453d64 fixed that behavior
by correctly checking in existing mail_messages to find matching message-ids.
Message found was set as parent and thread formation was correctly done without
collision or possible issues with badly formatted Message-Ids.
A compatibility mode was introduced at the same time to handle previous versions
of Odoo. This commit removes this compatibility as it was done long enough
to ensure compatibility is not required anymore.
[TESTS] mail: tests updated, compat mode should raise in all cases now
Nicolas Martinelli