Apparently a migration error in
0fd773a486, probably never noticed
because nobody ever tries to copy config objects since there's a
bespoke widget, and it's specifically forbidden.
Also fix the signature of the method itself to match the normal one.
closesodoo/odoo#82711
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Before this commit: a notification asking to reload the current window
appeared as soon as the server detected a change in one of the assets
bundles, even on first load.
To fix this problem and make the feature more meaningful, it has been
decided to only notify the client when the server version (not the
bundle version) is outdated (i.e. on database upgrades, when the changes
in the code are actually relevant).
closesodoo/odoo#82032
X-original-commit: a3b5a9d715be6a93c7f2859074b916f3249f97c3
Signed-off-by: Antony Lesuisse <al@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Automated action with a many2many field and reference evaluation can be created but don't work
Steps to reproduce:
1. Install Automated Action Rules module and Contacts app
2. Create an automated action for model 'Contact' with trigger 'On Creation' and action 'Update the Record'
3. Add a line to the automated action 'Data to Write' for the field 'Tags (res.partner)' with evaluation type 'Reference'
4. Go to Contacts, create and save a new one
5. An error is raised when trying to execute the automated action
Solution:
Raise an error when a many2many field is of evaluation type 'Reference'
OPW-2673939
(This PR is a duplicate of https://github.com/odoo/odoo/pull/82035 which for some reason couldn't do the forward ports)
closesodoo/odoo#82168
X-original-commit: 8d45823f2dda24c03b427ecbe7003a64b63d01b7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, if a theme record (eg `theme.ir.ui.view`) was deleted,
its copy_ids would not be.
While this is perfectly normal and wanted behavior when this is done in a
website context (to not alter other websites), it shouldn't be the case when
performing a theme update through CLI/Migration (or if the user find a way to
update the module through the UI).
Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040
closesodoo/odoo#81953
X-original-commit: 3146dd72e6cb07d6e78ca763325f13dd54de0086
Related: odoo/design-themes#548
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Core client remains incompatible with CSP, however it can't hurt to
CSP the sub-resources.
Current scheme is simplistic, however if useful of necessary it could
be made more flexible e.g. there could be a map of mimetypes to CSP
configuration, that sort of things.
All textual content generated by opening the tag must be flushed before
inserting the default content
closesodoo/odoo#81700
X-original-commit: effeba10787388ee0a3d153c984fab5731fc9b1a
Signed-off-by: Thibault Francois <tfr@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
- Remove unused imports `AsIs` and `Collector`
- Remove unused logger _schema
- Remove unused function same_name
- Remove unused attribute `_needaction`
- Remove backward compatibility of `__new__` and `__init__`
- Remove backward compatibility of `__export_rows`
Also:
- remove deprecated warning in api.py
- remove the `__init__` from `ir.ui.menu`, it was useless
because the cleaning of cache (`clear_caches`) is global (a call of
`clear_caches` clean all cache method with a ormcache decoration)
Part-of: odoo/odoo#79563
And make configurable via an ICP. Provide a reasonable default value,
and use it as a lower bound so user error can't lead to an insecure /
unsustainable amount of hashing.
Aside from being somewhat overdue on account of age (passlib's current
default were last updated 6 years ago), this is also made much more
feasible by API keys, meaning non-interactive use (RPC) is less
strained by the (interactive) password hashing.
Also modernize passlib usage:
* Remove global `DEFAULT_CRYPT_CONTEXT`, create inline (as overhead
should not be too huge given what we're doing with it), and
`ormcache()` for safety, the caches should be invalidated on any ICP
addition, removal, or update, so user update to the rounds
configuration should get reflected immediately.
* Switch on `deprecated=["auto"]`, feature was added in 1.6 and we now
depend on 1.7.
* Remove mentions of `encrypt`, it is deprecated in 1.7.
closesodoo/odoo#81498
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
It used to be a tuple.
Cf: 1abe965b59
opw-2681777
closesodoo/odoo#81312
X-original-commit: aa74f51db7bf5a8ad1f4e309b6352df3c31037ec
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
When there are multiple databases on a single server, it is necessary
to be able to set the "from_filter" for the implicit SMTP server
on a per-database basis, to allow 'opt-in' to the automatic wrapping
of email notifications.
When set to e.g. `notifications@example.com`, and a default SMTP
server is defined in the server-wide config or CLI, outgoing emails
will be automatically rewritten to come from this email, unless the
From/Return-Path domains match the `mail.catchall.domain` parameter.
Task-2710632
closesodoo/odoo#81277
X-original-commit: 8b468e1f7a3dfeb2bcfa83bff55c4b5adf6b2212
Signed-off-by: Olivier Dony <odo@odoo.com>
Without this index, finding the user(s) of a partner makes a seq scan, which
could take up to 100ms on my machine with only few thousand users. By adding the
index, the time is reduced to around 5ms.
Part of task-2702450
closesodoo/odoo#81176
X-original-commit: 372f1c5ebac4b9b542994ea5aaad59abe7290918
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
This is a bunch of fixes (65 corner cases) for the search on
company-dependent fields:
Without a default value:
- `char` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `(..., '!=', '<string>')` doesn't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `date` and `datetime` fields:
- `(..., '!=', <Date/datetime>)` doesn't return records with unset value
- `(..., '=', False)` doesn't return records with unset value
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., 'in', [..., False])` doesn't return records with unset value
- `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `boolean` fields:
- `(..., '=', False)` and `(..., '!=', True)` don't return records with unset and `False` values
- `integer`/`float` fields:
- `(..., '!=', <number>)` doesn't return records with unset value
With a truthy default value:
- `many2one` fields:
- operators `not like`/`not ilike` don't return records with unset value
- `(..., '=', False)` returns the record with the default value (which isn't `False`)
- `boolean` fields:
- `(..., '=', False)` doesn't return records with unset and `False` value
- `(..., '!=', False)` returns records with unset and `False` value
- `integer`/`float` fields:
- all `(..., operator, value)` which include value 0, return all records with unset value, even if the default value does not satisfy the domain
closesodoo/odoo#80994
X-original-commit: 3e3be652ece83420782070bdb13da2c3a4930046
Signed-off-by: Raphael Collet <rco@odoo.com>
>>> u1 = self.sudo(False).browse(1)
>>> u2 = self.sudo().browse(2)
>>> (u1 + u2).env.su
False
>>> (u2 + u1).env.su
True
Ensure all attachments are always in sudo
Before this commit, a portal user could not go in debug asset
Introduced at 3a98996eed
closesodoo/odoo#80807
X-original-commit: 9f0ce611b2acf5927a7703a7811081c4adbc3f41
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Bug
===
The arguments of the lambda function might be the same as other
variables in the QWeb. In that case the template rendering will crash.
To avoid this issue, we encapsulate the name of the argument to be sure
it's not the same as other variable in the QWeb engine (so the name of
the argument can no longer make the QWeb rendering crash)
Task-2674716
Closes#78392.
Forward-port of 96b09b127028e5c9a83c89acce86e1b6df904c6f
Change the lang of your user, translate the name of some records (e.g.
translate the "Customizable Desk" product to "Bureau personnalisable")
and create a cron that simply log the name of that record. Schedule the
cron to be automatically executed, check the created log entry (setting
> technical > logging) it is the default english name. Go back to the
cron, click "run now" contextual button, check the created log entry: it
is the translated name.
When they are automatically executed by the cron worker, crons run with a
minimal context without lang. When the user clicks on the "run now"
button his context was wrongly used while executing the code.
Closes#45388closesodoo/odoo#80532
Signed-off-by: Julien Castiaux <juc@odoo.com>
When "Saving" a settings wizard, all its settings are written, even if
not modified.
This implies updating ir.default and ir.config.parameter models.
By verifying whether there were effective changes, we can
avoid:
1) the searches to get the corresponding records from database
2) the cache clear triggered by default/parameter updates/creation
This commit thus reduces the queries triggered when saving settings,
but also the queries of future operations, since we avoid clearing
the ORM cache if not needed.
Part-of: odoo/odoo#62249
The settings wizard provides the implied_group logic to add/remove
implied_groups to an existing group (by default base.group_user).
When verifying those special fields (onchange, default_get and execute
calls), ref is called once by group, by field.
E.g. a field
group_broll = fields.Boolean(implied_group="broll")
will trigger two refs ("broll" & "base.group_user") for each
onchange/default_get/execute call on res.config.settings.
This commit uses the cached method to fetch ir.model.data,
avoiding a lot of queries (depending on the fields defined on
res.config.settings model)
Part-of: odoo/odoo#62249
Following the API for ir.model records, the same logic is provided for
ir.module.module records.
This allows to avoid a bunch of queries when modifying/opening settings.
Part-of: odoo/odoo#62249
At create, the ORM fills the missing create values with the defaults,
calling default_get.
In the case of res.config.settings model, the default_get overrides triggers
a lot of operations to manage its custom field logic (config parameters,
defaults, modules installation, ...).
This slows down the creation (and application) of settings updates for "nothing".
This commit ensures the defaults are not recomputed for fields whose value
was provided to the create call, reducing the effective time of settings flow.
Part-of: odoo/odoo#62249
Consider upgrading module 'base' on a database with millions of 'res.partner' records.
The upgrade of country and country state data makes a very costly search to reverse
the dependencies of the non-stored computed field 'contact_address', just for the sake
of invalidating its value from cache, which is most probably not present at all. The
cost of the search is so high that it may prevent from upgrading the module (timeout).
closesodoo/odoo#80251
X-original-commit: b7f9d0b7c3dfbca0f4897a650983a298da811ce1
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The `ir_import_module` module is used by users to upload custom module
data via a zip file. The zip file can contain xml data, xml views and
static files.
Before this commit, the "import module" feature of this module was
broken since the imported module's manifest was lost after the import
was performed.
Now, 'ir.asset' records are created along with the attachments pointing
to the imported static files.
closesodoo/odoo#80120
X-original-commit: ec77577796e72707fbb2077f05067428cebc3c7f
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
- Get a database with millions of files in the checklist (do not ask how
this happened)
- Set a cron timeout low enough so that `autovacuum_job` times out
The file GC will endlessly timeout without being able to delete any
file.
This is due to how the `_file_gc` method is built: we first build the
whole whitelist, then we perform the deletion. With millions of
checklist files, the loop which builds the `whitelist` takes ages. It
ultimately leads to a timeout of the scheduled action, and therefore no
file is deleted.
To avoid this, we delete the files progressively. The checklist is split
in chunks, and we check which files must be GC'd in a given checklist
chunk. This way the files are removed even in case of timeout, meaning
that there will be less files to check during the next run. Eventually
the GC won't timeout anymore.
closesodoo/odoo#79834
X-original-commit: dbae52479062ace9e2b2d376ec2d601d86482f86
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When detecting if the assets where already preprocessed, the method
only the last asset type matching was returned and deleted.
In standard, it should not have any impact as all assets are of the
same type but it may be possible to mix it with external modules.
Sign CLA
closesodoo/odoo#79786
X-original-commit: 0c2f83f4a6c4603d107007ac77c94e6a2805cd81
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
Purpose
=======
In the `res.users` view, we can add / remove a group of a user with a
simple selection / boolean field.
This trick is done with an override of "fields_get" to return fields
that don't exist, and override the create / write to write on the
"groups_id" when we write on those "virtual fields". So with this trick
we can create new fields in the `res.users` view by just adding a new
group.
So when you write on the virtual fields, it will add / remove a group.
But this implementation will not trigger the on-change of "groups_id"
(because those field do not exist).
With this commit, the "onchange" of `groups_id` field will be triggered
when you write on those virtual fields (and so the computed method
which depends on `groups_id`, e.g. the `share` field).
Task-2508521
Part-of: odoo/odoo#77766
Issue:
When trying to print a Suisse QR bill, if multiple images are presents
in document and they have a url as src, some pictures will not be
displayed.
(Same issue may occur with simple QR code)
Cause:
It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b
Also, adding css class to body by js break wkhtmltopdf.
Solution:
Replace link by base64 image value (use a function to retrieve base64
image instead of image_url).
Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
to this report).
Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
(since generic) to account module.
Move specific logic like `_get_qr_vals` and
`_get_qr_code_generation_params` to specific module (ex: l10n_ch).
extra: Alter some css for better rendering + update unitest.
opw-2620082
closesodoo/odoo#77643
X-original-commit: 699b6eeac993e3a8d97ae7949170f7e18ca05831
Signed-off-by: Olivier Colson <oco@odoo.com>
`assert_log_admin_access` uses the `name` field of `ir.module.module` for logging.
`assert_log_admin_access` was added to `install_demo` method of `ir.demo` in d345fb649e3e3c1bf141dca49b45503b8b3a7164 but `ir.demo` does not have `name` field, hence causing AttributeError.
The proposed solution here is to use `display_name` instead
closesodoo/odoo#79398
X-original-commit: 9d6f54e7f7219cbbda41129e35682f6a76aae1d4
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Raman Obaid Ahmed (raob) <raob@odoo.com>
Only admin users should be able to load demo data, if needed.
This is only possible from the settings dashboard, and thus,
the method could be decorated.
See: c002e2eb37
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following-up to previous commit, this one makes the
`get_translations_for_webclient()` more defensive with regards to the
absence of a `lang` key in the context, rather than relying on callers
to protect it. The rest of the logic was already fine with this.
This allows simplification of the `session_info` logic and removal of
the conditional for `translation_hash`.
Further cleanups in `session_info()`:
- removed a duplicate calls to `session.get_context()`
- removed duplicated resolutions of `request.session.uid`
closesodoo/odoo#79182
X-original-commit: 3eca1a2e58b8c644c0701d33d0c9d0330bdc234f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
In https://github.com/odoo/odoo/pull/78652 a fix was made in the layout
designer guaranteeing that the company_details field followed the correct
address format set by the company. However, this fix didn't take into account
all company data, making some `format_address`es raise a `KeyError`. This PR
fixes that by using the company_date defined in `_display_address`.
Fixes https://github.com/odoo/odoo/issues/78942closesodoo/odoo#79097
X-original-commit: 3cdc770c4966cef88362f8119a96de5501d21b18
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.
Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.
closesodoo/odoo#78966
X-original-commit: 0b4efd37376223806e7ff7273f520b2d17337bc8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Some records have NULL create_date. In that case we get a traceback like
below.
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 259, in _compute_avatar_128
super()._compute_avatar_128()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 62, in _compute_avatar_128
self._compute_avatar('avatar_128', 'image_128')
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 263, in _compute_avatar
super(Partner, partners_with_internal_user)._compute_avatar(avatar_field, image_field)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 39, in _compute_avatar
avatar = record._avatar_generate_svg()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 66, in _avatar_generate_svg
bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp()))
AttributeError: 'bool' object has no attribute 'timestamp'
```
Observed during upgrade request 40906
closesodoo/odoo#78945
X-original-commit: 559d53fd2a0d437fae595dd4700f2607c8de81a8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Xavier Morel