Before this PR:
The only way to neutralize the database is running cli command neutralize
After this PR:
There is a new checkbox "neutralize database" in Duplicate database and Restore database dialog that neutralize the database after duplication/restore.
I also moved the neutralization code to the external module so it can be called also outside the cli .
closesodoo/odoo#122185
X-original-commit: 616740e9d09b3d0376be43ed1489e390f6f5823e
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this patch the naive dsn parser `_dsn_to_dict` would choke
on `application_name` containing spaces or the equal sign.
closesodoo/odoo#122212
X-original-commit: 3573fe0726f8dde1c5714b7d501f6c43d97ce731
Signed-off-by: Fabien Meghazi (fme) <fme@odoo.com>
Current behaviour:
If we add a blockquote in the `website_description` of a product on
the e-shop, we cannot checkout the product. Silent HTTP 400 error
code, due to an exception raised by
https://github.com/odoo/odoo/blob/bf772181933ce5334da35c8368455963b2478399/odoo/fields.py#L1987-L1993
Expected behaviour:
You should be able to checkout products even if they have blockquote
in their `website_description`.
Steps to reproduce:
- Install eCommerce, sale_quotation_builder (issue is present only
after installing sale_quotation_builder)
- On a product, with the website editor, add a `blockquote` to the
description of the product > Save
- In a private browser window, as public user, visit the product on
the e-shop and try to checkout with it.
- Observe there is no visible error, and we do not proceed in the
checkout process.
Reason for the problem:
The exception mentioned above is triggered when there is a
difference between the html content that is saved in the DB and after
sanitization, meaning that someone with escalated privilege saved
the HTML content by overriding the sanitization with
`sanitize_overridable`. In our use case the only diff is the
presence of the attribute `data-o-mail-quote-node` which is removed
after the sanitization.
Fix:
This issue can be resolved two ways:
1) Adding `data-o-mail-quote-node` to the list of save attributes,
meaning it will not be removed during the sanitization process.
Since this is an attribute that we add on `<blockquote>` nodes,
it can be considered safe, just like `data-o-mail-quote`.
2) Remove the attribute sanitization of the `website_description`,
just like it is done in the website_sale module.
Since the `website_description` and `quotation_description` are both
computed from one-another, they should have the same sanitization
level.
I am implementing both solutions, 1) because adding the attribute to
the safe list seems safe in general, and may prevent future
issues of this sort. 2) because it is the root cause of the issue,
since the bug is present only after installation of the
`sale_quotation_builder` module.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3297237
closesodoo/odoo#122154
X-original-commit: 23022144cb1a338db05870b28f17360b92c46a9c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
It's not clear when and how this happened but apparently "headful"
chrome has a built-in background_page for hangouts which appears
before the `about:blank` page in the list of targets, and possibly
appears before the `about:blank` page has opened at all.
odoo/odoo#111422 was tested with chromium which apparently doesn't
have this feature either (or does it?), which probably contributes to
having no idea when it appears.
This feature also doesn't respond to `--disable-extensions`, despite
its url marking it as one:
chrome-extension://nkeimhogjdpnpccoofpliimaahmaaome/background.html
The result was that the tour runner would hook onto the hangouts
target and try to load pages, which it would reject with
`net::ERR_ABORTED`, hence the tours just getting stuck.
Fix by improving the heuristic to find a content page: look for a
target of type `page`, and with the url `about:blank`, rather than
just take whichever tab target is listed first. Requires modifying
`stop` as it can now be called after we've started the browser, but
before we've created the websocket connection.
Also move `--no-first-run` from the headless to the default switches
to avoid Chrome's migration & default browser popup, apparently it
doesn't cause Chromium grief anymore (???). If this turns out to be a
concern, add a condition on the `executable` or something.
closesodoo/odoo#122117
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When passing a very large expression to `literal_eval`, the odoo server crashes.
To avoid this behavior, a limit needs to be set by using the env varaible `ODOO_LIMIT_LITEVAL_BUFFER`.
If the variable is not set, it defaults to 100Kib.
closesodoo/odoo#121882
X-original-commit: 0e4f3ac464b80573b3dab8761dfba54771da0128
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>
Before this PR when a demo data error occurred (and the errors is too big). You could click on the error and a form view appeared. But if the error was too big, the text for module_id and wizard_id were impacted and were way too small to be readable (like a missing colspan). By adding a form view form this specific model it seems to solve the issues.
closesodoo/odoo#122031
Task-id: 3252698
X-original-commit: a7a6887a01491a42c610ee5019cb6d5feba25f7f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
before this commit
When users open the translation dialog for an empty field, and directly update
and save all translations in the translation dialog, nothing will be saved for
backend
after this commit:
these translations will be saved.
opw-3297748
closesodoo/odoo#122008
X-original-commit: ae643ab48b3447f372bfe08fbad7515f370b7cbe
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before this commit:
when en_US is not activated and the user changes terms slightly for
ir.ui.view.arch, the new term will be treated as a typo fix or style change, and
won't be populated to other languages. As a result, in the form view, arch_base
field which displays the en_US translation of the arch_db will still be the
content before the change(wrong and strange).
After this commit:
when write a model_terms field when en_US is not activated, its en_US value will
always be overwritten.
opw-3265418
closesodoo/odoo#122006
X-original-commit: e7fd2361ab83f3a02ada09c18094adc5c7517227
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
Michele