Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
The introduction of Milk has brought new app icons.
Using the svg format creates a lack of anti-aliasing on the edges of the
shapes, which makes the icons look bad.
Since the png size has been reduced, we can afford to use the png format
to have the best possible quality without having a lack of performance.
task-3326633
Part of task-3326263
X-original-commit: e07cb722f2b11407a3ad093bd688b7d37afd5a88
Part-of: odoo/odoo#121886
Since the introduction of Milk, the app icons have been updated.
But before this commit, some of these icons were not replaced in the
list of apps in Community.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 1f6294526675a49acc9c610f59749c82e5a47bef
Part-of: odoo/odoo#121886
This error was intoduced in #121159
The javascript unique should also be based on templates.
closesodoo/odoo#121842
X-original-commit: 2a7c6640357b4d6fc0c539b5d8d5e6dd80882d5b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The function `drop_view_if_exists` only works when the view in question is a
regular view. Here we allow for materialized views to be dropped without any
extra logic added from the caller side.
closesodoo/odoo#121814
X-original-commit: f0db3454bde6759af9aa1b3c2751845a3b2949e7
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this revision, when you pass `context` in the arguments
of a JSON routes, this one gets automatically injected
in the environment context.
This is not the case for regular HTTP routes.
It makes sense to propagate the context for the JSONRPC protocol,
JSON routes used by the backend, such as `call_kw`,
but it doesn't make sense to pass this context automatically
for any other kind of routes, such as front-end routes
or routes used by custom Javascript widgets.
This change brings a more unified behavior for routes
of types HTTP and JSON.
In addition, most developers were not aware of this "feautre",
that passing `context` in the arguments of a JSON route leaded
to the injection of this context in the environment context.
This is actually reflected by the diff size this changes required,
only a dozens of routes needed to be adapted, to manually
add the context in their route arguments and to inject it
in their environment context.
closesodoo/odoo#121726
X-original-commit: a7a5655631e6d5b05fd2ba3d0c80617aae6d9cfe
Related: odoo/enterprise#41229
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
when the user did a mistake in any view from UI, like missing the closing tag or
did any syntactical mistake in any view (standard or custom view) during that
time XMLSyntaxError is generated. Instead of traceback we can show
ValidationError to User.
Steps To Produce:- (This is only for example)
1) install 'industry_fsm' and make debug mode on
2) Go to 'Project', Open any Project
3) Go to debug mode > Edit View: Kanban
4) remove the 'closing tag' of the 'attribute tag' and try to save.
The error will be generated.
Applying these changes will resolve this issue.
sentry - 4157344102
closesodoo/odoo#121855
X-original-commit: ff6bfbdfd6eaf994e4ceca2cf8770301602c5650
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently when a QWebException raise Exception which will be caught by sentry
and causes unnecessary traffic.
So, we stop catching QWebException which are supposed to be generated by User's
Mistakes.
sentry-4137969310
closesodoo/odoo#121841
X-original-commit: 2859143c9b2950578385b66126178f27db750863
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Smit Nagar (smna) <smna@odoo.com>
The Weakset Used for envs can lead to unpredictible behaviour when
calling flush on the transaction because we iterate on the `envs`.
Since WeakSet.data is a set, the iteration will depends on the python
hash seed.
This commit proposes to replace Transaction.envs.data by an OrderedSet
to solve this issue.
Some test demonstrates that it does not affect the garbage collection
and that the order is now deterministic.
The question to now if we should reverse the envs to find the most
suitable envs remains.
closesodoo/odoo#121604
Signed-off-by: Raphael Collet <rco@odoo.com>
Delegate the property's resolution to a top-level function,
cached (with a single slot). This is slightly less efficient than
using some sort of global set once, but it's much easier.
Unlikely to be a huge issue in the face of *starting an entire
browser*, but may as well skip it.
closesodoo/odoo#111422
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It doesn't need to store so much crap as attributes, and the data flow
of the init can be made more explicit.
- have setup functions return stuff, which can be set on `self` by the
`__init__`, making the dataflow more explicit
- maintain a high-level `Popen` object instead of moving a `pid` around
- pass items like browser size as parameters instead of attributes
- remove redundant attributes like `screencasts_frame_dir` (/ convert
to properties)
Part-of: odoo/odoo#111422
Chrome's screencast / remote view (in the remote devtools) is
apparently *designed* for touch emulation /
simulation (https://crbug.com/1410433), which is not convenient when
trying to debug mouse-bound issues in a tour (e.g. drag&drop
problems).
However we can "simply" run the thing in a normal browser, on a watch
basis, and shut down the entire thing after each tour-call. This also
obviates the need for complicated cleanup steps to try and isolate
tours (as we can just delete the profile the browser created),
although it is somewhat less efficient as we keep starting and
stopping the browser.
It does simplify the result of merging `clear` and `stop` (into stop).
The switches setup does have a few foibles:
- `--no-first-run` causes tours to not run at all on my machine, in a
non-headless browser, so it's left just for headless
- also moved a bunch of other flags which seem to be mostly for
automated annoyances to headless only
- left extensions for now, not entirely sure which is the right one,
since we're running with fresh profiles I would assume there's no
extensions anyway
Part-of: odoo/odoo#111422
One of the most costly part of a page loading when the ormcache is cold
is computing the assets node, the unique identifier of an attachment to
validate whether the existing attachment is still valid with the current
version of the static files.
This operation needs to glob assets path in the filesystem,
get the modification date, check attachments, ...
Right now this task is not really optimized and can take some time
because of an excessive number of glob on the filesystem, unnecessary
exists to define absolute path, double computation of file list and
modified times when getting js and css bundle separately, ...
A list of modifications mainly discussed in the pr message are made
with this commit to speedup things.
- split css and js unique
- prepare api for an in memory glob
- change api to propagate absolute path and meta information through
`ir.asset._get_paths`-> _get_asset_paths -> `_get_asset_content` ->
`AssetsBundle`
closesodoo/odoo#121159
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since the "dirty flag" refactoring of
384fda2c2a
`IrModelFields._prepare_update` did not cope well with fields missing
from the python-side models, which can during uninstallation for
custom fields (possibly because the script loads the registry
incorrectly, not entirely clear).
Because of a custom field created by worksheet linking to it, the
removal of the `project.task` table would fail, making the
reinstallation of project fail to restore several constraints.
This case was actually handled correctly just a few lines above when
trying to resolve field dependencies, both record and field would be
checked for their presence before actually trying to use them.
Getting the model from the registry / environment has not been noticed
to break uninstallations, but might as well do that too so everything
lines up, and just in case.
X-original-commit: 05aca6ee4ce795b85b90430efd761f0cd3a6d5a3
Part-of: odoo/odoo#121522
Issue discovered in the uninstall (and reinstall) of sale_project: a
dump has ~100 tasks, when reinstalling `sale_line_id` has to be
initialised, this is done by marking `sale_line_id` on all extant
tasks as to-recompute, which triggers their computation on the next
`flush`.
Because it's a recursive field, `Field.recompute` ensures only one
record at a time gets recomputed (as there could be cross-dependencies
in the recorset which protection would prevent from resolving).
As the field computation runs, it accesses itself, which triggers a
cache miss, which triggers a `_fetch_field` (to get the currently
stored value), this calls `_read`, which flushes the field we're
trying to read.
The problem here is that for efficiency the cache miss will look for
all records in the cache without a value for the
field (`_in_cache_without`) and try to `fetch` on them as well. This
means rather than not doing anything in flush, we're going to
`Field.recompute` on all records except the one selected the first
time around, which repeats the cycle until there is no more additional
record found in `_in_cache_without`, which could trigger the next
round of `recompute`, and the entire thing unwinds, and we probably
perform a ton of unnecessary additional `compute_value`.
Except that doesn't even happen, because the process from one compute
to the next takes 12~13 stack frames, which given the default
recursion limit of 1000 gives a hard limit of 76 fields before hitting
a RecursionError. As this is less than 100, a recursion error [is what
we get](https://runbot.odoo.com/runbot/build/31726625).
In 15.2, this was fixed by only expanding the fetch on non-recursive
fields, pessimizing recursive
fields (5c2511115b14299516fce4aa3737a62faaf5b653). Test-wise this only
impacted mail performances and in a relatively minor manner.
In 16.0, the mail tests actually match already (so that part was
skipped by the cherrypicking) however this impacts the knowledge perf
tests much more significantly e.g. `test_article_creation_multi_roots`
gets +9 queries when creating 10 top-level articles, which is a bit
much.
So use an alternative which is ugly as hell but which I didn't
consider for 15.2 (may want to backport it one day if the current fix
is an issue): catch the recursion error and use the existing
fallback (of fetching just the requested record's field without
expanding the recordset).
This likely makes for a pretty inefficient situation in the original
case as we're certainly going to hit the recursion limit repeatedly,
but that still fixes the issue, and it avoids deoptimising cases which
fall short of the recursion limit (resolving under 60 records or
so).
Plus despite creating giant stacks we might actually get good
efficiency as we're going to hit recursion limits repeatedly but
that's pure python, once we fall below the limit we can resolve
everything at once with a single SQL query (or something along those
lines).
X-original-commit: 9e71094582ec4c9b719431e77538da8f91ffa9e3
Part-of: odoo/odoo#121522
Uninstallation does not cope well with `setup_models` being performed
unconditionally as those will dramatically alter registry states, and
resurrect computes which the uninstallation has disabled: rather than
try to update registry models in-place (which is rather fraught) the
uninstallation deletes the columns, tables, and `ir.*` reflection
records and only after all of that is done does it reset the registry.
This means while it does fix up the registry caches (`field_depends`
and `field_triggers`) as it goes, resetting those may cause the
recomputation of fields whose columns have been deleted, possibly
based on dependencies whose columns have also been deleted.
As such these kinds of manipulations should either be performed in
`@ondelete` methods which don't get executed during uninstallation, or
they should be gated behind an uninstallation check.
In crm the latter is necessary, as `ondelete` runs before `unlink`
actually executes, and the registry reset would run too early (and
unnecessarily).
In base, only the latter is possible as we're not in `unlink` itself,
instead `IrModelFields._prepare_update` is called *during*
uninstallation and its trailing `setup_models` causes the issue.
X-original-commit: 357b9f2c9fd44e14e5b7c9d3c17f1794691986f3
Part-of: odoo/odoo#121522
Confusion between uninstall hooks can apparently trigger errors during
uninstallation as two hooks can confuse one another?
In this here case, the issue triggered during the uninstall hook of
`account_accountant`, which apparently combines with the uninstall
hook of `industry_fsm_sale` to trigger an invalid in-memory state for
`project_project`. An implicit flush during the hook then blows up
with a check constraint error.
Flushing at the end of the `industry_fsm_sale` hook or at the start of
the `account_accountant` hook fixes the issue, so might as well flush
after each hook to ensure whatever they did using models is pushed to
the database and in good shape (hopefully).
X-original-commit: b28e9a7066d29d395421a11df2b9e170fb20d35a
Part-of: odoo/odoo#121522
To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised
Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server
Solution
========
catch `TypeError` to raise a UserError
opw-3285540
closesodoo/odoo#121313
X-original-commit: 5053620c640136025f5b37c5b8d233ad63825389
Signed-off-by: abla001 <abla@odoo.com>
When inside an HttpCase, the end of a successful request will
`signal_changes` meaning that the registry_invalidated flag is removed.
A second issue is that this flag is thread local meaning that if a
request set the flag, it won't be visible from the test thread.
For those reasons, this commit ensures the registry sequences are
incremented as in production mode, and adds a check that the sequence
didn't change during the tests, calling `setup_models` the registry
manually if needed.
closesodoo/odoo#121268
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.
Bonus point: tests no longer need to be imported in the `__init__.py`
file.
closesodoo/odoo#121453
X-original-commit: ed1b27dbdfc0a5084051c59da9c4578262b3bf8c
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.
closesodoo/odoo#121396
Sentry: - 4075426049
X-original-commit: ac2a3966cb035f112bf6aebb1244dc8d67831d1a
Signed-off-by: Rémy Voet <ryv@odoo.com>
* = account, sale
This commit allows users to modify the panel image for the
onboarding steps. This is especially necessary for additional
onboardings that can be/could have been created, or if the
appointment onboarding was modified, as it was chosen to not
overly complicate the upgrade and simply not modify these records.
We also customize the placeholder icon to be one of these icons
instead of the default "camera" image.
Finally, a few icons are renamed to be more generally usable.
closesodoo/odoo#121349
Related: odoo/enterprise#41031
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
This commit fixes the ribbons used in `kanban` and `form` views.
The SCSS uses the square root of the parent `div.ribbon` to calculate its
diagonal width and applies that width to the child `span`.
After changing the ribbon's transform-origin, we calculate the ribbon's
position based on CSS variables of the view's top padding,the height of
the ribbon and the shadow's size (to avoid it being cropped by
overflow-hidden).
By changing the values of a few of these variables in the kanban view,
we were able to remove all the specific SCSS related to ribbons in the
modules.
Other changes were applied inside some of the modules to make this
work:
- `event`: padding corrections on the kanban's cards;
- `hr_holidays: replaced `margin:0` in the SCSS with negative margin
utility classes on the element to achieve the same visual result;
- `discuss`: moved the ribbon to the parent element;
- this was also done to `discuss`, `survey` and `helpdesk`;
- `crm_team_view` in `sales_team`: the ribbon's height made it overflow
from the kanban's card. We fixed this by changing the value of one of
the CSS variables in the view's SCSS file;
- the same thing was done in `survey` and `appointment`;
- `website_event_exhibitor` had some SCSS that wasn't being used because
it uses `.o_ribbon` instead of `.ribbon`
task-2818586
Part-of: odoo/odoo#116641
*: onboarding, account, account_payment, sale.
Currently used in the appointment module (See c1cf8bfb).
Related Task-3297572
task-2818586
Part-of: odoo/odoo#116641
This just sets a dummy VAT number for all the demo partners
We need to access the demo partners vat number in
l10n_es_edi_facturae, and overriding data in the
other module could lead to different behaviours in
the future
Task: task-2793440
Part-of: odoo/odoo#108350
*: base, web_editor
The Many2oneUserValueWidget does not allow the user to reset it
to blank if it already contains a selection. This commit makes it
possible to select an empty value by specifying a `null_text` option.
task-2406626
Part-of: odoo/odoo#67913
mimic what is done for `odoo.addons` __path__.
closesodoo/odoo#121211
X-original-commit: 2a981e6a561f572742202d9c964d3b1f3aecacf9
Signed-off-by: Christophe Simonis <chs@odoo.com>
In https://github.com/odoo/odoo/commit/6371565e6933d6ede88fa85992f4acbc2cb5327b we expect required fields to throw ValidationError when not set,
we thus correct res_partner to raise that error when the email is implicitly
required, so after this commit if we can try to create a new partner from the
name directly then It will give a validation error and wizard will open for the
creation of a new partner.
Task-3297388
closesodoo/odoo#121127
X-original-commit: 98aca8f76f7509b143263100384a2f2ed644124b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The assets bundle system allows to generate `<script>` elements whose
resource is meant to be lazy loaded. In that case, a "data-src" is used
instead of "src" directly as attribute. This is valid HTML code: "src"
is not required. However... this lazy loading system also automatically
added `defer="defer"` which makes the "src" attribute required, thus
failing W3C validation.
Now, we only add "data-src" and the `defer="defer"` part is added on the
client-side, once the "data-src" is switched to "src". Note that this
"defer" attribute may not be needed in this case at all, but it cannot
hurt.
Part-of: odoo/odoo#120311
Since 16.0's 0501bbd62e fields with groups are now removed from the view
instead of being set as invisible.
Scenario:
- template user has group "Access to export feature"
- create a new user while being in debug=0 mode
- save
=> the users don't have the group "Access to export feature" set,
because the corresponding field is not in the view. If the same scenario
was done in debug=1 mode, we would get the group set.
Solution: duplicate the field that are inside base.group_no_one section
and have them be invisible if someone is not in debug mode.
note: before the fix, added assert fails because there is missing groups
in the newly created user.
closesodoo/odoo#121097
Note: issue observed when working on another ticket
X-original-commit: 9deb1e6aa902a09c4fd6a91ecbd34a89b9c98f98
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, the date/datetime/daterange fields only allowed for
an optional end date field. This meant that the primary date was always
the start date.
This commit allows the field to do the opposite: with the primary date
being the end date, and having a `start_date_field` option for an
optional start date.
closesodoo/odoo#120695
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit introduces a "_is_portal" method complementary to the existing
"_is_internal" and "_is_public".
The goal is to ease usage through the code base and be able to easily
distinguish our 3 main use cases: public, portal and internal users.
Task-3056280
closesodoo/odoo#120827
Related: odoo/enterprise#38575
Related: odoo/upgrade#4575
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When generating the routing map, `Rule.add` will call
`Rule._compile_builder` twice, representing almost one third of the
routing map generation time. `_compile_builder` is actually stored
in `Rule._build` and `Rule._build_unknown` for latter use, in the
`Rule.build` method.
The `Rule.build` method is used to transform a rule, lets say
`/forum/<model("forum.forum"):forum>` in `/forum/basics-of-gardening-2`
Even if a deeper investigation could be interresting, it looks like it
is only used for `is_frontend_multilang` routes and `_enumerate_pages`,
used in the `sitemap` and `search_pages`.
The proposed solution si to make this part lazy, in order to call
_compile_builder on demand, once per rule. This will speedup the initial
routing map generation and postpone the heavy work when we need it,
only for the part we need most of the time.
On a database with all modules installed, generation of the routing map:
Before: ~600 ms
After: ~200 ms
An alternative implementation was also overriding the Rule.build method
instead of having a callable LazyCompiledBuilder, this implementation
was choosen since it is less dependant off the werkzeug implementation.
closesodoo/odoo#120542
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`re` is using an internal cache for regexes with a default size of 512
This is correct for small apps running on small infrastructure
but as a simple example, the routing map will compile ~1100 regex in a
row. This means that generating two routing map in a row don't benefit
from this cache at all. It looks reasonnable to increase this limit
globally for odoo.
This is visible when generating two routing map in a row.
After this change:
Generating routing map for key None
Routing map web generated in 0.194s
Generating routing map for key 1
Routing map website1 generated in 0.196s
After this change:
Generating routing map for key None
Routing map web generated in 0.200s
Generating routing map for key 1
Routing map website1 generated in 0.062s
Part-of: odoo/odoo#120542
Before this commit: if you add a custom one2many field to the
'res.partner', like x_related_commercial_partner_ids, that is related to the
`commercial_partner_id` in the`res.partner` model, it won't update the
display name of a contact in case of changing its parent_id name.
Here are the steps to reproduce the problem:
1. Create a new custom field with these values:
a. Field Type = one2many
b. Model = Contact
c. Related Model = res.partner
d. Relation Field = commercial_partner_id
2. Create a new Contact that is the "Company" (e.g. "My Company")
3. Create a new Contact that is the "Individual" (e.g. "My Name"), and
put the "My Company" as its parent_id.
4. Now the display_name is "My Company, My Name" which is correct
5. Change the company name to "My new Company"
-> display_name won't change, and is "My Company, My Name"
The solution is to add the 'commercial_company_name' to the
`display_name` depends.
opw-3202894
closesodoo/odoo#120908
X-original-commit: f242cad9a27fb0e58e1b9c726573b316534f6be8
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If applied, this commit will handle the KeyError: res_id when the user tries to
import the translation of .csv file in settings -> translations, and if .csv
file doesn't have the res_id column.
I handled the traceback by changing the logger level to warning.
sentry - 4049419481
closesodoo/odoo#120904
X-original-commit: f5b69559a04cad9a693b991497936cf11ca36aeb
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
To reproduce the issue:
1. Install `mrp`
2. Send a RPC to create a new BoM:
- `{"product_tmpl_id": 1, "product_qty": -1}`
Error: It will generate a traceback
Because of the negative product qty, the RPC triggers a SQL constraint
that we try to return. However, the context does not have any `lang`,
hence the traceback
sentry-4088426130
closesodoo/odoo#120614
X-original-commit: badc554b9dd7a299aac8ebca24bec6b90bef779a
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Brieuc-brd