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
Because we converted buttons into tables so inline buttons was
breaking into multiple lines so we need to add display inline and vertical align
properties in tables.
We allowed display property from mail sensitizer whitelist.
Because in this commit https://github.com/odoo/odoo/commit/cf15030ed09f7479f5b2701ba101a5bed71f7409
we use display property for align items
commit 47654e98e0 modified a defaultdict by an OrderedDict.
When multiple orderpoints use the same location the key is the same and
location_data dict entry is removed for the new one.
This commit only call makedefault when there is not current entry for
the dict.
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.
opw 1865324
Due to this commit: 6e93fe0de1
the stock user has the all rights on model 'product.pricelist'
As the repair order model has the field pricelist_id on it,
the stock user must have the right to read it.
opw:1865814
The `active_id` when clicking on "Receive Products" on a purchase order
is the one of the purchase order.
But the action used has a context with:
```
{
'search_default_picking_type_id': [active_id],
'default_picking_type_id': active_id,
'contact_display': 'partner_address',
}
```
So the active_id should be a stock.picking.type and not a purchase
order, thus:
- we could get an error at some instance (eg. a refresh) when loading
the facet of the stock.picking.type with the ID of a purchase order
- we could erroneously show a facet for a stock.picking.type with the ID
being the same as the purchase order
So this commit uses the same action without the offending `active_id` in
context.
opw-1870687
closes#26160
Purchase creates an activity when some stock move is deleted.
Howver when two moves are merged "behind the scenes", some moves may be deleted.
As a result it creates an activity "warning: some move has been deleted" for no
good reason.
We add a hook to clean moves before the merge.
opw 1826791
On the pipeline action change the sequence of the view_ids to
change the order of the view_mode string
Put tree first instead of kanban for example
Before this commit, clicking on CRM menu app still displays the kanban
This was because the action window is wrapped around a server action that modifies it
After this commit, we recompute the view list to match what is on the original action
OPW 1863425
closes#26159
From a SO (for example), create an activity with type meeting
Create the calendar event
Access it as a guest with the route with the token
Before this commit, there was an error 500 because the description
of the event actually contained "\n" and was not parseable
After this commit, we strip the string at event creation, and no error occur
OPW 1867283
closes#25795
Lucas Perais (lpe)