From issue 660592. (already fixed in v9) When products are received from a purchase line
with taxes included, the cost for the stock valuation (on the stock move) on reception
should be without these taxes included.
Checking url_list for duplicates is O(n).
Use url_set instead of url_list to improve to O(1).
Otherwise sitemap generation even for a million products will never finish.
Close#11106
If an event is private, a bunch of fields
are hidden for the users not being
the owner of the event, even for sudo.
The fields on which depends the `rrule`
computation were part of the hidden/private
fields.
In addition, the `rrule` is always computed
as sudo. See `_get_rulestring`.
Therefore, the `rrule` of recurrent private events
was not correctly computed when the owner wasn't
the administrator.
opw-670295
Iterator was consuming the first 45k records.
So don't need to specify an offset, because that will ignore the next 45k.
Eg: if step of 5, and range(1,13),
it will only use [1, 2, 3, 4, 5, 11, 12, 13]
Cherry-pick/backport of de8296c3a8
The Sales Details report wizard gives the possibility
to print the details of the POS orders between two dates.
The fields in the wizard are of type `date`,
while the orders dates are of type `datetime`.
`00:00:00` and `23:59:59` were naively added
to the `date_start` and `date_end` (respectively) to
handle the case.
But, this doesn't take care of the user time zone:
When a user choose between February 24th and February 25th,
it's within his time zone, and therefore, for the search,
where the datetime are in UTC, adding `00:00:00` isn't enough,
the dates have to be converted from the user time zone
to UTC.
opw-6698831
CSV export was added in f146e2a and since then newline were not
exported.
But new line should be allowed if the string is quoted by " characters
which is done in Odoo.
closes#11005
opw-667853
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
During the conversion of the module
`account_asset` to the new API,
in revision 6120bab,
the variables `current_currency` & `company_currency`
have been changed from identifier integers to
browse records.
The currency passed in the `create` method
values must therefore be adapted according
to this change.
This prevented the correct use
of the assets when the currency of the assets
was not the same as the currency of the company.
opw-669571
During the conversion of the module
`account_asset` to the new API,
the currency conversion in `create_move` has been inverted.
```
amount = currency_obj.compute(cr, uid, current_currency, company_currency, line.amount, context=context)
```
has been converted to
```
amount = company_currency.compute(line.amount, current_currency)
```
while it should have been converted to
```
amount = current_currency.compute(line.amount, company_currency)
```
See:
https://github.com/odoo/odoo/commit/6120bab#diff-e35933343c229da0afceb2a3b9e3639bR356
opw-669568
In the case of a `raw_data` export, a boolean which has the value
`False` will not be exported correctly.
The fix handles the `False` value as a valid value for a field.
opw-666142
The product price unit should be rounded before being used in any
operation. The PoS calls the method `read` in order to get the necessary
fields. However, the product price is a non-stored calculated float. In
old API, such a field is not rounded by the `read` method. It means that
a product price of 28.067 (for example thanks to the use of a pricelist)
will be rounded to 28.07 at the server level but not rounded in the PoS
JS layer.
To lower the impact of the fix, the rounding is done at the JS level,
and not in the `_product_price` method.
opw-669024
In the base model `account.voucher`, in the module `account_voucher`,
the field `number` is set with `copy=False`, to avoid
copy the voucher number and force to re-use the voucher sequence.
The module `account_check_writing` redefine this column,
but forgot to set the `copy=False`. Therefore, once
this module installed, the voucher number is copied
on the voucher duplication.
opw-669154
t-field handles better the currency rounding than t-esc.
When setting the currency rounding to 0.05 instead
of 0.01 (e.g. Switzerland), for 600.00:
- t-esc returns 600.0
- t-field returns 600.00, as expected.
opw-669945
DO NOT FORWARD-PORT: the functionality is not used anymore in v9
Commit aaf9badb filters the returned ids by keeping the domain in the
request. However, `this.dataset.domain` might be empty, while
`self.dataset.get_domain()` will retrieve it from the model.
Since `get_domain` is not always defined on the dataset, we keep
`this.dataset.domain` as a fallback. The fix is not great, and a better
solution should be found in master branch when the web refactoring is
done.
opw-666755
When an "hr.holliday" record is created or modified, the employee_id
linked to this record has to be added in the followers.
Inspired from ff1d384
opw:668515
It was like that for the date field, which is taken into account for the forecast quantity,
but in the view the scheduled date field is shown. We put the scheduled date equal to the date.
That way it is clear to the user when the products are foreseen to be consumed.
The revision 29bd622521
aimed to improve the performance by changing
the view index, to use a BIGINT instead of a text.
It was assumed that the index used
(`stock_move.id`) could not appear
multiple times with the JOINs and
group bys defined.
This was in fact possible, if a
stock move is associated to
several quants with different costs,
because of the JOIN on the many2many table
`stock_quant_move_rel`
linking quants to moves,
and the GROUP BY
`price_unit_on_quant`
that caused the different moves/quants association
not to be merged within one unique line
if the costs on the quants are different.
Instead of the group by, we now aggregate the quants
costs, using the weighted average, so the index
used can be unique, as expected.
From now, the inventory value per line in
this report view can therefore
be different than what can be found on the quants,
but this report view is based on the stock moves
rather than the stock quants, and this is therefore accepted.
In other words, the inventory value is computed for the stock move
rather than for the stock quant.
opw-658903
Use the same factor than the one used when
computing the products to consume at confirm.
Before, the quantity of products to consume was wrong
when using a different unit of measure in the BOM
than in the production order.
e.g.
- BoM defined as:
- 1 dozen of milk
- BoM lines: 1 cow
- Production order:
- 1 unit of milk
- BoM: The above one
At confirm, the quantity to consume is 0,083 cow (1 cow / 12, this is correct)
But, when updating the quantity to 2.0,
it updated the quantity of cow to 24.0, instead of 0,16.
opw-669447
From saas-6, setting `0` as maximum available seats
means there is an unlimited amount of tickts that
can be sold, as stated in the help message of the field:
```
Define the number of available tickets. If you have too much registrations you will
not BE able to sell tickets anymore. Set 0 to ignore this rule set as unlimited.
```
This domain is the same domain used than in
the QWeb views of `website_event_sale`.
opw-669355
The POSBox attempts to maintain whatever Wi-Fi connection it has as best
it can. When it loses it's current Wi-Fi connection it will attempt
to recreate it every 30 seconds. This works well, but a side-effect of
this is that it'll also print a 'Could not connect to LAN' ticket every
time it fails. If you where to leave the POSBox with Wi-Fi on for an
extended period of time you could return to a lot of 'Could not connect
to LAN' tickets.
This makes it so that the 'Could not connect to LAN' ticket only gets
printed once upon connection loss. Although it would be simpler to just
not print this ticket at all when losing connection, it is very useful
to know when the POSBox has lost connection. Otherwise when it loses
connection it would stop working and noone would know why.
When converting a new API call to an old API call,
the context is expected to be found within the kwargs
argument. If not, it is seen as a regular argument.
See `get_context_split` in `openerp/api.py`
As it was not the case in the overidden method
`search` in `marketing_campaign.py`, if a module
overriden the method `search` of
`ir.actions.report.xml` using the new API, the
context wasn't treated as such correctly, and it leaded
to wrong number of arguments passed.
I take the opportunity to pass all arguments
that are passed as kwargs in the base `search`
as kwargs as well, to be clean.
opw-668471
In ddac26c `crm.crm_medium_website` was replaced by
`utm.utm_medium_website`.
There was one place where it was not reverberated so the medium_id was
always unset in that instance (a crm.lead created from a website form).
opw-668853
note: no need to forward port after saas-6 (code change)
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
When generating SQL queries, `column._symbol_c` must be used as placeholder as
for the method 'set' of the column itself. Otherwise it is not possible to
define specialized columns.
When rerouting from a lang path token to the given route (eg:
/en_US/route_path to /route_path) it is better to keep request variable
clean.
opw-668563
Christophe Simonis