In case an exception (programming, out of memory or any other unexpected
failure), the cron_thread would crash and not recover until server restart.
Issue #15666 was an example of failure.
Courtesy of Nils Hamerlinck
If postgresql database is temporarly down, the cron thread may fail.
The cursor creation fails when trying to connect to the server which leads to
the cron thread to die (uncatched exception) and will not restart when postgres
is back.
Fixes#15666
Change the condition from
[...] and debit != and credit != 0
to
[...] and (debit != or credit != 0)
as at least one of debit or credit may have an unaffected value
Without this patch a past unpaid entry will not be included in the report.
Closes#15550
The separator in the debit/credit columns of the report must contains coma
instead of dots for decimal separator (fr).
All the other columns (cf SQL query) contains coma but not this one.
Inverse the currency sign of the credit column. Otherwise the credit is negative
and sum of the balance is wrong (sum credit != debit)
Closes#15550
When computing the discount in product_id_change, before the fix
discount was equal to (new_list_price - line.price_unit) / new_list_price * 100
But line.price_unit was already rounded so the discount computed was not the
discount set in the pricelist due to rounding error.
opw:709704
Template "sitemap_index_xml":
<loc><t t-esc="url_root"/>sitemap-<t t-esc="page"/>.xml</loc>
should be:
<loc><t t-esc="url_root"/>sitemap-<t t-esc="website_id"/>-<t t-esc="page"/>.xml</loc>
The fix in python is not elegant but allow to fix without -u of website.
In mass mailing there is several possibilities of states when rendering
the widget with a possibly new value:
1. we are not in edition
a. we are in same language than user language => the editor content
can be updated
b. we are in a different language => the content cannot be updated
2. we are in edition
a. we are editing translation : the editor content cannot be updated
b. we are not editing translation (editor language == en_US)
i. we are requesting editor update (by having magic value
`on_change_model_and_list`) => the editor can be updated
ii. we are in same language than user language => the editor content
can be updated
iii. we are in a different language => the editor content cannot be
updated
In summary:
- if language is the same than the user, we can update the value
- if value is magic `on_change_model_and_list` and we are not translating,
we can update the editor
Before this commit, this worked as expected but for 2.a.ii. which if the
user language was not en_US would for example prevent editor updating.
closes#15583closes#15414
opw-708032
inspired by a27e24c6d1
note: the fix is a fix for 9.0 and saas-11 only.
When uninstalling the module sale_margin, the view 'sale_report' was deleted
because this view was overwritten in this module.
But the module sale still uses the 'sale_report' view so it raised an error
each time this view was required.
opw:709328
Due to these commits, it was impossible to make an uninstall_hook
just after an uninstallation.
In some case, it 's needed to make an uninstall_hook just after the uninstallation.
Look this commit for example: e03c919e9955c5d3f678c0580744d9ef8c483c74
- Create a partner with an invoicing and a delivery address.
- Connect to the website as this partner, create an order
- In the "Shipping & Billing" page, the delivery address is selected
automatically. Change and set to "Ship to the same address", and
confirm.
The "Ship To" address is still the delivery address, while it should be
the same than the "Bill To" address.
This reintroduces the v8 behavior:
`order_info.update(partner_shipping_id=checkout.get('shipping_id') or partner_id)`
https://github.com/odoo/odoo/blob/8.0/addons/website_sale/controllers/main.py#L623
Create the following
- Create a partner of type "Company" (Address 1)
- Add an "Invoicing" address to this partner (Address 2)
- Add a "Contact" address to this partner
- Authorize this contact as a portal user
Connect as the portal user created:
- Place an order from website, add a product to cart
- In "Shipping & Billing", confirm the order. The proposed billing
address is "Address 1". Do not change the shipping address ("Ship to
the same address"), and confirm.
The "Bill To" as well as the "Ship To" address are set to "Address 1".
This is a regression from v8. In v8, "Bill To" is set to "Address 2",
while "Ship To" is set to "Address 1".
opw-707283
The variable `st_line` was used outside of its scope,
in the line
`move.line_ids.filtered(lambda x:x.statement_id == st_line.statement_id).write({'statement_id': False})`
It leaded to issues when calling the method
on multiple `account.bank.statement.line`: Only
the items associated to the last line were unlinked
opw-709196
Links containing HTML escaped characters,
such as the ampersand
`&` escaped `&`
were not shortened correctly:
Their redirecting URL contained the escaped value
(e.g. `&`) instead of the actual character,
leading to the wrong redirected URL.
e.g. creating a mass-mailing with a link
contains as query string
?test1=1&test2=2 were shortened
with as redirect link
?test1=1&test2=2
opw-708272
Without passing `active_test=False` in the context,
a one2many fields exludes the record with
`active` set to False.
For an archived product template, this means
`product_variant_ids` returned an empty array
opw-708828
If amount = 1 and the category amount = -1, the sum is 0 and the returned
value was amount instead of zero (`0 or amount`)
Avoid this evalution error by splitting on multiple lines
Closes#15470
When clicking on the smart button "Claims" of a contact, it shows
a tree view with all the claims of this contact and his children(because
the domain on the filter is [('partner_id','child_of',self)]).
So the function _claim_count has to return the sum of the # claims
of a contact and the # claims of the children of this contact.
opw:708698
The previous code (`parent.field_widget.string`) was returning the untranslated
action name (and why use parent anyway?)
Use the action name instead.
Closes#15207
opw-705938
For a pricelist based on another pricelist,
the price of the product is the price in this other
pricelist.
To get the price of a product in a specific pricelist,
the field `price` must be used, along with the right `pricelist`
passed in the context when browsing the product.
Without this, the sale price is considered the sale price
indicated on the form, in the product company currency,
while the pricelist on which is based the currenct pricelist
could give a specific other price, in another specific currency.
e.g.:
Watch, Sale price 690CHF
Public USD Pricelist, setting the sale price of the watch to 790 USD
Reseller USD Pricelist, discounting 60% based on the public pricelist price, discount shown.
Before this revision, the sale price of the watch was marked
690 USD, with a sown discount of 54,xx %
With this revision, the sale price of the watch is marked at
790USD, with a shown discount of 60%, as expected.
opw-708301
Backport of 1f6ec2b8d6
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
opw:708099
2 sequences are created when a pos.config is created:
- one for pos.order, stored in sequence_id field
- one for pos.order.line, link is lost, like dust in the wind ♫
When creating a pos.order.line from a new order, the default value was using the
first sequence if found using the code 'pos.order.line' (returning the latest
created).
The name of the line was always using the same sequence, whatever the config
used.
In master, the field has been stored at 645df676 but in stable version, the
following hack is done:
As the sequences are created in the same transaction as the pos.config, the
create_date will be the same to the microsecond.
The name of the config can not be used as too easily changed (e.g. duplicate)
and may not be unique.
Done in SQL to avoid ORM cleaning of microseconds, not working with a search.
opw-703092
With a sale order with:
- a stockable product
- the `Create Invoice` policy set to `Before Delivery`
After the quotation validation and the invoice validation,
if the user:
- cancelled the invoice,
- then validated it again,
- then hit `ignore exception` on the sale order
- then registered the payment on the invoice
The picking of the sale order was not created automatically,
and the sale order was therefore stuck.
Actually, it was just a write trigger that was missing:
The condition for the sale order workflow to go to the next state
is that the `invoiced` boolean is set to True.
It was, when the invoice of the sale order was paid
(after having registered the payment), but since
this is a computed field, not stored, no write operation
was actually performed on the sale order, and the workflow
wasn't "notified" that a change occured for the `invoiced` boolean.
A simple write on the sale order (e.g. in its notes) would
have unblock the situation, though.
This trigger ensures the worfklow to be notified when
the invoice of the sale order is paid, and therefore
when the `invoiced` boolean is set to `True`.
opw-706591
This is a complement of previous commit.
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company banking
information displayed in the report footer.
opw-708581
As a portal user, access one of your invoices from the frontend
(download the PDF). The generation of the report crashes because of an
access error. The error arises when trying to access the company contact
information (address, phone, fax...) displayed in the report footer.
This is due an API migration error (7eab8e26d3). Before the migration,
the partner was browsed in `_get_address_data` as:
`address = part_obj.read(cr, openerp.SUPERUSER_ID, ...`
After the migration, this is not browsed as superuser anymore.
Therefore, users with limited access rights won't be able to read it
anymore.
opw-708581
In the kanban view, if we try to group by a field that is not
defined in the arch, some features (like 'Add a new Column')
are not available because the case is not correctly handled.
To fix it, a RPC is done to load all fields in this case.
Christophe Simonis