Some users are confused by the generic error message asking to confirm a sale
order that is in locked or cancelled state.
We add specific error messages in these two cases.
opw 1871019
compute method called 2 times in t-esc case when monetary field has "from_currency ::
1) value_to_html: compute method call when qweb monetary widget is return value as a html.
see https://github.com/odoo/odoo/blob/10.0/odoo/addons/base/ir/ir_qweb/fields.py#L325
2) compute_currency : compute_currency method is pass from controller into render engine and it is call the compute method.
So, we removed compute_currency method from qweb template in the t-esc with monetary widget.
FIXUP da2140b
The above commmit was half-right in the business logic, but overlooked that if a user is not
in the company of the project, it will crash.
This use case worked before that commit
While agreeing that a little more clear access right is needed
like for example be able to get the project_time_mode_id on the companies
that are in user.company_ids,
the aim of this present commit is to avoid regression
OPW 1878204
closes#26539
Steps to reproduce:
Create a customer invoice with 2 product A and refund 1 product A.
Display account.invoice.report for this custumer.
Bug:
The quantity should be 1 not 3.
Fine tuning of this commit: e890682656
opw:1868116
When creating a new wizard, the related field user_id = employee_id.user_id
forces a write on employee model
Make sure we actually have the same value (to avoid using the wizard to modify
employees) and use sudo to grant the badge.
In master, the field should not be stored
backport 1dbc655676
Company in USD
Invoice in EUR with rate A
Register a payment in EUR with rate B
Unreconcile them.
Before this commit, there was an error because we tried to reconcile the exchange items
with its reversal while the formers were already reconciled with the invoice
After this commit, there is no error
OPW 1864091
closes#26583
In the reconciliation widget, search for an amount like 5361.61
Before this commit, if the targetted line that you want to see was represented as 5361.61000001
you did not see it in the results of the search
After this commit, you do!
OPW 1872543
closes#26523
- In some cases (merge of partners, etc ...) there might be mail.channel
that have two mail.channel.partner with the same res.partner.
When you try to open a discuss window with a partner for which you
have no existing mail.channel.
The channel opened is the one where your partner is duplicated.
This is due to the fact that the SQL request to find the mail.channel
doesn't take in account that a mail.channel may have twice the same
partner.
To fix this issue, we try to exactly match the partners we search.
Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
When creating and editing a new calendar.event record from the calendar
view, the start_datetime field does not prefill from the day that was
selected on the calendar.
Introduced in e08f999468
opw-1875276
PO that can be linked to an invoice are filtered via a domain
restricting the partner. However when no partner is selected yet, the
domain was `('partner_id', 'child_of', False)` which, beside being horribly slow, was also useless as it returns ALL partners.
Only generate a meaningfull domain.
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.3.2 and Jinja2 before 2.8.1 suffer
from a few issues that could lead to crashes of Odoo workers.
The bugfixes have been backported in the DEB packages for Pillow,
so users of Debian/Ubuntu LTS versions won't be affected if they are
keeping their systems updated.
However it's worth an exception to our rule for pip users.
len-odoo