Complement of the previous complement e2752a04ff (#137099)
Those opcodes were added in Python 3.11 and we missed them.
Fixes#140588closesodoo/odoo#141015
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With normal module, the icon is always loaded from the filesystem but
when importing a module that contains a module icon (by default in
static/description/icon.png) it crash with a `FileNotFound` exceptions
because the image is not available on the filesystem but as an
ir.attachment.
This ensure that for imported module we load the icon from the
corresponding imported attachment
closesodoo/odoo#141133
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
As of https://github.com/odoo/odoo/pull/114024, `display_name` is
implicit in every form view (see the use of addFieldDependencies in the
Form controller). Therefore, when you create a new record for this
model, it calls the first `onchange`, which will compute display_name
for a new record (id without origin). Some `_compute_display_name` don't
handle new records correctly and raise a traceback. These models are
sometimes directly accessible:
- Accounting > Account Group > New => Traceback
- Contact > Contact Tags > New => Traceback
Other models are inaccessible by default (no view to access or create a
new record), but if someone creates a view for them with studio (or
modifies an existing one to allow creation):
- `crm.iap.lead.role`
- `crm.iap.lead.seniority`
- `chatbot.script.answer`
- `payment.token`
Change the code of `_compute_display_name` on these models to be more
defensive and avoid (potential) tracebacks. Similarly, change the
`convert_to_display_name` of `fields.Datetime` to take into account
`None` value.
closesodoo/odoo#139592
Related: odoo/enterprise#49721
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
__accessible_branches() used to call search() to get the children companies, but doing so, it returned them sorted according to res.company's _order, so (sequence, name). Because of that, a branch company with a name coming before it's parent's in alphabetical order, if they had the same sequence (which is the default), would always be returned before it by this function.
This behavior caused some issues, as it was assumed the order of the element it returned would be the same as in the company selector ; respecting the hierarchy of branches, with parent companies coming first.
This was spotted in Accounting, with the following setup:
- A company named "main", with one branch called "branch".
- "branch" has one sub-branch called "branch branch".
- Enable "main" and all its sub branches in the selector ; "main" is the active company.
Here are the issues that were found in Accounting:
1) Click on the "new" button in the Customer Invoices' tree view. Don't change anything in the form that opens, and check the value in the company_id field of the invoice being created. It should be "main", but it's "branch" instead.
2) (when applying the fix commit on the enterprise branch related to this one)
When printing an accounting report, the route called to generate the file restores the active companies from the options' multi_company key https://github.com/odoo/enterprise/blob/16.0/account_reports/controllers/main.py#L21 . Because of that, if the report does not support multicompany, but only branches of the active company (see corresponding enterprise commit for details), if the first company in this list is one of the branches instead of the main company, the companies computed for the report will be different.
In our example, "branch" will be first in the list, so the options for the file export will be computed with "branch" as main company, enabling only its branches that are selected in self.env.companies ; so only "branch" and "branch branch" will be in the report ; which is wrong, as we also want "main".
X-original-commit: b0d716a0e618ddc78d6ca80b5bc7b796ed27905a
Part-of: odoo/odoo#141033
If the web client gets into a bad state and piles on errors (or
exceptions) this leads to a mess with hundreds of kilobytes of
warnings being logged as we try to set an already failed tour to
failed (and also take screenshots), as in
http://runbot142.odoo.com/runbot/static/build/53098209-master/logs/test_only.txt
Also update `has_failure` to directly depend on an exception being
set, as that should be a more reliable indicator. And much like the
case of an error log skip trying to set the tour to failed in
`_set_exception` if it's already failed. Although in that case do log
the traceback as an `error`.
closesodoo/odoo#140879
X-original-commit: 96c501036a6dcb216e82e0dfa42b59a9b917d742
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since #104741, `Field.states` is no longer supported, remove the
documentation associated. We cannot remove the attribute
from Field because it is used in the migration script.
closesodoo/odoo#140694
Signed-off-by: Raphael Collet <rco@odoo.com>
Scenario:
- go to a model in technical
- create a new field and set "Related Field" to id
=> error "Unknown field name 'id' in related field 'id'" because we
get the field in self.model which is not present in the form view.
Fix:
Fallback to self.model_id.model as was the case before 16.0 commit:
76f699ca0b
Note: without the change, the added tests fails with:
Warning Unknown field name 'id' in related field 'id'
AssertionError: False != 'integer
opw-3138440
closes#112495closesodoo/odoo#140583
X-original-commit: aa406352541abd8bbf188da84fc4e370029ffc12
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When we add a smart button on a contact tag related to contacts, the
button adds a default search filter that hides the related records
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts > Configuration > Contact Tags
3. Open tag "Vendor / Desk Manufacturers"
4. Toggle Studio
5. Add a button (at the top right of the form) related to field "Tags
(Contact)"
6. Close Studio
7. Click on the button
8. A list view of the related contacts opens but there is a filter that
hides the records
Solution:
Remove the `filter_domain` attribute on the field category_id and
replace it by the `operator` attribute in order to use the raw value in
the domain
Problem:
In `_getFieldDomain`, we replace the `self` in the domain by the
stringified id which essentially checks for a category that has a name
containing the id
opw-3471959
closesodoo/odoo#140564
X-original-commit: 18640a2ddddcf2ef90948295a41b0d7d30ec09e3
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Incoming picking should almost never be in a waiting ('confirmed') state. So we check if the location bypasses reservation and that no move is in MTO.
Changing the main_flow_tour because removing the "Waiting" status from incoming picking forms makes it unable to find "Ready" in Mobile UI.
closesodoo/odoo#140180
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This will help the upgrade process. Currently, there is an harcoded[^1]
inherit tree stored in the upgrade source. By storing this information
in the databases, we:
- avoid this hardcoded list.
- support more than the standard modules.
task-3504720
[^1]: hardcoded, but autogenerated.
closesodoo/odoo#140261
Signed-off-by: Raphael Collet <rco@odoo.com>
-> This commit add/change the name of the page corresponding to the string
attribute because To be able to detect a field, Knowledge needs to be able to
read its page name.
For more reference: Task-3501211
Task-3524474
closesodoo/odoo#137428
Related: odoo/enterprise#48315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This patch provides the possibility to implement a custom security layer on top
of Odoo's imbus notification system and ir_cron live triggering system.
The key addition is the `ODOO_NOTIFY_FUNCTION` environment variable (opt-in),
which can now define a custom postgresql function to be called instead of the
default `pg_notify` function. This allows for greater flexibility and control
over the notification and triggering mechanisms within Odoo.
closesodoo/odoo#140089
Signed-off-by: Fabien Meghazi (fme) <fme@odoo.com>
In the 'Accounting Settings' of 'Fisical Year', When the User tries to set
'February' as a month and the 29th as a Day and Save it, It will allow the user
to save but when the User opens the spreadsheet dashboard in the terminal,
same error will be generated.
Steps To Produce:-
1) Install the 'spreadsheet_account' module
2) Go to Settings -> Accounting
3) In the 'Fiscal Periods' of 'Fiscal Year', In 'Last Day' select
'February' month and set 29 as a Day
4) Go to the Accounting module, Customer->Invoices
5) In the 'Favorites', Select 'Insert Link in a Spreadsheet'.
6) Open Spreadsheet, Click on the 'Dashboard' Tab
The Error will be generated in Backend(Terminal)
Applying these changes will resolve this issue.
sentry - 4079962029
closesodoo/odoo#140011
X-original-commit: 1323829d3b5e134300f326f86c887f1cad6119f4
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before this commit, the `recover` parameter is used when parsing the xml
files. The issue with this, is that it will allow and parse broken XML
files, and the error messages in JS will not be related to the issue on
the broken XML.
Now, the parser is stricter, and the broken template will be replaced
with an error template with a compressive error message of the parsing
error.
closesodoo/odoo#139818
Task-id: 3420400
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
change the field name 'parent_id' to 'related_id' for the test model, since
'parent_id' is an Odoo reserved field name
add translation test for `mapped` since it uses different code from the normal
read api.
closesodoo/odoo#139819
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently both incoming and outgoing emails are using the same 'email'
message_type. However both flows are not linked in any way.
Purpose of 'message_type' is to distinguish who generated the message.
In this case incoming emails are generated by the mailgateway while outgoing
emails are generated by mailins e.g. using the composer in mailing mode.
We now distinguish outgoing emails from incoming emails by using a specific
type for outgoing emails. Addons are updated accordingly.
Default 'message_type' value when removing sms/snailmail/whatsapp is now
'comment' instead of 'email', as default value of messages should be
comment as discuss is the main source of messages.
Task-3285720
closesodoo/odoo#139814
Related: odoo/enterprise#49597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously proposed formating was trying to normalize extra in one part
of the path. This means that no extra needed a placeholder.
The implementation was meant to be more generic and extendible since a
part of the logic has to be in website.
A suggestion was made to make it more restricted but explicite by
keeping the url simple in web/controllers/binary.py but adding a
controller in website to add this extra part.
The base extra direction is now in the extension, as the min part.
Initial urls:
/web/assets/{unique}/[{website_id}/][rtl/]{bundle_name}[.min].{extension}
New urls:
/web/assets/[{website_id}]/{unique}/{bundle_name}[.rtl][.min].{extension}
Managed by two routes:
/web/assets/<string:unique>/<string:filename>
/web/assets/<int:website_id>/<string:unique>/<string:filename>
Where filename is in the format {bundle_name}[.rtl][.min].{extension}
Multiple possibilities where proposed
- /web/assets/website/<int:website_id>/<string:unique>/<string:filename>
More explicit but prefixing by /website was considered
- /website/assets/<int:website_id>/<string:unique>/<string:filename>
This one is a litle painfull to match similar attachement, where
website is ignored.
- /website/<int:website_id>/assets/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
- /web/assets/<int:website_id>/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
This last solution was not ideal to match without unique
/web/assets/%/<string:filename> can match both
/web/assets/123456/<string:filename>
and
/web/assets/1/123456/<string:filename>
Anyway, matching without unique shouldn't be supported for al (even if
it is kind of supported with any right now) but it will work by changing
unique wildcard to a more specific one (_ * 7)
closesodoo/odoo#131353
Related: odoo/enterprise#47313
Related: odoo/design-themes#730
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The generation inside the rendering has some drawbacks:
- `commit_assetsbundle` is needed for reports rendering because the
template rendering may generate some assets that will be accessed by
another transaction before the transaction is committed. But this
solution is not ideal since the transaction is committed in the middle
of the request
- when the first rendered page is a 404, the assets are not committed
and the page is broken.
- when starting, deleting an attachment can create a concurrent update
error and the request is retried. This will occur once per attachment
and for all worker trying to access the same resource. The whole
transaction is rollbacked, even the previously created assets bundle.
- The cold page load is a slower since there is more work to do.
- Implementing a readonly request is difficult because it could be
transformed to read write and re-executed if the assets bundle does not
exist.
Generating assets when needed solves those issues. The concurrency
when deleting an assets could still occur but only once per bundle, and
in a smaller transaction. This could be solved with a lock now that we
have more control on the transaction. The commit_assetsbundle can be
removed and 404 page should have a correct layout. The cold page load
could be a little faster because the assets bundle can be generated in
parallel requests instead of sequentially when rendering the page.
Part-of: odoo/odoo#131353
This is a small improvement to reduce the dependency between attachment
and link generation. This will help to move the generation in the
web assets route in next commit.
Part-of: odoo/odoo#131353
The current solution returns two node, one for the css itself, another
for the script managing the error. This means that we must know if we
have a css error when generating the assets links, when rendering a
t-call-assets.
The proposed solution will solve this issue by managing the error
in the css file itself. A slight change will also save the error in the
attachment instead of choosing the previous one, meaning that the
error will be saved and the bundle won't be recomputed anymore.
This solution also removes the only case when a t-call-assets can return
content instead of a link, this will be cleaned in the next commit.
As a slight change, a warning will alway be displayed on the bottom of
the page, to manage the case where the javascript managing the error is
not in the page.
Part-of: odoo/odoo#131353
The main motivation is to be able to generate assets bundle outside
the t-call-assets call.
The need of an id in the url makes it mandatory to have an attachment
when adding the url in the page. Without this restriction, we can guess
the url without generating the assets.
This can also have other useful side effect:
There are corner case when a worked could have an invalid url in
cache because, if the transaction is rollbacked or if another request
generates the same attachment at the same time. This should be
partially solved by removing the id: The url remains valid even if the
attachment does not exist.
Note that the extra part of the url was made explicit, always there and
taking one / to remove complexity and ambiguity.
Note that an additional query appeared in .test_50_perf_sql_web_assets
because of the search, this but two of them were in _find_record. One of
them was an `exist`, not making much sense since we are not getting the
id from the attachment url anymore but from a search, and the other one
was prefetch of the "public field" since the call to _find_record does
not go in other cases (xmlid, website published, access token, ....). A
attachment of a asset is always public, and this part of the security
was moved to the search domain. The final result is one less query:
- one query to search
- one query to read the fields (_get_stream_from) (the prefetch could
actually be set to avoid prefetching everything)
Part-of: odoo/odoo#131353
If upgrading a database across an addition of a new field to
ir.module.module (which is uncommon but does happen), the field
prefetching would try to load the field before the database schema had
been upgraded, leading to a loading error.
Since we *only* want / need the module's name, we can `search_fetch`
to preload just the field we need, and avoid ancillary
prefetching. It's a bit of an unnecessary optimisation compared to
just turning prefetching off, but it's also simpler (shorter) here
so...
closesodoo/odoo#140010
X-original-commit: c0102ca5dc3507c39f5ae6406fd962419fb09c6e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* clean and improve docstrings in orm
* fix typos found with codespell
* rely on the Environment class docstring instead of doc content (and
therefore move part of the doc inside the class docstring)
closesodoo/odoo#102969
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* clean and improve docstrings in orm
* fix typos found with codespell
* rely on the Environment class docstring instead of doc content (and
therefore move part of the doc inside the class docstring)
closesodoo/odoo#102969
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Unwittingly broken by the removal of `__implements__` in
a6d601dc4e, these lints don't run
correctly with the old pylint, allowing new errors to creep in since.
closesodoo/odoo#139605
X-original-commit: 99cec73f585c8759142a707b06934d9c23aa5478
Related: odoo/enterprise#49473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since https://github.com/odoo/odoo/pull/137098, `display_name`
can be false (from the default behavior in BaseModel). It isn't
handle correctly in domain_selector Component, which trigger a
traceback trying to `split` false.
closesodoo/odoo#139450
X-original-commit: 06f3cbb95b2e4cfb271039a19660991c743c2ba8
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Polymorphe57 <dam@odoo.com>
Before this commit, updating a boolean field through a server action was
possible but unintuitive: if you wanted to set the field to `False`, you
had to leave the value empty - worse, writing down `False` would be
considered truth-y since it was evaluated as a string!
This commit introduces a simpler UX for these cases, where the user can
select Yes/No in a selection field if the field they're trying to update
is a boolean field.
Task-3450200
Part-of: odoo/odoo#138804
Commit b05e7e4da0 rightfully removed the _compute_name dependency on
context keys (a bad idea for stored computed fields), but this change
could lead to UX frustrations (Server Action names getting reset all the
time despite what the user may have used as a name before) and UX issues
(e.g. triggering a recompute by accident at module removal that could
reset all 'code' action names to 'Execute Code').
This commit simply removes the automated naming feature from the base
module and moves the logic to the base_automation module - and only
computes automated names based on the link with an automation rule or
not (so 'standalone' server actions need a name given by the user at all
times).
Task-3450200
Part-of: odoo/odoo#138804
Before this commit, server actions of the 'Update Record' type could
only write on m2m fields entirely - meaning that there was no support
for commands like adding or removing records from the set without
writing it completely.
This commit introduces this possibility, along with some UI changes to
come from it regarding the display of such actions in automation rules.
Task-3450200
Part-of: odoo/odoo#138804
Webhook server actions allow users to send a POST request to an external
system, e.g. Slack, Github or even another Odoo instance.
This is a rather simple setup, as this feature does not include frequent
features of typical webhooks, such as the possibility to use headers for
authentication, or a retry-policy with exponential decay and all the
bells and whistles of that style.
However, this can be useful for simple actions and automations.
Task-3450200
Part-of: odoo/odoo#138804
Up until now, the 'Update record' server actions could only update the
record on which the action was triggered.
This is a rather serious limitations, especially in modules that
leverage server actions, like base automation - indeed, if you want a
server action run on e.g. Leads that will write changes on the leads'
customer, you *had* to use Python code.
This commit makes it possible to traverse relations when selecting the
field to update, and indeed to write across relations.
Task-3450200
Part-of: odoo/odoo#138804
- inline configuration/display for 'update record' action type
- don't use notebook when there's a single page that gets displayed
- remove default field when updating a record
Task-3450200
Part-of: odoo/odoo#138804
- Slight reword of the 'type/state' field labels for server actions
- Re-ordering of 'type/state' values
- Form view changes
- Allow hiding model in display_name of ir.model.fields base on context
key (avoid technical details when they are not needed)
Task-3450200
Part-of: odoo/odoo#138804
Up until this commit, HTML fields created from the UI or via data
modules or via Studio where alway sanitized, without any possibility of
control by the developper or db admin.
This commit makes it possible to override these attributes for
data-defined fields (python-defined fields cannot be overriden).
This makes it possible to create fields that can e.g. be used as 'block
targets' in the website editor for data modules.
closesodoo/odoo#130544
Related: odoo/enterprise#47116
Related: odoo/upgrade#5290
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Christophe Monniez