The linter would miss / fail to warn on injection of *local variables*
in some cases.
Try to improve it to be stricter and more reliable, after discussion
with odo, sql which is "correctly" dynamic should use psycopg2's sql
package in order to bypass the linter (bonus: it should also properly
escape & quote identifiers).
closesodoo/odoo#53938
Related: odoo/enterprise#11718
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
These field combinations [1] are actually secondary keys. They are
unique and represent the record identity.
Marking them as modified had a nasty side-effect: on some models, there
is a m2o to an ir.model and a stored related to ir.model/model that will
be recomputed at each model reflection. This can take some time on big
tables.
Moreover, some other stored fields may depend on those ir.model/model
related store, which adds useless time lost at recomputing unchanged
values.
[1] ir.model/model, ir.model.fields/{model,name} and
ir.model.selection/{field_id,name}
closesodoo/odoo#54126
X-original-commit: db013a01ca4e10640ac33a59466c9cb5746e3698
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
This intend to enforce specifications and improve readability
Layout changes:
* [FIX] Amount section must be placed under the QR code
* [FIX] Don't display empty additional information
* [FIX] Rename slip sections and labels
* [IMP] Rework of the layout
Group content like adresse by removing line spacing
Reduce character size to follow Swiss Implementation Guidelines QR-bill v2.1
Reduce left margin to avoid overlap of spaced ISR reference on the Receipt
* [FIX] Missing street on Receipt
* [FIX] Add thousand separators
Official specs asks for:
- thousand separators as blank. (using a non breaking to avoid spliting the amount)
- decimal separators as a full stop
> If the amount isincluded in the Swiss QR Code, then it must be printed after the currency code. A blank (space) should be used as the thousands separator and a full stop «.»as the decimal separator. The amount must always include two decimal places (e.g. CHF 1 590.00).
QR-Code:
* [IMP] Align QR code upper and improve accuracy of size
Add an option on reportlab to print QR Code without surounding blank space
this is required to compute with accuracy the width of 46mm x 46mm defined
in the specs.
* [FIX] Street and street2 issues
Removes an extra space between street values when only one is given.
Test the right partner street, only the company street was checked.
QRR generation
* [FIX] make it possible to generate QRR
It must be possible to generate QRR without ISR subscription number.
Content removed as not present in the specs version 2.1:
* [RM] procedure section
* [RM] due date
Translations:
* [IMP] Add translations of the QR-bill in DE, FR and IT
* [FIX] QR-bill lang is now based on customer lang
Tests:
* [IMP] Add unit tests for Swiss reality check for the QR-bill
closesodoo/odoo#54053
X-original-commit: 4f4edd0594b29252a5d44281cc773230c09521e9
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, when the same field occurred multiple times in
a form view, all occurrences were associated with the same id, and
all occurrences of the corresponding label (if any) had the same
'for' attribute. As a consequence, besides the fact that there were
warnings in the chrome console, clicking on any occurrence of the
duplicated label focuses the first occurrence of the field.
This commit generates a unique id for each pair label/field, when
possible. However, there is a case that can't be handled
automatically: when the label isn't automatically generated (field
located outside a group, or with nolabel attribute set to "1").
Typically, in this case, there is a <label> node with "for"
attribute referencing the associated field. In this situation, the
id must be defined in the arch, and used in the "for" attribute:
<form>
<label for="phone"/><field name="phone"/>
<label for="phone_2"/><field name="phone" id="phone_2"/>
</form>
Task 2261697
The logs should all be in the same language, s.t. one does not need to
understand multiple languages when browsing/reading the server logs.
closesodoo/odoo#53984
Related: odoo/enterprise#11615
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Use of new _ signature (and placeholders)
* Ensure all error messages are translated
* No translation for warning logs
* Improved/fixed validation messages
closesodoo/odoo#53804
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Improve layout of access error messages from group restriction
* Improve layout of access error messages from security records rules
* Use the error title in the js crash manager when possible
* adapt unit tests
closesodoo/odoo#50369
Taskid: 2206787
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Code's been dead since 3407fb70e4
essentially inlined its behaviour into the base class.
closesodoo/odoo#53774
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Well odoo/odoo#40872 is definitely the gift that keeps on giving,
after causing grief with the logging configuration change turns out
inlining the method was *also* a terrible idea because it's overridden
in `mail` in order to note merges on the destination partner, which I
apparently completely missed back then.
Task 2285876
closesodoo/odoo#53756
X-original-commit: 41209dababfaebca7bfd3be6ee5a2f41e9bb4ff5
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Was missing demo data and some modules
closesodoo/odoo#53666
X-original-commit: 957bad16b6df1ee712e0db218fe03285fbf5c420
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Performance fix: when parsing domains using special operators
(`child_of`, ...), or with dotted field on the left value
(`['partner_id.name', ...]`), the ORM starts by a first call on
`search()` and builds a new domain so the final query has "IN (<ids
found by sub-search>)".
The sub-search issued on the comodel uses the default "order by".
The order of the ids is irrelevant here, we only need to know the ids.
A good example is when the sub-search happens on `product.product`,
which is ordered by `default_code, name, id`. The field `name` is
inherited and translated, so the ordering requires a JOIN on
`product_template` and a LEFT JOIN on `ir_translation`. Ordering by `id`
avoids these 2 JOINs.
Some discussion took place about modifying `_generate_order_by()` to
remove the `ORDER BY` clause when the `order` argument is False or ''.
Apart the fact that it would be a breaking change, @odony has shown that
sorting by `id` is so cheap that removing the `ORDER BY` might not
bring significant performance boost [0].
[0] https://github.com/odoo/odoo/pull/52368#issuecomment-646643773
opw-2270690
closesodoo/odoo#53629
X-original-commit: fc91f7b4e8f9f8a95862df1ce95a9639cf7d1363
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
The misc feature remove_accents(input_str) return a
string 'False' if the param is a boolean.
Solution
Return input_str if equal '' or False.
opw-2278959
closesodoo/odoo#53572
X-original-commit: 3fc7ce3b5599355933734e5e3f59d14a7a9b199c
Related: odoo/enterprise#11391
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Revision 07631a5185
inverts the parent/children relationship of the module categories
`module_category_administration`
and
`module_category_administration_administration`,
by swaping the `parent_id`.
During an upgrade, e.g. from 12.0 to 13.0,
as the `parent_id` node has been removed from the category
`module_category_administration` in the data xml file,
the field `parent_id` of the category was left untouched,
therefore leaving the former parent,
creating a recursion between the two categories.
```sql
select id,name,parent_id from ir_module_category where name ilike 'administration';
id | name | parent_id
----+----------------+-----------
79 | Administration | 78
78 | Administration | 79
```
closesodoo/odoo#53568
X-original-commit: e4bc0a6c6b1181b7c723df415c75f6983ff91927
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce the bug:
- Let's consider a new instance with default installed language 'en_US'
- Install CRM
- Activate a second language (e.g. en_GB)
- Set that language in all users
- Inactivate default language 'en_US'
- Reset the language of your current user (no value)
- Go to contact and try to create a new one
Bug:
A traceback was raised because the lang en_US did not exist.
PS: Forcing the user to set a language ensures that this fallback
will never occur anymore.
opw:2267711
closesodoo/odoo#53375
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
We want to create a XMLID for every first exhibition of a field in a
model. That is, we just want one XMLID by field by model and not one
XMLID by field by class. Previous implementation was determining the
"first field exhibition" by making sure the field was created and used
as part of the same module.
This assumption is invalid when we consider mixins. A mixin is an
abstract model that define fields and methods to be included in other
models. As it is abstract, it does not exhibits the field by itself. The
field will only be exhibited when included in a concrete model via
inheritance. When it is included in another module, the XMLID creation
is discarded.
Take a module M1 that defines a model A, take another module M2 that
defines a mixin X with a field X1. In a third module M3, extend A to
inherit from X. While M3.A is the first model module to exhibit the
field X1, the XMLID creation was discarded because `"M2" != "M3"`.
See https://github.com/odoo/odoo/issues/49354#issuecomment-614093767
Task: 2235368
Closes#49354closesodoo/odoo#53435
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
* code *must* have an eval_context, `None` would blow up as soon as it
looks for the `'action'` key
* [accidentally quadratic] eval_value returns a value per line, seems
silly to evaluate all lines for each line when we can evaluate all of
them once, then map results to field names
* eval_value doesn't break inside the loop, so every id gets a value
by construction, `dict.fromkeys` is completely unnecessary (and
provides no performance benefits)
closesodoo/odoo#53110
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
`state` was special cased in `copy_data` such that it would always be
reset to its default value if it had one.
While this special case can be useful (maybe) and is certainly
ingrained in odoo, having it not be overridable can be
problematic. Move the special case to the fields, so it's possible to
explicitly mark state fields as copy.
closesodoo/odoo#53113
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The attribute has been lost during a previous commit e6695c72d8.
This commit avoid that you can create an ir.ui.view without arch.
Before this commit, if you try to create an ir.ui.view with type but no
arch, the code will raise an exception in _check_xml:
/odoo/addons/base/models/ir_ui_view.py, line 377, in _check_xml
view_arch = etree.fromstring(view.arch.encode('utf-8'))
AttributeError: 'bool' object has no attribute 'encode'
Now, the user will have a warning on create, to say that View Arch field is required.
Could be backported if reported
X-original-commit: 4877bb4b650f5d1c52fefb06dec2fa568afcb121
On ir.property model, do get the field_id using the cached result from
ir.model.fields _get() method instead of issuing a direct SQL query
OPW-2067461
closesodoo/odoo#53351
X-original-commit: 24fff41d02fc7469d563f732a607db5c9a150e1e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Wrong usage of self in for loops makes some apparently multi-friendly
methods not work correctly when called with a recordset of len > 1.
This commit replaces those references by the correct unique record
reference which should be used at this iteration of the loop, avoiding
potential exceptions or wrong behavior in the concerned methods.
closesodoo/odoo#53320
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose of this commit is move 'Helpdesk' under the 'Services'
section on res.users form view instead of 'others'.
closesodoo/odoo#52043
Taskid: 2253481
Related: https://github.com/odoo/enterprise/pull/10821
Related: odoo/upgrade#1351
Related: odoo/enterprise#10821
Closes: #52043
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the PDF, `DictionaryObject` can be wrapped in `IndirectObject`. For nested
dictionaries, using `get` on a `DictionaryObject` will unwrap the result if it's
an `IndirectObject`, but not `__getitem__` so when trying to futher call `get`
on the result will cause an error: we need to unwrap the object first.
Instead, we patch `DictionaryObject.get()` for it to unwrap the object in case
it's an `IndirectObject`.
This is a follow-up commit of fece5ab1bf2fef043b131f1bd0886f0841116103
closesodoo/odoo#53269
X-original-commit: 189a0b28ec7fdb7472f936450cfd7b4bfd6912ed
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Until version 13.0, ir.ui.view:postprocess_and_fields returned a tuple
of a string and a dict of field information.
With aae1d57829, it now returns a
defaultdict instead of the dict.
This dict comes from NameManager.available_fields, which is initialized
as a defaultdict. There is no apparent reason to have a defaultdict in
this place, apart from the usage in has_field.
Furthermore, using a defaultdict has a side-effect in the search_view
computed field of all the ir.actions.act_window. On a database, if you
access env.ref('base.paper_format_action').search_view it will contain
a stringified dict, and the string default_dict(<class 'dict'>, {...})
is used in place of just {...} under the fields key.
closesodoo/odoo#53235
X-original-commit: 4586d0fbf0bdd5959b274611c58df911e50f4ef2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Since a recent commit[1], we have a utility method in tools named
'is_html_empty' that checks whether the given html content is
void(containing only formatting tags) or not. However, the re from
this method does not consider the case of self closing tags, fox ex
`<br/>`. In such cases, the method returns Falsy value even if the
content is void.
This commit fixes the issue by considering self-closing void tags
in the regular expression.
commit[1] - https://github.com/odoo/odoo/commit/974f512f5f5d3b9f80a8c3fcde290e4f55cf1230
Task - 2267689
closesodoo/odoo#53167
X-original-commit: 0fd6c9388dc959a9b6b7828850683175edb05b9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
ACLs on the wizard lines should match that of the wizard, otherwise
ERP managers can see the action but get an error as soon as they open
the wizard.
Since ERP managers have write access on arbitrary users, that's
probably the right group to use.
Task 2275134
closesodoo/odoo#53007
X-original-commit: 657d44f08c402bc0547b7cbb01c2d447e641d062
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Odoo cloc is a tool to count the number of relevant lines written in Python,
Javascript or XML. This can be used as rough metric for pricing maintenance of
customizations.
It has two modes of operation, either by providing a path:
odoo-bin cloc -p module_path
Or by providing the name of a database:
odoo-bin cloc --addons-path=dirs -d database
In the latter mode, only the custom code is accounted for.
Both modes can be used simultaneously.
Files that cannot be parsed are shown at the end of the report.
Parsing can fail due to syntax errors or excessive file size.
closesodoo/odoo#52635
X-original-commit: ae858c3ac66267b4726db459032b91a6be1cc1d6
Related: odoo/enterprise#11018
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Thibault Francois <tfr@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Things to know about specific views:
Since the introduction of website specific views, we can have multiple
views that are related to a website (specific views). These views have
no xml_id as it is only set on the original view (generic view).
We rely on the view's key to identify related views as it is the same
for all specific views of a generic view. Also the key is equals to the
xml_id.
When a generic view is updated, we will check if the specific views have
the same values as the generic view. If it is the case, the value that
are the same are considered updatable and are updated on both the
generic and specific view. Else these are considered as noupdate.
When a generic view is created we will check if the potential parent
generic view has specific views. If it is the case we will create a copy
of the created view for each specific view.
The issue:
The method that checks if a created/updated view has specific views is
located in website. When we update a module, each modules are
initialized and updated in a specific order. If a generic view that has
specific views located in a module loaded before website this view's
specific views will not be updated/created as the method does not exist.
This issue is mainly affecting portal views at the moment.
The solution:
For write:
We now COW(copy on write) the views in base module, meaning this will
apply to all qweb views that are duplicated and not only the website
specific ones.
For create:
We will create the generic view as before but wait until we have
updated all the modules to gather all generic views that are supposed
to have a specific view but don't and create the specific views.
This will result in a change of behavior being that if a specific view
that have a parent is deleted it will be recreated on update
(same behavior as a generic view).
closesodoo/odoo#52629
X-original-commit: b1a90ee2bb441aa52e3cf4607c43fb464b55b1d7
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.com>
Issue
- Create a second company
- Create user with access to main and second company
- Go to "Contacts" app
- Edit contact of the new user, and under the "Sales & Purchases" tab,
ensure that the company field is set
- Create a new contact with same email of the new user
- In list view, select both contact related to new user
- Click on Action->Merge Selected Contacts, then merge contacts
User has no more access to both companies, only company related to
merged destination Contact/Partner.
Cause
All related companies are unliked from user, and instead overwrited
with one company related of the merged destination Contact/Partner.
Solution
Instead of unlink all companies, we will only add the contact company
to the allowed companies of the user.
opw-2269397
closesodoo/odoo#52620
X-original-commit: e00b23b73f00fb24b2771ea8894031b35204e65e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
*: base
Previously, cropping an image was done inside of a modal window, turning
it into an inline widget makes the editor feel more integrated and
allows you to better see the result of cropping directly in the page,
it's also less intrusive to the user's edition workflow.
At the same time, the way cropped images are saved was refactored to use
the new original_id field on ir_attachment, as the old system was
creating problems.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
Part/Fix of commit #e579642
Issue
The condition `default_type not in self._fields['type'].selection`
always evaluate to True as the selection is list of (key, value)
tuples.
Solution
Replace the tuples by a list of possible values.
opw-2256905
closesodoo/odoo#52501
X-original-commit: 1b21c674c6de3ef96d7938c3e99b36d7cb2f2b6e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Commit bca2926b01 introduced a fix for
ir.ui.view unlinks during uninstall but forgot to return the result of
the super() call to unlink which broke behaviour downstream.
This commit restores the proper behavior of returning the result of the
call to super.
Closes#52364closesodoo/odoo#52435
X-original-commit: a3d91cc8691794d8f93ef416830b09fabcf08b66
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Similarly to server actions, searching and viewing the model on which a
scheduled action is defined is useful for administrators.
closesodoo/odoo#52239
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Issue
Step done with "CRM" since main kanban view can be
grouped by 'res.partner' model:
- Install "CRM" app
- Go to crm and group by "Customer".
- Add a Column.
Traceback is raised.
Cause
Wrong "default_type" in context ('opportunity' in this case)
when creating new kanban stage and grouped by "Customer".
Solution
On "default_get" for "res.partner", if "default_type" is in
context and not in 'type' selection choices field; then
remove it from context.
Cherry-pick of #47723 in 12.0
opw-2256905
closesodoo/odoo#52282
X-original-commit: e5796429c8adcbb929cb032cdfd2cbaba835b086
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit d5d2c5524c improved the UrlWidget s.t. it automatically
prefixes the url with 'http://' if no protocol is specified (except
for own website paths).
In addition, it removed a logic specific to model res.partner that
automatically prefixes the saved website values with 'http://'.
However, the second part should not have been done: those urls can
be displayed without UrlWidget (e.g. on the website), and in this
case, the protocol wouldn't be set, meaning that it would behave
like a relative link.
closesodoo/odoo#52113
X-original-commit: 5a8690bb64cb3dc01ee8d4f9af3a6ab91eee8b99
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
By default importing is batched (or at least attempted to), however
because the import is functionally sequential it's possible for a
record to refer to a previously imported record of the same batch.
When records are referenced by xid this is easy, we can just keep
track of all the xids we *should* have created so far and when trying
to look up a xid if it's one of those flush all pending
creations (otherwise assume it's some other unrelated xid which
already exists in the system).
For "name_search" lookups however this is more complicated, so we'd
just flush the entire thing.
This, then, is an issue when importing records with an m2o which
is *generally* looked up by "name" rather than xid e.g. when importing
partners it's more likely the "state" will be specified by
name (e.g. AZ or Arizona) than xid (base.state_us_3 lol), because it
means more or less every line will be flushed, defeating all batching
and slowing down the import.
To fix this, allow passing *model names* to flush (not just xids), and
try to collate all the models we could be creating (or updating)
records for in the process of importing. If we see a name_search on
one of these models flush, otherwise don't because we couldn't have
impacted the search.
Task 1951307
While at it, f2a1618758 removed all
usage of model_load_save, but left the creation of the savepoint
itself.
The InternalError check should be left in place to catch things like
conversion issues which put the tnx in an invalid state (only invalid
states should trigger an InternalError according to psycopg's errors
documentation).
closesodoo/odoo#49289
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Only system users can access ir.property records.
This PR is part of the long-term task id 8203 that plans to remove all access to
ir.* models
"Official" methods to interact with `ir.property`:
- `_set_default(name, model, value, company=False)`
- `_set_multi(name, model, values, default_value=None)`
- `_get(name, model, res_id=False)`
- `_get_multi(name, model, ids)`
Done in this PR:
- remove ACL on ir.property (only system users can access directly)
- make all getter/setters private with sudo
- use these methods everywhere instead of CRUD calls
- add sudo where needed
closesodoo/odoo#51658
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Xavier Morel