The headers returned by content_disposition must be either in Unicode or in ASCII.
The encode function expects a Unicode or ASCII string.
The quote function from urllib2 expects a UTF-8 string and retruns a ASCII string.
opw:634205
Fixes#6160, #6557
This is related to revision 65d7cc524d
The `order_line` field of `purchase.order` is readonly within states
aprroved, done. See the field definition. This means it should be
possible to remove lines of a `purchase.order` when the PO is in
any other state than approved or done.
Therefore, the deletion of lines shouldn't be prevented
when the PO is not in state approved or done
opw-634538
sometimes some blank spaces are lost in subject of some incoming messages
There is a bug in `decode_header` in Python < 3.3,
which leads to lost some spaces in the email subjects
when several encodings are used in this subject.
See
- Issue: http://bugs.python.org/issue1079
- Fix: https://hg.python.org/cpython/rev/8c03fe231877
Joining the strings returned in the result of `decode_header`
solves most cases. Only extreme cases, like having
a subject with several different encodings following
each other without white spaces between them could lead
to have extra spaces in the subject. It won't happen
most of the time.
Closes#6629
When duplicating confirmed bank statement lines,
the many2many `move_ids` links were preserved, and,
therefore, there were links between the duplicated
lines and the move entries of the original lines.
Closes#6617
When importing a CSV file with an "id" column containing
external IDs (XML IDs), the system automatically creates
or updates the corresponding ir.model.data entries.
This would fail for regular users who do not have
create/write access on this internal model.
With Safari, the function content_disposition must return "attachment; filename=\"%s\"" % filename
to avoid that Werkzeug raises an UnicodeDecodeError.
Fixes#6160
opw:634205
In SQL, the addition/subtraction between NULL and an integer/numeric
returns NULL.
Therefore, if either debit or credit was set to null instead
of 0.0, debit-credit returned null, instead of the actual subtraction
opw-634044
Within the 'import invoices' wizard in bank statements
(addons/account/wizard/account_statement_from_invoice.py)
Prevent currency rate differences when the statement
currency is within the company currency (and therefore
the debit/credit fields are already within the currency
of the statement)
opw-631895
Closes#6504
The datejs globalisation files are loaded based on the user's language.
If the file is not present, the loading crashed and the user could not access to
the web client.
Adding empty files for lo_LA and renaming bs-BS.js to bs-BA.js for bs_BA (see
65d92da) that were missing.
By the way, this is a 0 bit commit, beat that!
When using another decimal separator than `.` (dot)
in the language settings,
it wasn't possible to build an advanced search specifying
the decimals.
e.g. with a language with decimal separator `,` and thousand
separator `.`,
if you want to search invoices with amount total 366,38
The advanced search "Total" "is equal to" obliged you
to enter your number with `.` as separator (366.38),
and then, when entering the search, the `.` was
regarded as the thousand separator, giving as domain
`('amount_total', '=', 36638)`, which is not what you asked.
opw-634201
PS: The `|| '.'` in the xml template are only for
retro-compatibility, so if the server sources are
updated, but the browser cache is not refreshed
(meaning the Javascript code isn't refreshed, and,
therefore, `widget.decimal_point is undefined)
it still works.
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.