Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).
Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.
That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.
Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.
Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
print that, it's formatted to show the exception type, message &
traceback
* otherwise format the garbage that is an "ExceptionDetails" object
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit the search would search for phone numbers that contained a part of a string. The mobile phone would only look at exact matches so if we'd search for '0492700' the only result would be contacts with this exact match. After this commit every mobile phone that contains '0492700' will match and be shown. This allows for quickly finding customers by a partial mobile, just like the phone number does.
closesodoo/odoo#43752
X-original-commit: 8a34a6a66f3f06829231e5d0ba536fcdd27d17ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Correct the rounding of several currencies which should be 0.001.
opw-2172122
closesodoo/odoo#43715
X-original-commit: 71f01060ea359814ffdb9ef506a01a2543dfc9ea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This is the second move to replace Filipino by Tagalog language
Using Filipino (code fil_PH) is problematic as conflicts with Finnish
(code fi_FI) and users having their browser in Finnish were redirected
to the Filipino version of the website (cf discussion at opw-2172710).
This problem was also raised in other softwares like in the below
discssion in Mozilla L10N groups
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE
Quoting the discussion in above thread:
> Filipino is the national language of the Philippines, but it is
> commonly referred to (and registered as) Tagalog, since most of the
> terms therein were derived from it (Tagalog).
This commit targets the master (future 14.0 as of today), adds a new
Tagalog language and removes the Filipino.
In 12.0, only the Tagalog was added.
As fil_PH is only translated on odoo-com project but remains at 0% in
other Transifex project, it is assumed the language switch won't
impact too many people.
closesodoo/odoo#43634
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Bug in 13.0 regarding company_id field of partners when creating them from
their parent contact or when setting their parent.
The field 'company_id' of res.partner is set by an onchange on 'parent_id'
to that of it's parent; unfortunately the field is readonly if parent_id
is set and not set to force_save.
Furthermore, creating a child partner from the main one (in the 'Contact'
tab of the main partner form view) does not follow the same behaviour
(company_id is unset in that case, meaning that children don't have
the same company as their parent).
Since the company_id is already set by an onchange when we change 'parent_id'
and set to readonly in that case, I assume the expected behaviour is actually
that children partners should have the same company as their parent by default.
Fine tuning of 7b49f5836c
opw:2176384,2167106
closesodoo/odoo#43621
X-original-commit: 92737f21acf9b044df99e111fceffc08e05abe65
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
1/ When the new database is created without demo data, the admin has a
'silhouette' as a default picture. When a new user is created without
picture given by the current user, the new user will have a 'silhouette'
as a default profile picture.
2/ web: image for fa-user-slash. This image will be used when a record is
unassigned.
3/ web, *: Change placeholder by default when record is unassigned.
We want to have a fa-user-slash icon when a record is unassigned instead
of 'placeholder.png'. A method is created in the BaseModel to have a
generic method to change easily the placeholder for other models.
4/ Adapt kanban test to keep the same behaviour. Attention the behaviour is
a bit different. Because, now the default image is given by the server to
change easily the default image when a record doesn't have an image.
Thus, we don't say if it's the default placeholder, but we can say it's
not the same image of the record (in this test, the record, it's the
partner).
5/ misc: display 'Unassigned' in the hover on kanban cards if record is unassigned
closesodoo/odoo#41356
Taskid: 2060206
Related: odoo/enterprise#7758
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: jdoutreloux <jud@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
The faulty code modifies a dictionary in-place to apply a formatting
function to each value. In this case, the formatting is `browse`, and
the issue occurs when `ids` contain duplicates:
for id in ids:
result[id] = format(result.get(id, default))
Fix it by returning a new dictionary based on `result`.
X-original-commit: bd4565e227c7196604af9c5c51ce136a2beac088
Some code modify return of res.users().context_get, but this is a
cached method so this will unexpectedly affects totally unrelated code.
For example, changing the company with the company switcher could add
`allowed_company_ids` inside the cache, then it will be cached until the
server is restarted, even if we change company again inbetween.
Added test failed with:
"NotImplementedError: '__setitem__' not supported on frozendict"
on the line with `User = User.with_context(context)` where User already
contained `allowed_company_ids` in its context.
note:
in this forward-port, context_get is also changed to return frozendict
and prevent being able to have an unexpected issue by code that modify
context_get returns.
opw-2158340
closes#42465closesodoo/odoo#42723
X-original-commit: 5d69885c1cd6921b3de00aae7e0ed6fff243ff95
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, bank accounts tab on partner view is available directly
in base whereas it should not, as it contains information useful only
for accountants. We therefore move them directly to account.
Task ID: 2172260
closesodoo/odoo#43322
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Query counts weren't adapted to recent performance changes.
This commit updates the different query counts to make sure
any commit changing the query counts knows it and does it on purpose.
Some query counts may vary between community and enterprise
and therefore have a higher value than needed in community version.
closesodoo/odoo#43202
Related: odoo/enterprise#7682
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
If check company is set on a field and if the user has no access
right to the field value (example: address_id on an expense sheet
could be set to a private res.partner, on an onchange method when
setting the employee), then the check_company mechanism will
raise an AccessError when trying the validate the companies on
the different records.
Specification
=============
As we only wish to validate the new record values and not the
access rights, the validation could be done as a superuser to
avoid unecessary errors.
closesodoo/odoo#43240
Taskid: 2170006
X-original-commit: 37a9b6c63dcbc268013fbe1a890cf9390eb8e223
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the SSF, o2m updates get initialized with no values (1, id,
{}). The record data is only fetched when the "record" gets updated
explicitly from which updates will hopefully get properly tracked &
saved.
However if the "record" was first initialized through an onchange
values which are updated by the onchange (diverging from the db) those
would not get tracked and thus wouldn't get saved when the record is
saved.
* use more specific placeholder (None) for "o2m records to update but
we don't have values yet"
* once we have values, always store them as an update-tracking dict
* if we don't have values yet for an o2m and an onchange is trying to
write to it, initialize with values from database first (might
eventually be a good idea to initialize upfront though there's the
question of what happens for default values and recursive views)
* mark anything coming back from the onchange and differing from local
values as changed (so they get sent out on save)
* properly reify parent values for onchange instead of sending them
as-is
* the evaluation context for contexts (and domains) needs properly
formatted values so use `_values_to_save` to get them, however it
cares about neither required-ing nor filtering out e.g. unmodified
fields, therefore add an awful toggle to handle this
Task 2150302
Probably todo in the future:
* better UI for change-tracking dict, should have "snapshot"
support (to freeze / discard previous changes)
* cleanup save, it's unclear that it properly resets the form
closesodoo/odoo#43235
X-original-commit: 6c99fe3ffec3aeb8d210e3b943ccef81d62d44ce
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Example:
User 1 has access to company A
User 2 has access to company B
Customer 1 is shared, has user 2 as their Salesperson
Try to create a SO for Customer 1 as User 1
=> access rights issue, the quote is trying to set User 2
as the salesman of the quote but cannot because of
base.res_users_rule
This commit makes this flow possible by sharing users
if they're not portal.
closesodoo/odoo#43190
X-original-commit: ebc8d85d383643c1d4d2aa6723bc7a589c7d1c68
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.
After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed
Task ID: 2126832
closesodoo/odoo#40563
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some library versions are outdated since the release of Debian Buster.
With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).
Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.
As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.
Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.
closesodoo/odoo#43106
X-original-commit: 32e455bf72980e6330871aa9cd99c26c6e1225d7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since dae065d, model defaults are retrieved based on the env company instead of
the user's company.
However, for a request with auth='none', the company might not be set on the
environnement (if `allowed_company_ids` is not in the context).
This makes the sql query crash, trying to compare an integer to `false`.
closesodoo/odoo#42951
X-original-commit: fa47b1b23a7fa09166c16aacf025cdcefcfaa9fd
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
The constraint view in Odoo has no good quick search options to filter/group and find
specific constraints easily.
This commits allows you to easily group and search for the most used values of
constraints. This will make the finding of constraints easier for functional people.
closesodoo/odoo#41288
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
``_split_street_with_params`` method is defined in base, on partner model. It
is redefined in ``base_address_extended`` without calling super. Only that
module use it. That means that the base implementation is not used anywhere
in the codebase, leading to dead code. Let us remove that method.
Task ID 2158302
PR odoo/odoo#42678
Currently when writing on street field of company model, its sub-fields
(notably street_name, street_number and street_number2) are not correctly
computed again in cache.
Indeed address sub fields have no direct trigger as it depends on its
partner_id and its partner_id children (see ``res_partner.address_get()`` and
``res_company._compute_address()``).
When writing on address fields from the company record, we then invalidate
all address fields cache in order to force their computation.
This commit adds a new tool method giving the list of fields coming from the
address partner to copy upon the company.
Task ID 2158302
PR #42678
Consider an x2many field with `context={'active_test': False}`. The
value of that field should always contain inactive records, as the
field's own context overrides the context of the current record.
closesodoo/odoo#42824
X-original-commit: a2fc37adc179fb8bfc11251137334f0a43c58135
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`run_action_` hooks don't always return a value, in which case
invoking run() over RPC will raise a TypeError (though the call itself
should still succeed).
Somewhat oddly, "standard" hooks (e.g. in mail) generally do
things safely and return a `False`, but the "builtin" hooks (code,
object create and object write) tend to return nothing, and thus break
when invoked over RPC.
Fixes#42268Closes#42272closesodoo/odoo#42804
X-original-commit: 9ad01ef242afc9602d4a1470cb321374129f29b9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
* add a runtime warning when an onchange method contains the string
'domain'
* add a lint test to forbid the string 'domain' in onchange methods,
this is easy to defeat (e.g. `dict(domain=...)`) and can have false
positives (literal `'domain'` strings for reasons other than an
onchange result) but overall it seems to work nicely
* implemented as a non-pylint test as pylint takes ages to run. While
at it, remove the long-disabled and long-useless
PEP3110TokenChecker (checks for `except Exception, a` which is a
syntax error in P3)
Task 2115472
closesodoo/odoo#41918
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Without this flush, partner computed fields are not computed when creating
the company, leading to a cache miss. It is due to the quite complex model
introduced in base_address_extended with multiple related / computed / inverse
fields.
How to reproduce
* have base_address_extended installed;
* create a company with address bits (street_name, street_number,
street_number2);
* encounter a nice cache miss bug (partner<ID>.street_number):
Original task ID 2068145
PR odoo/odoo#42701closesodoo/odoo#42722
X-original-commit: 69ea928828fca06c9b0f589e23ca3c0d4c387ab0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Fine-tunning of 42eec88e5da164e4930c48113109f2c8d4b73da3
Before this commit, the assets were not found when the user is connected
in mode debug assets in a multi-website and multi-company. This occurs
because the attachments (assets) were created only for the first website
accessed, and cannot be loaded when trying to access the second website.
Now, the attachments are created for each website accessed and can be
loaded withtout problems.
closesodoo/odoo#42593
X-original-commit: 95077a8cdd9f2cd99c2ef85bdf7ca5d58e006b71
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Commit d86c2c5883 removed the multi-company partner rule because it
interfered with the users rule. Indeed, interference between the user's
default company and its corresponding partner's company made it possible
to have users that were basically unselectable in relational fields if
you were not viewing more than one company at the same time.
However, this generates a lot of frustrations and tickets for Odoo
users, since having everything shared by default is annoying and a clear
departure from the expected behaviour.
This commit tries to mitigates this fix's side-effects by re-introducing
the multi-company rules but by not applying it to partners who are linked
to a non-share user (basically, any partner who has a user that is not
a portal user). That way, customers and vendors remain filtered by the
multi-company rules and only partners of internal users bypass the rule.
This is still a side-effect, and might raise a few eyebrows (why is this
partner visible even though it is in another company?), but the
trade-off seems to be worth it since it fixes the original issue with a
far smaller behaviour change.
Fixes#41720.
closesodoo/odoo#42592
X-original-commit: 2390ba60b8bd624daaea2e6d4e3fd85ef1b1faeb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This is a changement succeeding 13.0 7eb603b26c, in that commit the issue
was solved but only in the case of en_US base language of translation
which can not be the case on a website.
opw-2153422
closes#42269closesodoo/odoo#42467
X-original-commit: 191075454563c7e15b22d20b21afeb8bcc5601c4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When an attachment is linked to a record (res_id and res_model are set)
we check the access rights and access rules of that record.
The access we check on linked record has changed as follow:
- 15905e78 (2013) => we check `write` access right/rule for `create`
- f5ebc509 (2014) => we check `write` access right for all mode
- 66644e85 (2015) => we check write access right for all but create mode
So currently we check on the linked record for each mode:
- create: write access right / write access rule
- read: read access right / read access rule
- write: write access right / write access rule
- unlink: write access right / unlink access rule
The behavior is not expected for `unlink`, we should check if we have
write access through access rules instead of checking unlink access.
Without the change, the added test failed with a `unlink` access rule
AccessError on the linked record.
opw-2154448
closes#41814closesodoo/odoo#42264
X-original-commit: 2b3fc2e3b80f191b4cd126abccf6f94b1302ac11
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Assume F and G are computed by the same method on a missing record R.
During recomputation of F on R, the compute method is called but fails
because R is missing. Both fields are re-marked to compute (because
computation failed), then F is discarded (because R is missing). Then
comes G's turn: G is accessed on R and the computation fails. Both
fields are re-marked to compute (because computation failed), then G is
discarded (because R is missing). Now F is marked again to compute: the
process never ends.
To avoid this situation, discard all fields to recompute on missing
records.
closesodoo/odoo#42234
X-original-commit: 78bf4dbaa1c4adfa1dac68a4d79b87800003ac05
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
Ensure that expression.OR and expression.AND and some other
expression.py methods do not propagate or rely on TRUE_DOMAIN and
FALSE_DOMAIN that may be muted on some instance.
For example, if we did:
self.search(expression.OR([]))
then in the search method we do something like:
received_domain.append(('res_field', '=', False))
before this commit, FALSE_DOMAIN would be altered for any succeeding code
that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`.
Without the changeset, the added test would fail with:
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
note: another commit referenced in #41968 should make the TRUE_DOMAIN
and FALSE_DOMAIN immutable.
related to work on opw-2154448
closes#42107closesodoo/odoo#42222
X-original-commit: 303ce32e6ccd7432b96ffae545e4a6eced68ae84
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Company used to get defaults was user.company_id and not current company
in the environment.
Fixes#41679closesodoo/odoo#42153
X-original-commit: af50c694445d49f1098de4236b6e8bdd9b1c93f2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
If a long-running transaction holds a write-lock on any row in
ir.attachment, the GC job can wait an indefinite amount of time to
acquire its table-wise SHARE LOCK.
While sitting in the queue for this lock, it will conflict with any
future transaction that tries to acquire a write-lock on any row [1].
So the GC transaction, which would normally execute very fast and
immediately release its lock, will start to block other transactions and
cause severe delays in response time. It basically depends on how long
the tx holding the lock takes to complete... which is unknown.
As a workaround, we force an arbitrary (but short) lock_timeout in the
GC tx before attempting the lock. If it fails to acquire it, it will
fail and raise, causing the whole operation to abort. The cron job will
be rescheduled quickly because it failed to complete, giving the GC
another chance to complete.
10 seconds seems a reasonable compromise, as it gives the blocking
transaction(s) some time to complete before bailing out, yet should
not be long enough to bring the system to a halt due to other
transactions blocked by the GC one. I have no hard data to back this
claim, though.
[1] See the LOCK conflict table in the documentation:
https://www.postgresql.org/docs/10/explicit-locking.htmlclosesodoo/odoo#42128
X-original-commit: 8a093c74c209d492f066c927cc4ac61325aee3ae
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
We are looking for the "Bom Count" stat-button, which can be hidden
behind the "More" dropdown, depending on the number of installed modules
and views inheritance order loading.
closesodoo/odoo#42085
X-original-commit: dc4a40cc130175a60aa77a0660613b23c4bb916f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Issue
- Export all english translation
- Import the file and override existing terms
Cause
When importing, we try to insert the translation if
it doesn't exists. If it exists, we do an update via
a "onconflict" rule.
This update can be done only one time but in the values to import
there are things like:
```
( 'Account', # translation
8, # numbers of duplicate
['account', 'account', 'account', 'account', # modules
'account', 'account_ponto', 'account_yodlee', 'payment']
)
```
Solution
It will not be fixed in stable to avoid performances issues.
Instead, we will display a clearer error message.
As it's a `psycopg2.ProgrammingError`, the cursor is aborted
and we can no longer use it to retrieve translations. This
is why I use a save point.
OPW-2150610
closesodoo/odoo#41934
X-original-commit: e108770d55b42a1793085a169145492b39d0a15c
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
The filename can be obtained in 3 ways when downloading a file, in order:
- by the filename argument
- by the filename_field argument
- a default one is computed as backup.
In the last case, there is by construction no file extension.
The filename is made from the record's model name, id and field.
However the model name almost certainly contains a ".",
which is the standard extension separator for filenames.
As a result <model_name_end-id-field> is considered to be the existing
extension, so we don't try to guess it from the mimetype.
To keep the existing default filename convention, we always add the
guessed extension in this case.
opw 2149612
closesodoo/odoo#41924
X-original-commit: f62a49a2f83bcce66eb9c3b08687ee5a37def503
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
On the website when you modified a string with not much change, we
modify the translation source so they are not dropped.
But we also do it for an en_US translation, so if we have a translation:
lang=en_US/src=helloworld/value=helloworld
if we change `helloworld` by `helloworld!` the translation would become:
lang=en_US/src=helloworld!/value=helloworld
which would make it seem like the change did not work at all.
Without change, modifed test fail on second:
self.assertEqual(view.with_env(env_us).arch_db, archf % terms_en)
with assertion:
AssertionError: '<form string="X">Bread and cheeze</form>'
!= '<form string="X">Bread and cheese</form>'
opw-2153422
closes#41714closesodoo/odoo#41809
X-original-commit: 7eb603b26cc591b85ceb11210f5db8308d2ba27a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set active = false on menu that has a parent
- Delete the parent menu.
It crashes in the unlink method of ir_ui_menu
because it didn't set parent=null on records that are inactive.
Because the search method to get children
of a menu item only returns node where active=true
if `active_test` is not passed in the context to
disable this active test filter.
closesodoo/odoo#41859
X-original-commit: a9c0c1d45583d547754735e857168d5ae27876a5
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
To be able to detect issues in .pot like at #41364 due to bad .pot
file (cf fix at #41650)
closesodoo/odoo#41778
Related: odoo/enterprise#7200
Original-signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
X-original-commit: ba39590b004655df55d5d182c4ad50caa7f583c1
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Xavier Morel