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
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
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
The kanban CSS applies both a 90 degree rotation and a top-bottom rtl
writing mode to folded kanban group titles. This was initially fine
because browsers didn't support the (SVG) "tb-rl" value for writing-mode
and the property was thus ignored. Firefox 43 (December 2015) and Chrome
48 (January 2016) added support for this value, and thus now end up with
a 180 degree rotation on the title.
Issue #7955 fixed it in 8.0 due to MSIE impact, this is essentially a
backport to 7.0.
close#10687
The LDAP method filter_format(filter_template,assertion_values) requires
that the length of assertion_values matches the count of %s in
filter_template. If not, a TypeError exception is thrown.
This fix catches the exception and displays an understandable error
message instead.
opw-608126
opw-657370
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
Backport of de3b64018a
This revision back-ports revisions
983d5eb9fa
&
ccbb8e09a6
regarding this signature regex.
Besides, it adds the fact the dashes have to
be at the beginning of the line
to make them detected as a signature.
opw-655834
The decimal precisions for the quantities, cost/supplier price
per unit of measure were not respected. It was always
set to 2 digits, whatever the configuration in the database
decimal precisions.
opw-653143
The current code when applying negative operator on an expression used
recursion which in extreme case is not best friend with python.
e.g: on instance with a lot of wharehouse, some simple action could lead
to a domain with lot of elements which could easiliy go over the python
maximum recursion limit.
This commit fixes this by replacing recursion with iteration.
We have a stack of negation flags and loop on each token of the domain
as follow :
- when we iterate on a leaf, it consumes the top negation flag,
- after a '!' operator, the top token negation is inversed,
- after an '&' or '|' operator, the top negation flag is duplicated on
the top of the stack.
closes#9433
opw-653802
For these function fields, bypassing the ORM, using a SQL query,
improves the execution time by 100 for a set of 80 timesheets
in a database with
- 250K `hr.analytic.timesheet`
&
- 250K `hr.attendance`.
These function fields depends on a one2many field which use
the SQL view `hr_timesheet_sheet_sheet_day`.
When performing `sheet.period_ids`, two SQL requests are performed,
- the first just to know the ids in the sql view matching this sheet
- the second to read the fields `total_attendance` & `total_timesheet`
and the request is performed on the entire set of lines of this view
(~250K lines in the observed use case)
while, when replaced by this SQL request, only one request is performed,
on a restricted set of lines, speeding up significantly the computation
of these computed fields for smaller sets of sheets.
opw-653447
In some complex use case of a workflow instance with several workitems,
a given workitem processing could itself somewhat recursively process
one of the following workitems.
This situation was currently not taken into account, so in that given
case, the already processed workitems would be processed again.
opw-647580
Users not belonging to the project user group can not access the model
project.task.history.cumulative
Hide the dashboard for them
Fixes#8606Closes#8607
When duplicating a user, an email was sent to a user at the email of the
previous user (as the create is called before changing the email).
Closes#8754
Commit e0c1f54fd7 was supposed to prevent the message fetch in the
inbox view. However, self.is_log refers to the type of message: internal
note or message. This properly checks if the page displayed is the inbox
view before fetching the messages.
Related to #7596
opw-650208
`qty` is the quantity in the product default uom.
`move.price_unit` is the price unit of the product
in this move, for the specific uom of this move.
The quantity to use is therefore the quantity
in the move uom, `move.product_qty`
Closes#4555
In case of different directory for stroing po and pot files than 'i18n'
(e.g. 'i18n_extra'), a po could be linked to a wrong pot file.
Use the same folder as the po file to look for pot.
Closes#4323
This is possible that changes happen
during the loop in the multiple pickings:
an update in a picking could update another
picking. The browse must therefore be done
inside the loop to update the pickings with
the latest changes.
Fixes#4201
In the module `purchase_double_validation`,
you can change the limit to require a second approval
in the purchase settings.
If the module was updated, the limit was re-set to
its default value.
Closes#4183
If an error happens in an overload of setUp, the already-open cursor
is likely not to get properly released before the next test,
deadlocking the db, because tearDown only runs if setUp has
succesfully completed.
Cleanups were added specifically to run every time, after tearDown has
(potentially) been executed.
closes#8327
Note: cleanups run in LIFO order (as they should).
The function interval_get_multi must take into account the minutes in
hour_from and hour_to. hour_to and hour_from are float fields in the model
"resource.calendar.attendance" and the decimal part of these two fields is
for the minutes.
opw:648349
Correctly use the email_from tag from template.
This partially reverts commit 0f82346167.
"[FIX] email_template: keep email_from and outgoing server"
Remove the email_from part that was incorrect, keeping the one on mail_server_id
Instead of assigning an non-evaulated email_from in the context, specify the
email_from in the onchange method. This way the created email has an evaulated
from value. This was an issue for templates using email_from like
"${(object.user_id.email or '')|safe}"
In the _notify method method, the email_from is partially respected as it will
be used a fallback only. However changing that would introduce a modification of
behaviour not suitable for 7.0 branch.
Fixes#8409
To compute the intervals of working time, the function interval_get_multi
used 'hour_to' and 'hour_from' from "resource.calendar.attendance" model. 'hour_to'
and 'hour_from' are not in UTC timezone. All the dates in odoo are compared in UTC.
Then 'hour_to' and 'hour_from' must be converted.
To take into account the minutes in this computation, the minutes from the start date
are added in the variable todo (number of working hours).
opw:648349