The patch fa492d87f4 has been backported
from Odoo 12.0, that runs on Python 3.
The string '\n\n({} {}, {} {})' to be formatted is a byte-string in
Python 2, while the return value of _() is always a unicode-string.
As format() is (too?) nice, it attempts to convert the unicode-strings
into ascii in order to inject them in the format pattern.
With some languages that are written in ascii, this works -- by chance.
When you use non-ascii languages like Japanese, it fails.
We then fix that issue by using unicode-strings in the formatting
pattern.
#OneCharacterPatch B-)
opw-2032016
-----------------------------
For full technical understanding:
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '{}'.format('test')
'test'
>>> '{}'.format(u'test')
'test'
>>> '{}'.format(u'エ')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u30a8' in position 0: ordinal not in range(128)
>>> u'{}'.format(u'エ')
u'\u30a8'
closesodoo/odoo#34698
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Before this commit, when a transaction has as status 'authorized', the
transactions' confirm page gives an error : 'Oops! There was a problem
with your payment.'
Now, the page gives the same message as when the transaction has the
status 'done' : 'Your payment was successful! It may take some time to
be validated on our end.'
opw-1984325
closesodoo/odoo#34652
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, on a device with a "pen" (e.g. Surface Pro, ...),
it was not possible to sign a document on some browsers recently
updated (e.g. Chrome, Firefox, ...) only Internet Explorer was working.
Instead of drawing continuous lines only few dots appeared.
For Chrome and Firefox we have to catch events with "addEventListener".
For Edge we add touch-action property to convert touch events into click.
Steps to reproduce:
1) Go to sales app
2) Then go to quotations (menu Sales)
3) Create a new quotation
4) Click on preview
5) Click on the "Accept" button at the end of the preview
6) Use the "pen" to draw the signature (BUG)
We use a custom version of the jSignature lib (c.f. odoo/odoo@eddcb46),
so we have to patch the file in the Odoo repo with a mix of some
pull request found in the official repo and forks.
Link:
https://github.com/brinley/jSignature/pull/109https://github.com/brinley/jSignature/pull/159https://github.com/willowsystems/jSignature/pull/96
opw-2029684
Backport somewhat improved version of this fix (we don't need to check
for the existing extension since we're not doing anything if there is
an extension at all) merged into later branches, to avoid forward-port
conflicts.
closesodoo/odoo#34509
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Fix/improve commit d870749d79
that was removing line feed (\n).
In this one, we also remove carriage return (\r)
to address all cases.
closesodoo/odoo#34536
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Detected with OPW 1920765
Reproduce : set multi-companies, install accounting. The due amount for all companies is the sum of the due amount for every single company
Cause : the context for company_id is not set in account.move.line:_query_get
Solution : set it in res.partner:_credit_debit_get in case _query_get is used elsewhere
closesodoo/odoo#30463closesodoo/odoo#34486
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Let contacts be shared in a multi-company setting.
Make a filter on 'Total receivable', e.g. greater than 0.
All contacts that correspond to this clause are show,
even if their Total receivable is nonzero in another company.
It follows that a partner can be shown by the filter with a value 0.
The inconsistency was created by 017184331b, which adapted the compute method
to the multi-company setting, as before the two were summing all companies.
opw 2028660
When an `IntegrityError` is raised, the user receives a cryptic error
message which doesn't provide much valuable information in order to
solve the problem.
However, such an error is raised in 3 cases:
1. A mandatory field is not provided at creation/update.
2. The deletion of a record makes a mandatory Many2one field NULL on a
referenced table (`ON DELETE SET NULL` on a not nullable field).
3. The deletion of a record raises a `ON DELETE RESTRICT` foreign-key
constaints.
In the first and second cases, we provide the table and field on which
the `NOT NULL` constaint is raised. We also suggest to archive the
record in case of a deletion.
In the third case, we provide the table and the constraint raised. We
also suggest to archive the record.
Notes:
- The IDs of the records causing the issue is not provided since the
information is not provided by PostgreSQL.
- Although cases 2 and 3 have a different root cause, the error
message raised is very similar. Indeed, from an end-user perspective
the solution is identical: archive the record. Another solution would
also be to manually edit the records raising the error, but most of
the time this is not an option: these records are locked and cannot be
edited anymore.
task-1970853
Closes#32949closesodoo/odoo#33922
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Sapan Zaveri <sza@odoo.com>
Co-authored-by: Pragya Ladda <pla@odoo.com>
It's currently possible for binary downloads to be missing an
extension entirely. Generate an extension from the mimetype and use
that. Also ensure the existing extension (if any) matches the
mimetype.
Warning: this may require adding new mimetype/extensions pairs to the
local mimetype database similar to
f413d155df.
Also fix missing or incorrect filenames on records without a filename
field: in some Odoo versions the client would send a filename of
"null", resulting in a download of e.g. "null.pdf" instead of the
attachment or inferred name.
Task 2025716
closesodoo/odoo#34299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Make a SO with a product that have a carriage return in its
description
- Export FEC report
The CSV contains new lines and is not correctly formatted.
opw-2026861
closesodoo/odoo#34385
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A special folder named `0.0.0` can contain scripts that are run on
upgrade of any version.
They are useful to make some sanity checks or other verifications to
ensure database consistency.
The first version of this patch used the more eye-catching `any` for
the migration folder, but it was problematic for upgrading from an older
version that doesn't contain this patch.
Using a version "number" containing two dots is required to avoid it
being prefixed with the server version (see `convert_version` method) and
resulting in a version like `10.0.any`.
Such version would have been executed, even without this patch, when
upgrading from an older major server version (9.0.1.0 < 10.0.any).
closesodoo/odoo#34268
Signed-off-by: Christophe Simonis <chs@odoo.com>
- Create 2 included taxes: 21 % and 6 %
- Create a product A with 21 % as default tax
- Create a fiscal position to map the tax 21 % to tax 6 %
- Allow the fiscal position in the POS
- Add product in a POS order
- Apply the fiscal position
The subtotal is not recomputed correctly. On the other hand, if the
fiscal is first set then the product added, there is no problem.
This is because the `fix_tax_included_price` is only called by
`add_product` and not when changing the fiscal position.
opw-2020755
closesodoo/odoo#34260
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).
1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).
Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.
2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.
closesodoo/odoo#34243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Stock.locations should be in no-update:
Limit the impact of recompute fields during the upgrade of stock module. (especially method _compute_product_availability)
Limit the impact on migration
Method _compute_product_availability is triggered during an upgrade of module and during migrations.
This may take a lot of time of big databases
closesodoo/odoo#34074
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.
The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.
opw-2006647
closesodoo/odoo#34076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Installing test_new_api without demo will fail since demo_user
does not exists. This is a problem if we want to test migration
with all modules installed. This simple fix solve the problem.
closesodoo/odoo#34065
Signed-off-by: Christophe Simonis <chs@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33945
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
Before this task, when creating the related field from the studio, it is by
default stored. When we change the field name in 'ir.model.fields' using ORM's
write method, it also renames the column in the table associated with the
field's model.
This is the expected behavior. But when someone tries to change the 'name' of a
non stored field, the column is not available in the associated model, and so
trying to rename the column results into traceback. This issue was probably
there for a while but came into light with the task 1985710. More info can
be found on the chatter of the task.
This commit fixes the issue by adding an extra check before renaming the table
column. The query will be executed only when the field is stored and thus
exists in the table.
closesodoo/odoo#33944
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The content of these fields can't be updated, there's no reason to
even show them. Just remove them from the default / auto-generated
view for client actions.
Task 1772242
closesodoo/odoo#29179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Martin Trigaux