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>
[Here](https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/odoo/tools/translate.py#L1645) If 'en_US' is exist in new_values then as a default language 'en_US' translations are loading due to that translation of default language gone lost
OPW -3482255
original translation look like this
if default language is dutch for example then instead of dutch language english's translations are there
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
```
arch_db look like this
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this dutch</p>
</t>
</t>
```
closesodoo/odoo#139111
X-original-commit: 542851c50182f32327f9cd3607081515899ddb76
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Sanchit Gupta (sagu) <sagu@odoo.com>
Purpose
=======
Cannot currently save My Profile due to those 2 fields
- attendance_manager_id (allowed for groups 'Attendances / Administrator')
- employee_cars_count (allowed for groups 'Fleet / Administrator')
They are in the SELF_READABLE_FIELDS property, but the method
check_field_access_rights is not taking that information into account.
Part-of: odoo/odoo#139731
Currently if a record is not in the cache it raises a `CacheMiss` the
handling of which leads to loading the record from the database (or
something).
If an issue occurs during that loading, because the loading is an
`except` scope the cache miss gets linked with the new one via
> During handling of the above exception, another exception occurred:
This is both noise (the cache miss is not actually relevant) and
misleading, because the wording makes it look like an unrelated error
occurred during handling.
- move the loading of the record out of the `except` to limit the
scope of the `KeyError` and avoid "inheriting" it
- try to `from None` a few specific errors to remove implicit linkage,
as the new error should have all relevant information, the key error
/ cache miss is just an implementation detail
closesodoo/odoo#139680
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Now that some field attributes like invisible are given by Python expressions
and that those can involve some set operations, we have to ensure that
the views can be validated if they use such operations. We do that and
add a test.
closesodoo/odoo#139451
Signed-off-by: Géry Debongnie <ged@odoo.com>
Most of the time, rates are computed in a loop by using
`<res.currency>._convert`. This leads to a lot of round trips with the
database.
This PR is caching the value for a whole transaction.
In order to do that, the non stored field `rate` has new (missing)
contextual dependencies: the arguments of `_get_conversion_rate`.
This allows to move the actual computation of the rate to the computed
field, and `_get_conversion_rate` is now only a proxy to avoid playing
with the context manually; also kept for backward compatibility.
Other solutions were considered:
* `ormcache`, but we want to avoid creating multiple caches and reduce
the possibility to have inter dependent caches.
* managing a local cache everywhere, which is cumbersome and error prone
* a helper for the previous option by using a converter factory, but it
is still an issue when the convert function is called from multiple
call functions because the cache isn't shared then.
Part-of: odoo/odoo#137609
Chong Wang (cwg)