The profiling tools can be useful to profile a test of some execution
point but this is not convenient to identify a problem on a running
instance.
With this commit, an option available in the debug menu allows to add a
flag on the user sessions to enable profiling of all requests. Each
request will be saved in a different 'ir.profile' entry, but will be
grouped under the same session.
The profiling can be activated on all sessions, even for a public user,
but only if profiling is enabled on the database globally.
This commits also adds a speedscope view to visualize saved results in
the web client.
closesodoo/odoo#66590
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit adds tooling to profile performance and save execution by
saving stack traces and queries to a file/database in specific format.
----------
Collectors
----------
For now, three different profiling modes (aka Collectors) are available
even if a last once should be introduced by @Gorash to profile qweb
execution.
- SQLCollector (or 'sql'): Saves the current stack trace and the query
every time Cursor.execute() is called. Any query executed on the thread
will be collected, no matter the cursor.
- PeriodicCollector (or 'traces_async'): Saves the stack trace every
'interval' seconds using a parallel thread to profile the caller thread.
The python implementation was optimized to minimize impact on
performance while remaining portable and easy to enable/disable
inside a odoo execution. Higher the frequency (lower the interval),
more impactful the profiling will become on the execution and increase
memory usage. From last experiments, 1ms looks to be a good minimum for
short executions.
- SyncCollector (or 'traces_sync'): Saves the stack trace every function
call/return. This collector is obviously quite impactful on performance
and can quickly overload the memory for long executions, but this is
quite useful to understand the precise path followed by some short
executions. Any time related information will be almost irrelevant with this
collector.
A base Collector defining minimal collectors features can easily be
extended to create custom collectors if needed.
----------------
Profiler & Usage
----------------
Collectors are not supposed to be used by themselves, but should be
given to a Profiler. The Profiler will synchronize collectors starts and
stop, and manage saving them to a file of in a ir_profile in the
database.
Exemple of usage:
```
with Profiler():
do_stuff()
```
This simple example will use the default collectors (sql and
traces_async) and save them to the database. The database is defined
automatically from current_thread 'dbname' if available.
Example of usage:
```
with Profiler(collectors=['sql'], db=False, path=/home/user/logs/do_stuff_profile/{time}):
do_stuff()
```
This more complex example disable the default behavior consisting
to save to the database, gives a path where the profile will be saved
and specify to only use the 'sql' collector. Note that
collectors=[SQLCollector()] would have the same behavior since
Collectors can be either a Collector instance or a string describing the
desired collector. This allows to define custom params for the
collectors and use custom collectors if needed.
Note that it is always possible to get results after execution without
saving it since they are available on the profiler.
```
with Profiler(collectors=['sql'], db=False) as p:
do_stuff()
print(len([None for entry in p.collectors[0].entries if ...]))
```
Profiler will also save the stack below the profiler start point, and
collectors will only collect the part of the stack over this stack.
This is a good way to reduce collectors CPU and memory usage.
Collected entries will be saved as follows:
```
[{
'start': 2.0,
'context': {},
'stack': [
['path_to_file', lno, 'func_name', 'line_content'],
...
],
},
...
]
```
SQLCollector will add three additional keys on each entry:
- query (query without parameters)
- full_query (mogrified query with parameters)
- time (the 'exact' execution time of the query)
----------------
ExecutionContext
----------------
A last tool, ExecutionContext, allows to define some context on some block of code:
Example of usage:
```
def process_modules(modules)
for module in modules:
with ExecutionContext(module=module): # note the 'not linter frienldy but still convenient' 2 spaces indentation
do_stuff(module):
```
This context will automatically be added in the stack as a virtual frame between
process_modules and do_stuff in order to split do_stuff from one single frame to
one frame per module.
----------
Speedscope
----------
The saved data are in a simple json format easy to analyze, but can't be visualized in
speedscope as they are. A utility class `Speedscope` can be used to generate a format
readable by speedscope. The used format is actually the format defined by speedscope,
meaning that all features should be available using it.
The output format is evented, meaning that we need to transform a list of samples
(a list of stack) to a list of event (going in/out a frame).
This is the main task of the Speedscope, as well as combining samples from different
sources, to display SQLCollector and PeriodicCollector results mixed together.
When stored on an ir_profile, the default speedscope generation can easily be generated
with the speedscope computed field.
This class can be used as it is but will mainly be useful for the next commit.
Special thanks to @rco-odoo for the in depth review and @Gorash for support.
Before this commit, `get_base_url()` could not be called on an empty recordset.
It might be called on an empty recordset for instance when getting the paypal
payment endpoint URLs.
This commit allows that and returns the ICP value in that case.
The goal is to always use the util method `get_base_url()` instead of directly
accessing the ICP.
closesodoo/odoo#68201
Related: odoo/enterprise#17538
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In order to be able to add a button to activate contextual merge action on the
target model, the ir.model form view had to be adapted to add the header.
Task ID: 2459416
ENT PR: odoo/enterprise#16975
PURPOSE
Have an overview of the current status of a project and keep track of its progress. Share with other stakeholders where the project stands. Identify risks and opportunities and act on them accordingly.
SPECIFICATIONS
1) Status in controlpanel + access rights
- Indicate the status of the project next to its name in the controlpanel clicking on the status should open the updates kanban-list
by default, the status should be 'on track'
- users with the project > user access right level can see the status of the project
- users with the project > admin access right level can read, write, create, delete updates
2) Project Updates
- Project updates are defined with a name, Author, date, progress and description.
- The description is build based on project data, timesheet related to project and project profitability.
3) Project Updates Kanban View
- The kanban is a kanban list view with a right side panel.
- The right side panel displays various information about project
- It's possible to create milestone from the project update right side panel.
4) Project form view
- The milestone and update lists are accessible from the project form stat buttons
task-2393768
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#68899
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
This commit aims to add a button in the control panel to easily display
the current project update status.
This is done by extending ControlPanel Component and template.
We must add a context value `show_project_update` to enable the
button in the breadcrumb and it's done only once; e.g. when we click to
see all project tasks of an active project.
The button redirects to a kanban list view of the project_updates.
The activity rng is modified in order to accept js_class definition.
Following commits will add behaviour to handle those updates and
milestones in the various views. See PR for further information.
PR : #68899
task-2393768
When invoking onchange() on a line in a one2many field, the inverse
many2one field is given as a dict of values. Those values are the ones
of the "container" record in the form view, and they include the "id" of
the container record. The method onchange() instantiates the container
record as a new record with the given values. Fix the code to set the
expected "origin" of that record to the record with the given "id".
closesodoo/odoo#71491
X-original-commit: ebfb5d90fd4ff65ee1d2fc73faf8f9eaa18f4521
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
`./odoo-bin -h` prints unnecessary spaces between sentences.
---
task-2431630
Finetuning of #71130closesodoo/odoo#71364
X-original-commit: fcc60e219fd024394f8642509a20755f964546b6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.
```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1
In [2]: import odoo.addons.base.maintenance.migrations.util as m2
In [3]: m1
Out[3]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [5]: from odoo.addons.base.maintenance.migrations import util as m3
In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [7]: m2 == m3
Out[7]: True
In [8]: m1 == m3
Out[8]: False
In [9]:
```
Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.
```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2
In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```
closesodoo/odoo#71351
X-original-commit: 0d0458a0f370f872caacac26361f2c4730c2cbba
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Steps:
- Install Website
- Go to Website
- Click "Go to Website"
Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.
Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.
Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf
opw:2530388
closesodoo/odoo#71303
X-original-commit: 5a047574dde6b207697244c866749d3cd439922c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit the PyInotify filesystem watcher used by the code
autoreload feature (`--dev=reload`) would not get a chance to free
it's inotify watches before the reexec, hence at each reexec triggered
by a code reload the inotify watches where accumulated until potentially
reaching the kernel limit `fs.inotify.max_user_watches`.
This patch ensures that inotify properly closes it's file descriptor
before we reexec:
https://github.com/dsoprea/PyInotify/blob/f77596a/inotify/adapters.py#L79closesodoo/odoo#71302
X-original-commit: 8703ff1e3d9be6f2f5fce2e8c4e62589b05133fb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').
To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:
assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])
The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404
fails, therefore the result of `filtered_domain` is empty.
Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.
Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`. Then
b1.filtered_domain([("friend_id", "child_of", b1.id)])
throws an exception of the form shown below:
ValueError: Invalid field 'parent_id' in leaf "<osv.ExtendedLeaf: ('parent_id', 'child_of', 1) ...
Meanwhile the following code is still valid and returs b1:
B.search([("friend_id", "child_of", b1.id)])
closesodoo/odoo#71237
X-original-commit: e7a5ba95d8b7df5bbf545ef8afe0a1f5d0f70272
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently, clicking on the "upgrade" button from Apps in community
opens the corresponding page in the same tab. As a consequence, the
user completely leaves his database and it can quickly become tedious
to get back to it.
so in this commit, clicking on the 'upgrade' button should open the
corresponding webpage in a new tab
closesodoo/odoo#70636
Taskid: 2513785
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
In `prepend_html_content`, if body `html_body` and `html_content` are
`Markup` objects, the processing of `html_content` through `re.sub`
will strip away the `Markup` flag, leading to the later concatenation
of the body and content first escaping the content (to safely convert
it to a `Markup`) before performing the concatenation proper.
As a result, the `preview` of a `mailing.mailing` would be
double-escaped, and the markup hiding it would instead be printed as
part of the body.
Assume that the type of `html_content` is str-compatible, and
immediately rewrap the value after processing it through
`re.sub`. This should do nothing if `html_content` was an actual
`str`, and will re-flag it as a `Markup` if it was one.
Also change the finding of the insertion point to use `re.search`, I
don't understand why this uses `finditer`, it just makes the code more
complicated.
closesodoo/odoo#71090
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As part of the Python 3 compatibility effort,
01e3514147 moved all uses of urllib(2)
to werkzeug & requests as the packages were renamed and reorganised
between P2 and P3.
For `module.py`, it looks like I confused the `urls` local variable
for an already imported `werkzeug.urls` and just tried calling
`url_parse` on that. Which doesn't work, because `urls` is a
dict.
Fixes#71076closesodoo/odoo#71120
X-original-commit: 0cfe528de82c1de8971e5bb5f66103447eae781c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Make the email body take the entire space to avoid having some wasted space,
this will also make the user have more focus when designing an email.
Revamp the settings notebook page in order to give more clarity to the user,
and move some fields from the main form have been moved to this section to
have more space in the bottom for the email body.
In the mailing form, when the mailing is sent or is being sent, set fields
which are no longer useful for the user to change to readonly mode.
Add a wizard that enables the user to schedule a mailing, the schedule field is
still kept in the form for the user to be able to change the date when the
mailing is in the queue (if they want to send it sooner).
Display an action helper-style content when the email is empty, because,
currently, the user is left with a big white screen when the email has no
content which is not desirable.
Update the html_empty function to take into account style attributes to better
match the editor's void content.
Hide A/B testing fields from SMS mailing form view as these are not supported
for SMS marketing.
Task-2469409
closesodoo/odoo#68882
Ent-pr: https://github.com/odoo/odoo/pull/68882
Related: odoo/enterprise#18391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.
PURPOSE
to update the definition of any many2one on which we applied a 'selection'
widget, and instead use the standard many2one widget with disabled
opening/creation instead.
after this commit,
for each many2one field defined with widget="selection", widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"
Task : 2476488
closesodoo/odoo#68387
Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Manually adding a line should not trigger the computation of the field,
just like modifying the line fields that occur in the field's domain.
In other words, the dependencies of the field should be limited to the
ones declared on field or its compute method.
closesodoo/odoo#71049
X-original-commit: 1c39814bd729cc08882f1545c7d88b0592e63f9a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When there is a materialized view that has not been populated any select
on it will fail.
Example of traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
```
Several upgrade requests have or had had this error which has been
solved with specific scripts.
Related to #40930closesodoo/odoo#71008
X-original-commit: b208570ce8399bc6d3e4a8ba02eef6558e0a6ccc
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closesodoo/odoo#70980
X-original-commit: 08a561505b92d23c4c4ec4094b0cee209ece8753
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.
Now, the content of the binary is cropped to
20 chars as it is useless to log more.
opw-2527629
closesodoo/odoo#70740
X-original-commit: 0ed46ae94b20b30c10025b2a458e1ecf92c2712d
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The "Starting job X" and "Job X done" logs are very useful to monitor
cron executions over time, or to detect a cron job that has been running
for a long time.
Those logs were dropped by mistake in #62124 - this patch restores them.
closesodoo/odoo#70921
X-original-commit: 0db99a9fb00465266485c7f6c8d16760250152df
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Use `frozendict` for dicts that often remain empty on models, like
_inherits and _depends, and also make `frozendict` more compact in
memory.
On a registry with 296 modules, this saves 635 kilobytes of memory,
which is about 6% of the registry's memory footprint.
closesodoo/odoo#70402
Related: odoo/enterprise#18142
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This makes the union of many dicts into a single dict.
On a registry with 296 modules, this saves 300 kilobytes of memory,
which is about 3% of the registry's memory footprint.
This keeps field.__dict__ as small as possible.
On a registry with 296 modules, this saves 40 kilobytes of memory,
which is about 0.35% of the registry's memory footprint.
This mainly keeps field.related's type consistent.
On a registry with 296 modules, this saves 325 kilobytes of memory,
which is about 3% of the registry's memory footprint.
This avoids a call to __init__() which no longer has access to the
model's class' parent classes, and was not even correct...
closesodoo/odoo#70400
Related: odoo/enterprise#18141
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The base classes of models in the registry are modified when models are
extended by inheritance. But modifying cls.__bases__ is a costly
operation, so we manage to do it once per model when loading a registry.
Our benchmark consists in loading a registry with 296 modules. The net
time to load the registry is 25% smaller. In other words, the registry
loads 25% faster. Note that the time does not include the time to load
modules themselves, which does not change.
Bug
===
1. Create an event which allows track proposal
2. Follow it and subscribe to "New Track"
3. Log in in incognito and submit a proposal
The email is not sent, because it's sent as the public user, which has
no email address set. And so it the 2 system parameters
<mail.catchall.domain> and <mail.default.from> are not set, we can not
know which email address used to send the email.
Note that this bug also occurs if you create a track with a user without
an email address set.
Task 2510181
closesodoo/odoo#70627
X-original-commit: 45ffab08a7c1dacc70d331077198f92884b53646
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, empty help content are not properly added so in this
task add the proper help content on several menu and add module
field service in community.
So in this commit done the below changes:
- Task form view: change the tooltip of the sale_line_id field
- Change the empty help content in below menu:
- reporting > tasks analysis
- Configuration > Stages
- Project > Reporting > Project Costs and Revenues
- base: The industry_fsm module should show up under Apps in community,
with the usual 'upgrade' button
closesodoo/odoo#68940
Taskid: 2465012
Related: odoo/upgrade#2369
Related: odoo/enterprise#17548
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Currently, in the res.company form view, name field
is extremely short.and in mobile view name field
is hidden by other element because of placeholder
is too long.
after this commit the length of name field is should
be as long as the res.partner one and change the
placeholder (e.g. My Company) instead of (e.g. My Awesome
Company) for idle mobile look.
closesodoo/odoo#70241
Taskid: 2520268
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Currently all menus are out of order in app switcher.
- For example, Sales app is 16 menu away from Accounting,
Social Marketing app is 25 menu away from Email Marketing, etc.
So, all menus should be reordered.
- This commit will reorder the menus of the app switcher in order to reduce
the distance between correlated applications,
and bring the most common apps upward.
- And in this commit we have left gap of 5 subsequent sequence for further new menus.
PR: #69984
TASK ID: 2513082
Related: odoo/enterprise#17989
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Have in a purchase order a first row with unit price 0
Export the PO adding unit price in the list of fields to export
The unit price is not reported
This occur because the first line of the order lines is meld with the
purchase order line but in the process the 0.0 values is discarded
opw-2510917
closesodoo/odoo#70368
X-original-commit: 242bf5024ce6ae9c32176cd1a65a4f57a242dd45
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This commit allows using ESLint on the code JS to disallow undeclared
variables (no-undef) and disallow specific global variables
(no-restricted-globals) (error, event and self).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
When a registry is loading, if a custom field cannot be set up, it will
be removed from the dependencies of the field 'display_name', which do
not exist yet on the registry. This patch makes sure that the dict
registry.field_depends always exists, even as an empty dict.
closesodoo/odoo#70373
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
The only purpose of the module `test_documentation_examples` is to test
a few of the code examples shown in the developer documentation.
As d4ba3117524 removes the documentation sources from the repository,
the test module is removed as well.
DOC PR: https://github.com/odoo/documentation-user/pull/945
task-2352371
closesodoo/odoo#70256
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Xavier-Do