Make sure building reports using local resources are disabled.
This avoids get different report result based on the system if the
given resources are or not present (e.g. custom style)
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
Currently, when a digital product is purchased, the list of attachments
is incorrectly computed. Product template's portal files are retrieved
correctly, but all product variant's attachments are taken into account,
not only its portal files.
This commit causes the portal attachments to be computed correctly,
taking into account only portal files from both the product template and
product variant.
Closes#25609
third positional argument is places not msg (which expects a number not a str)
https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertAlmostEqual
fixes errors like these:
if round(abs(second-first), places) == 0:
TypeError: 'str' object cannot be interpreted as an integer
and gives the intended message when assertion is errornous
In Python 3.5, items() on a dictionary return keys in a randomized order.
location_data can thus be processed in different orders, leading to
different quantities in the MO's created by the procurement scheduler.
This fix makes the output of the scheduler deterministic.
(thanks to @odony for his help in troubleshooting this issue)
opw-1865711
Steps to reproduce:
- activate the EUR currency
- set a currency rate 1 USD = 1.2 EUR
- create a Bank journal in EUR with a EUR account
- create a Vendor Bill in EUR for 1200 EUR in total
- go in the Vendor Bill list view (Accounting > Purchase > Vendor Bills)
- select the created Vendor Bill
- click "Register Payment" in the action menu
- select the EUR Bank journal you created
Bug:
The payment amount is 1000 EUR instead of 1200 EUR.
opw:1870351
Since 6a3324a7 and 0c489cf1fa, a translation can not contain a \n
Previous text was not correct rst anyway.
Reexport base translations to include all missing modules
This reverts commit 2054b59285 which
already has been fixed multiple times [0].
However this change does not correctly handle successive onchange calls on
ony2many fields which alter existing rows.
i.e., in saas~11.4, an onchange has been added on move lines [1] in
order to create and/or update lines containing taxes amounts.
However, with diff-only onchange, a second call to onchange will discard
changes made by a first one as nothing change between the 2 calls.
Scenario: On an existing account.move, add a new credit line with a tax set.
The first onchange will update the tax line with new amount. Add a
second line (with debit amount balanced). The onchange will not change
the tax line, resulting as it value being reset to initial value. As a
result, the move is not balanced and cannot be saved.
[0] cd2ccc4110, 5e58ac16c3, 07023137cd
[1] d49ab568a2
This field is used by the multiple payment wizard; the payments it generates are always individual and should never have multi=True. Before this commit, they did, because of the values given in context when calling the payment wizard.
The 'drag and drop' function defined in test_utils should be aware of four
different cases, moving up or down, above or below another row.
We need an offset of one pixel for the function to work when moving down
(this is a case of broken symmetry because of <=)
Related to opw 1867049 regarding sequences of resequence moves.
Steps to reproduce the bug:
- Go on a picking with an operation type of type "vendor" (e.g. a receipt) :
the field source location appears while it should be the destination location.
- Go on a picking with an operation type of type "customer " (e.g. a delivery) :
the field destination location appears while it should be the source location.
opw:1869145
3869cdf7d8 merged a fix which used a
P3-style super call, which is not compatible with Python 2.
While 11.0 is not really exactly officially supported on Python 2,
we originally decided not to break compatibility unless there were
very good reasons to do so.
Steps to reproduce:
1. Activate multi-currency and associate a price list "Other list" with secondary currency as an alternative for "Public Price List".
2. Enable the price list to be selectable on the website.
3. Enable wishlist functionality on Website module
4. Navigate to website without logging in
5. Add a product to the wishlist (with the default price list)
6. Switch price lists.
Bug:
The wrong currency was displayed in the wishlist for the new price.
PS: In function "compute_new_price", price_new = website_price
opw:1867314
Have a statement line with multiple pages of propositions
Go to the last page
Add everything
Before this commit, after clicking on the last item of the list,
a write-off creation was displayed, without any means to come back to the other
propositions
After this commit, we display the page before
In manual reconciliation, have an accound with no direct proposal.
An empty line should be present
Click on it
Before this commit, there was a traceback
After this commit, a write-off creation appears
In manual reconciliation (but probably automatic too)
Have 3 lines for one account
2 of them are balanced
the third is of an amount X
Add the three lines to the reconciliation
A write-off proposal of -X should appear
Now, remove the third line by clicking on it
Click on Reconcile
Before this commit, the values sent to the server were wrong, as the write-off
was still included
After this commit, we make sure we don't send lines that are not displayed
Create an account.move, create a line, then add an item to start to add a second aml
The current balance of the move is put in debit (or credit) to help automatically making the second line
Save the move.
Edit the move
Delete a line
Add a new line
Before this commit, the balance was not correctly computed because the default_get did not compute
the balance on deleted lines
The move ended up with wrong unbalanced new lines
After this commit, the balance is computed with deleted lines taken into account
Before this commit, negative values in a float field interpreted as time
(i.e. unit_amount on analytic lines) were wrongly formatted
After this commit, not only we correct the hr_timesheet qweb templates
but we also correct the qweb widget to handle the case
OPW 1869986
closes#26024
Have the Admin in company A
Create a pos.config for company B
Have its default pricelist to be one of company A's
Save
Log in with user B, in company B
Try to make a new pos session
When everything is loaded, the screen stays black, leaving the pos unusable
After this commit, we constrain the pricelists to either be of company B's
or to not have a company set on them
The black screen doesn't happen
OPW 1861757
closes#25996
Have an invoice with analytic tags
Create a credit note
Before this commit, the tags on the invoice lines
are not transmitted to the credit note's lines
After this commit, they are
OPW 1866432
closes#26010
Simon Lejeune