This is related to rev. ab9f02cdee
The above rev. take care to exclude payments that are not yet due;
meaning the ones due in the future, by checking the maturity
date.
Problem: Payments (e.g. move lines from bank statements)
do not have a maturity date. Only move lines that actually
have a maturity date, in the future, must be excluded,
not the one that do not have a maturity date.
opw-633930
The domain on account.account was preprocessed in search method but it had no
effect on read_group. This lead to inconsistency or errors when using 'goup by'
filter.
Move domain processing in '_where_calc' method instead as this is used by both
'search' and 'read_group'.
This reverts commit 24526b18a7.
The journal_id field is not present on account.account but is processed in
search method.
Next commit will improve the processing to also accept journal_id in read_group.
The Tax Report printed with details should not include draft accounting entries.
Technicaly, the account move lines include in a draft account move do not have to be
printed
opw:633642
The `tax_amount` of move lines is by default set to `0.0`.
Nevertheless, this default value is set by Odoo,
not by postgresql.
This is therefore likely that the `tax_amount` is set as
null instead of 0.0, in database.
Therefore, when getting this value directly with a SQL
request, this is possible that `null` will be returned.
Therefore, in this specific case, `res.get(record.id, 0.0`
could return `False`, if the sum of `tax_amount` is `null`,
and try to multiply a boolean with an integer is not possible:
`_rec_get(rec) * rec.sign`
opw-633903
The ir.ui.view.graph_get() method depended on the natural
semi-random order of Python dict keys in the _columns dict.
When the number and/or names of the _columns happened to
yield the o2m field of the "incoming transitions" *before*
the "outgoing transitions" of the "Node model"
(e.g. workflow activity), it would swap the incoming and
outgoing transitions fields around, causing a crash later
in the `tools.graph.process` method (currently an infinite
loop in the `tree_order()` method of tools.graph.py).
Closes#3614
Fixes https://bugs.launchpad.net/openobject-server/+bug/1316948
opw-633765
Make sure the purchase order is marked as invoiced only when fully invoiced.
If the invoices are generated on delivery order (invoice_method picking), make
sure all products are delivered before setting it as invoiced.
opw 614256
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
This fix adds the toJSON() method to datetime.datetime,
so domain expressions can use datetime values directly,
without having to compute the stringified version
with convoluted strftime() and timezone calculations.
The datetime results are sent down to the JSON-RPC
level where the JSON.stringify() serialization will
convert them to UTC string, to be deserialized
properly as UTC datetime values on the server side.
Thanks to this we can use the browser's local midnight
timestamp in a filter expression, for example like this:
`datetime.datetime.combine(context_today(), datetime.time(0,0,0))`
and get the expected result regardless of the user/browser's
timezone.
related to issue #2972 and pull request #2914 and #6229
(Next commit will fix them)
opw-621282
Correctly creates menu and add implied groups.
Since the conversion from res.portal to res.group, we lost the field
parent_menu_id so a search is needed to find parent menu.
To add the access of existing users to the new groups, implied id rules are
needed. opw 612594
When opening the list of meetings from an opportunity, show only the meetings
linked to the current opportunity.
Use search_default_ to be able to remove the filter if not needed.
Remove context on meeting button as it's ignored in action_makeMeeting (and
there is no field attendee_id linked to a crm.lead anyway)
opw 614039
When reading over IN_MAX (currently 1000) records, the select is slip into
subsets of IN_MAX records. However the list of ids was split using set() method
which removes order that may have been pass. The subsets are ordered using
_order attribute but the subsets were not ordered between themself.
This is an issue in case of browsing a o2m field with more than 1000 lines as it
will return sorted blocked but the order of the blocks is the order of the
contained ids (e.g. split(2, [5, 4, 3, 2, 1]) -> [[2,1], [4,3], [5]]).
Removes the set() to make sure the order of the given ids is preserved.
opw 616070, linked to #439
As event_obj._length doesn't return the number of days when the selection spans
multiple weeks, the test was wrong when the selection ended on the first day of
a subsequent week.
This fix was originaly written by rha-odoo at 95d344b, but I rewrote it a little.
I would have liked a cleaner way of finding how many days there were between the
two dates, but I couldn't find anything better, considering I didn't want to
create new objects just for that test.
Fixes opw 614703.
When doing a manual reconciliation, the current filter could restrict the
visibility of move lines and show empty results for some partners (e.g. filter
the lists on only one partner will show empty list of moves for other partners).
This is also the case for multicompany restrictions.
Integrate the current filter to the search to only get results for displayed
lines.
Fixes#3817, opw 618134
Fixes#5221, opw 632095
The name field contains the refund reason.
The reason is filled when you create the refund
from the refund wizard available when
pressing "Ask Refund" on a supplier invoice.
As this field wasn't visibile on the supplier
invoice form, this wasn't possible to change
the reason on draft supplier refunds after
having created them through the wizard, while
you could change your mind or having done a
silly mistake in the wizard, that you could
edit since the invoice is stil draft.
This was also not possible to set a reason
when creating the refunds without going through
by the wizard.
This was also not possible to change the reason
when you duplicated your supplier refunds.
opw-632756
closes#6301
Taxes can be applied on the repair fees.
The field was defined in the model, it was just missing
in the view.
In addition, the product_id_change worked already for the
taxes.
opw-632898
When creating a chained picking, the first move has no sequence, this is because
there is no sequence for stock.picking.internal.
Set the sequence before the chained move so that the sequences are in the right
order. opw 621261
Reasons:
- the currency conversion is done assuming that the cost price currency is the company currency
- we support only one price type per field. Defining several price types on the same field using
different price types is not supported.
Backport of 8.0 code, rev f61339b
Create a new journal item with an tax included, the automatically created tax
line had the amount computed as tax excluded.
Fixes#3731, opw 618305
The context wasn't defined in the below methods:
- action_production_end
- action_in_production
while it is defined in the base methods, in the mrp module.
This doesn't lead to any issue in standard
modules, but it prevents to correctly
override these methods within custom modules
when mrp_operations is installed.
opw-632425
When the margin is calculated, the purchase price is calculated using the currency of the price
type 'standard_price' instead of the currency of the company, since they can be different.
opw: 631884
The state 'Quotation Sent' was not visible on the sales analysis report (e.g.
group by Status). Add the missing state to the report to correctly disaply it.
opw 619748
`setLang` alters the "browse" context of the documents
being printed, but it must also discard any values
already cached, as they could be using a different language.
This is the case when the report uses translatable fields
on `res.partner`, because `setLang` is usually called
with the target partner language, hence prefetching
the translatable fields with the user's language instead
of the partner's language.
E.g. `setLang(o.partner_id.lang)` will cache any
translatable field on `o.partner_id` in the language of
the *user*, not the *partner*.
Denis Ledoux
Nicolas Martinelli
Mohammad Alhashash
Goffin Simon
Thomas Rehn
Martin Trigaux
Josse Colpaert
Nicolas Lempereur
Martin Trigaux
dhr-odoo
Rifakat Haradwala
Vincent Vinet
David Monjoie
Christophe Simonis
Alejandro Santana
rmu-odoo
Christophe Combelles
Olivier Dony
Somesh Khare
Rucha Dave
J Bradshaw
Akash Balar