This reverts commit f6216a99df.
What we wanted two years ago is no longer a true today.
Only fools and dead men don't change their minds.
Task id: 31052
- If a database is migrated from an older version to saas-11.3 without
this patch, all the links /mail/view with a message_id as parameter will not work.
We must keep the backward compatibility for those links.
Before this commit, when we opened the report "Structure & Cost" of a Bill of
Materials of a product without any variant, the dropdown option selection
'report' had the current selection name cut. For instance, the selection
"BoM Structure & Cost" was displayed as "BoM Structure".
This was due to each option having a width determined by the bootstrap
classname `col-md-4`, independently on the number of options that are
available.
There are either 2 or 3 options at the top of this report, depending on whether
the product of the BoM has variants or not. When there are 3 options, there is
not problem. However, with 2 options (i.e., without variants), each option
available horizontal space is reduced, so that the 'report' option is shrunk,
which cuts the text selection as a result.
This commit fixes this problem when there are 2 options (= "no variant"),
so that the 'report' option uses more horizontal space.
Task-ID 1864490
Closes#25643
Steps to reproduce:
- activate the multi-currency option in the Accounting App
- activate the EUR currency (USD being the base currency)
- create a EUR Bank Journal with an EUR account
- on 31/07 ==> rate = 1.1
- on 08/08 ==> rate = 1.2
- create a vendor bill for Asustek on 31/07 for 39794,40 EUR
- create a vendor bill for Asustek on 31/07 for 61668,00 EUR
- create a vendor bill for Asustek on 31/07 for 33487,70 EUR
- create a supplier payment for Asustek for 134950,1 EUR
- use the payment matching smart button
- match the 3 invoices you entered;
Bug:
Odoo says there is an open balance to write-off and prevents you from reconciling
Expected Behavior: the payment total amount in EUR matches the 3 vendor bills total
amount in EUR so I would expect Odoo to consider I have a perfect match between the
payment and the vendor bills and the difference in USD (base currency) should be
automatically reflected through an exchange difference entry.
if you follow the same operation with 3 invoices of 115EUR each and a payment of 345EUR,
it will work as expected.
opw:1872978
Related to f89d4201c7
Since the invoice policy is becoming more and more simple, it is
always nice to add as much logic as possible to make things even more
simple.
For the record, 5 fields are taken into account when it comes to
invoicing policy:
service_policy
service_type
service_tracking
invoice_policy
expense_policy
They are partially linked one with the other, and not all make sense for
a given product type...
When more than one mail.channel.partner have been linked to a given user, he may
be unable to open some discussion channel because of a traceback.
The issue is that we access a channel_partner field while the recordset is not a
singleton.
We limit the search to 1 to ensure that this recordset is a singleton.
When a move line is not linked to a move, it'll be linked to the first
move of the same product at validation time. We slightly improve this
logic by linking it to the first non-completed move. To be completely
correct, we should split the move line if necessary and link it to all
needed moves, but at this time we don't want to make the logic too
complex.
Use case: create a sale order with three sale order lines of the same
products, use the detailed operations view and add three move lines of
the same products, validate the picking. Before the patch, all move
lines were linked to the first move and thus only the first sale order
line had delivered quantities.
Fixes#25488
opw-1861765
Due to the side effect on related fields that are not readonly, the value is saved
in project although not changed. Putting it readonly avoids the problem.
Fixes#26156Closes#26171
This is not expected since it leads to an inconsistent result: the user
and the access rights do not match. Better add a PIN to the manager.
This reverts commit bb8bb3cbfe.
- Create an order from the eCommerce
- Choose to pay with Stripe
- Enter the credit card info, validate
There is a short window of time (before the reload of the page) where
the user can click on 'Pay Now' again.
This is because the HTML is completely replaced, including the button.
We restore it when necessary.
opw-1866332
Create an account_move, with at least one move line having an analytic account on it
AND no label
Save and Post
Before this commit, the post failed because an analytic.line should have a label (required)
After this commit, we fill in a default name for the analytic line, composed of the data of the line,
if available, or '/'
OPW 1863418
closes#26013
Before the fix price control only worked like should on initialisation of a pos section. On switching cashier during a setting manager would lose price change rights and normal users would gain them.
Same reason as 8d948d92.
In firefox if barcode is installed, for example on a form view the keys
to navigate the possible scrolling PageUp/PageDown/Home/End don't work
at all.
This is caused by the interface barcode catching and differences of the
key event handling between firefox and other browser.
So in this change, we add these keys so they are not catched by barcode.
note: aso backport 5bc29744c so the code is the same between 10 and 11.
related to opw-706352
closes#26219
The to_refund attribute is set to copy=False.
However when splitting a move to create a backorder, a new move is created as
a copy with the remaining work to do.
This attribute is needed so that the backorder refund is consistently applied.
Essentially a backport of commit:
https://github.com/odoo/odoo/commit/c5ffca151160f9d99bec036330def108e4e91e0b
opw 1865324
Steps to reproduce the bug:
- connect as the demo user
- go to the Leaves app
- check the Leaves Summary menu: by default, it is empty
- go to Allocation Request
- create one Allocation Request for 1.00 day using the Compensatory Days type
- repeat the operation several time
Bug:
Only the first Allocation Request appears in the Leaves Summary
opw:1872365
- Set the currency to a rounding of 0.001
- Create a POS order:
Unit Price: 0.12
Quantity: 0.1
- Pay and validate
- From the backend, return the products on the create order
- Click on 'Payment'
The proposed amount is 0.01, not 0.012. It is not possible to complete
the payment process since the field is rounded at DB level to 2 digits
of precision.
We make consistent the `amount` field with the various amounts on the
`pos.order`. By using a `digits=0` and forcing the rounding, we avoid
inconsistent rounding between the order and the payment.
opw-1864344
The other overrides are working with multiple records but not event_sale.
The ensure_one() is not needed if you make a proper loop
Replaces and closes#26078
The char field has a size attribute that is displayed in the interface:
- if the field is added with code, the size is always 0 even tough the
size limit is set correctly in the database.
- if the field is a custom field, the size is correct and can be updated
With this commit, a base field show the correct size.
opw-1869282
closes#26204
Consider the following:
``` python
from datetime import datetime
from dateutil import rrule
import pytz
dt = pytz.UTC.localize(datetime(2016, 9, 2, 15, 42, 43, 205))
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA', dtstart=dt, forceset=True, tzinfos={})
test = [d for d in rset]
```
This will generate the following error:
```
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1164, in _iter
advance_iterator(ritem)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1091, in __next__
self.dt = advance_iterator(self.gen)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 649, in _iter
date = datetime.date.fromordinal(ii.yearordinal+i)
ValueError: year is out of range
```
If such an event is received from Google Calendar, the synchronization
crashes. To avoid this, we enforce a `COUNT` condition if the latter or
`UNTIL` is not explicitly specified. This gives:
``` python
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA;COUNT=100', dtstart=dt, forceset=True, tzinfos={})
```
Note that this was supposed to be fixed in
https://github.com/odoo/odoo/blob/9dcc32c3041e7ad3549a09c5ed68ee3ef22c7a26/addons/calendar/models/calendar.py#L1287
However, this was working with the old API. The new API and its computed
fields does something different:
1. create the calendar event with the provided `rrule`
2. trigger the inverse method `_inverse_rrule` => `count=100` is added
to the computed parameters
3. however, doing so won't recompute `rrule` for obvious reasons (it was
the initial value provided, so we don't recompute it)
4. the crash is met in `_get_recurrent_date_by_event` when using
`self.rrule`
The fundamental issue is that `_inverse_rrule` is not strictly the
inverse of `_compute_rrule`.
Fixes#25189
opw-1861658
In resource.calendar.attendance, we store the start and end hour of an
interval as floats.
eg: 17 hours 9 minutes is stored as 17.15
When converting this float to a datetime object, the method
float_to_time always rounds down the value, which may be wrong if, due
to float imprecisions, 0.15 hours is converted to 8.999... minutes (and
was then rounded to 8).
We do fix this behaviour by rounding to the closest integer.
Thanks to @jem-odoo for his help troubleshooting this issue.
opw-1872166
Martin Trigaux