Copying a custom model's record seems pointless by default, since
no field is actually copied.
It makes sense to copy at least the `x_name` field, to make it clear
to the user that the system understood it was duplicating something
and not just creating something entirely new.
time.clock is deprecated since python 3.3 and no longer exists in python 3.8
time.process_time was introduced in python 3.3
Replace "is" by "==" as this produces a SyntaxWarning in python 3.8
Fixesodoo/odoo#41313closesodoo/odoo#44502
X-original-commit: f03b4cb5576f264b6845242ba112f02422af4f5f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Closes#43580Fixes#9449
Adds field type conditions for boolean in search for Property model.
As False values are not stored in DB for boolean, the search() does
not return any value for non existent lines with:
* operator: '=' and value: False
* operator: '!=' and value: True
Uses the 'include_zero' and inverse operator mechanisms implemented
in Property model.
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Allow a naive `group_expand` for manual fields where having the
attribute set to True causes the ORM to include all records from the
relation model of the m2o field in the read_group.
This is particularly useful for custom m2o fields which represent
stages - a grouped list view or a kanban view should include all
possible stage, not only the currently used values.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
Up until now, it was impossible to specify the default ordering
on models created manually.
This could somewhat be bypassed by specifying the ordering of records on
views themselves, but this has one main drawback: when using a
relational field that targets a custom model as a group-by key, the
ordering defaulted to the id of the custom record. For example, if I
create a custom field on partners that points to a custom model
'x_grade' on which an 'x_sequence' field exists, I could order my grade
in their own list view according to their sequence, but any read on
partners grouped by this 'x_grade_id' field would order the returned
groups by id while I would prefer to have them ordered according to the
'x_sequence' field.
This commit introduces a new field 'default_order' on the ir.model model
that can store this default ordering clause (as an SQL expression).
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When removing a custom model, it remained listed in the base classes
(normally `base` and also possibly a list of mixins; e.g. `mail.thread`
or `mail.activity.mixin`) list of inheriting classes, possibly causing a
crash when trying to reload the registry.
This commit ensures that any custom model is removed from its parent
class `_inherit_children` set; it will be re-added automatically during
the call to `_build_model` if the custom model still exists.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When the db reflects the python models at startup, a query is generated
to update various `ir` models (models, fields, etc.). This query did not
properly escape identifiers, preventing the use of the 'order' field
name on ir.model because it is a reserved keyword in SQL and wasn't
escaped.
This commit introduces proper escaping for these reflection queries.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
With this commit, the url widget automatically prefixes the href
url by http:// if no protocol is specified, so that clicking on
the url will by default redirect to an external website.
To prevent this behavior, one can still specify the new option
'website_path: true' on the url field node in the view arch.
Thanks to this, we can remove a similar logic (only implemented on
res_partner model) which automatically altered the value saved in
database to force its 'http://' prefix.
task-2153184
closesodoo/odoo#42118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The issue is: the user wants to send an invoice to a customer, changes
the email template, and after the onchange, the field "Template" of the
wizard is empty.
Here is what happens. The onchange on the template renders a PDF file
with the corresponding invoice document. The rendering builds some
assets to convert the invoice to a PDF document, and former assets are
deleted. The deletion of former assets (`ir.attachment` records)
invalidates the whole record cache, which implicitly clears all the
fields of the record of the onchange.
The problem is that the asset is systematically invalidated by the
rendering of the report itself. This hack changes the CSS assets to
introduce company-specific colors for the rendering of reports. This
implementation is actually not consistent with the fact that assets are
kept in cache by the server.
This patch does not fix the root cause of the problem, but it reduces
the sides effects of it, and makes the issue above less frequent. It
simply consists in not updating the asset's attachment when its value is
already correct.
OPW 2168623
OPW 2171040
closesodoo/odoo#44295
X-original-commit: b1ddd9c95bc642e42eb0d3d51066902d5283ba04
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
In this commit, we add a new attribute "Delete" for user conveniency
if he don't want 'Delete' button on popover card they easily achive
by "delete=false" attribute and also add a testcase for it.
task-id:2088954
When we name_search a res.user, we have a special hack so we will
firstly perform an exact search on the res.users login, if none is found
we will search over res.users name.
This is intended but in the case of negative search since 660cebb4faaeb,
for example operator='not ilike' and name='test' would probably just
return all user that do not have a login that is exactly test.
This is not the intended behavior, in this instance we should just
return user that do not have "test" in their names.
Without fix, added test would fail on:
- .name_search('vlad', operator='not ilike') => finding everyone but
user with exactly login vlad instead of user not containing vlad in
their name
- .name_search('', operator='not ilike') => find all users instead of
finding no user
- .name_search('lad', operator='not ilike') => find all users instead of
just finding "Nothing similar"
opw-2170517
closes#44040closesodoo/odoo#44152
X-original-commit: 2378fb63c132c0bcf027785d478c0608b59a3409
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Let's consider a company partner P with company_id = A
- Let's consider an other partner C which is a child of P
- Change the company_id of P to B
Bug:
The company_id of C was not changed even if the field company_id
of C is in readonly as he has a parent.
opw:2179632
closesodoo/odoo#44061
X-original-commit: f41f7dc0f4f2a1682c6f81aba6512306ecf86067
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose of the task is to get the contact tags in the list view, even if
membership is not installed and get the actual tags instead of 'Records 3'
by setting a many2many_tags widget on it.
closes odoo/odoo#43399
Taskid: 2172137
Closes: #43399
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Open the form view of Contacts with some children
Some children have phone number set on them.
Before this commit, the phone was not displayed
This is due to the same reason as #35869
After this commit, the phone number is displayed.
Although widgets can't be supported in this case
closesodoo/odoo#40266
Related: odoo/enterprise#6706
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Consider an x2many field `foo_ids` with `context={'active_test': False}`
in its definition, and a comodel with an active field. The value of the
field includes inactive records.
Now consider a search with a domain like `[('foo_ids.bar', op, value)]`.
The search should return all the records with corecords that satisfy the
domain `[('bar', op, value)]`, including inactive corecords, because the
field's context explicitly disables filtering on the active field.
closesodoo/odoo#43625
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit executing m2m commands in batch would lead to undesired
results, such as duplicating the related records on every subsequent record of
the batch.
Indeed since [1] the `create` and `unlink` are called in a loop, but their
content was not reset at each iteration.
[1] 9920f20e4cclosesodoo/odoo#43950
X-original-commit: 0800f64b011c8f020c0d7dd6e1c149aebd1a4627
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
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