Steps to reproduce:
- install the mrp_plm module (Product Lifecycle Management app);
- create a product with a long name;
- create a bill of material for that product;
- create a manufacturing order and select that bill of material;
- confirm the manufacturing order.
Issue:
The value of the bill of material field overflows into the second column.
Cause:
There is a problem in the use of classes in the .xml file (o_row and d-flex).
Solution:
Change the classes used (Bootstrap and Odoo classes) to have the correct rendering.
opw-2966863
closesodoo/odoo#100305
X-original-commit: 7a7c6870a2006edab8ffe62c016e5eb0681a46f8
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Before this commit
When creating a new mass_mailing and hitting multiples times enter, the
content was reset.
task-2985162
closesodoo/odoo#100284
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
It feels more natural with the new name;
The "X2ManyTags" things is because it used to use
a many2many tags fields under the hood.
1) It's no longer true
2) It's an implementation detail
Part-of: odoo/odoo#100246
The X2ManyTagSelector component still used a legacy many2many tags
widget under the hood and an adapter layer on top.
With this commit, it uses new components
Part-of: odoo/odoo#100246
Commit [1] made it so the computed stock_location.warehouse_id field is
stored. Unfortunately it did not correctly add the additional depends
value of `location_id` so when this value is changed after the record
has been initially created+saved without a location_id, the warehouse
will never be correctly computed.
[1] https://github.com/odoo/odoo/commit/9978bcb366d0ea48ed25a7891e0c7653a2f96bfb
Followup to task: 2882539
closesodoo/odoo#100219
Related: odoo/upgrade#3901
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The `is_subcontracting_location` setting is intended only for
complicated route/rule use cases therefore we make it visible
only in debug mode to prevent users from setting this value and
unintentionally creating a lot of new routes/rules unnecessary.
Additionally, it is expected that users who previously set these up
manually will not want their custom rules/routes changed but will still
need the existing behavior to continue, so we restore the previous check
for subcontracting locations set as sublocations of the primary company
subcontracting location.
Follow up to task: 2720393
Part-of: odoo/odoo#100219
Before [1], the web_editor module was auto installed. After that commit,
the bus module has been added to the web_editor dependencies. Since
the bus module is not auto installed, the web_editor module dependencies
are not met which means the login colors are wrong (blue instead of green).
This commit fixes this error by adding the `auto_install` flag to the
bus module.
[1]: odoo@a5623d24b77f523aeeafbb8c2bfaf27241ef3c8e
closesodoo/odoo#100212
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Introduce header actions so that emoji picker in knowledge
can have an action to remove emoji.
Task-2980528
closesodoo/odoo#100010
Related: odoo/enterprise#31231
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
On the application page, too much elements are set
in the primary color, creating confusion as of where is
located the main page action.
Also changes the phone field in the job application page
to be stored as a mobile phone instead of a home phone.
task-2980889
closesodoo/odoo#99976
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The purpose of this commit is to improve the domain selector UX with
multiple little changes:
- The model field selector popover is now autofocused when opened
- Removal of a div that appeared during a hover on "add leaf" and
"ellipsis button"
- Caret icon next to the root node selector
- Minor CSS changes
task-2861497
closesodoo/odoo#99321
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before, the small "caret" to the right of the dropdown was only
displayed if the current Dropdown was a child of another Dropdown.
It is sometimes necessary to display this caret in a parent
`Dropdown` in order to make the user understand that there is a
dropdown if he clicks on the text.
Now, it is possible thanks to a props to display manually this carret
if desired.
Part-of: odoo/odoo#99321
[IMP] core: store translated fields as JSONB columns
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
`NULL`
`{"en_US": "Foo"}`
`{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}`
`{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}`
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
` NULL`
`{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}`
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
`SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...`
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
closesodoo/odoo#97692
Task-id: 2081307
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose of this PR to improve the generic usage of project app
So in this commit done the following changes:
- when a project is archived, the 'tasks' stat button should
count/show archived tasks
- when delete project it's milestone should also be deleted automatically.
- project.task > blocked by notebook: it should be possible to select tasks
in projects that are not allowing 'task dependencies'
- project.task portal form view: hide the description if it is empty
task-2853991
closesodoo/odoo#94138
Related: odoo/enterprise#28654
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The current asset_bundle version uses the last modified date.
This can be problematic in some case.
Even if it is a long time issue, the problem was rediscovered on runbot
with a commit being in the future. Runbot will export all file and set
the write date of the file to the commit date. The main purpose is to
have deterministic bundle version between different builds. This also
allows to generate assets bundle once at install for all post install
subbuild.
The issue here is that the commit date was greater than now(), meaning
that some tests setting custom css in attachment won't trigger the
regeneration of assets bundle. This wasn't really noticeable before
assets pregeneration.
This is not the first time strange issues occurs because of the
last modified logic.
This commit combined all last_modified to generate the bundle
version.
The current adaptation is quick and dirty and this will be reworked in
another post 16.0 freeze assets refactoring and cleanup.
closesodoo/odoo#100160
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The field is related towards the 'manager' field of the expense sheet,
which means that when the approver is suggested automatically based
on hr data, the expense records get written a value for this field
(which is not in the view) which gets logged as:
- None -> Mitchell Admin (Approved By)
which seems to suggest that:
- the expense has been approved (it has not, a report was created)
- Mitchell Admin has approved: it may not be him (as when approving,
the 'manager' field does not log who did the approval but who was
supposed to initially)
Disabling tracking for this field (which contained no actionable
information at best, and incorrect suggestions at worst) makes this
problem go away.
closesodoo/odoo#100241
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In legacy, hide_model attribut on FieldReference was used to hide
the model input, but it was not implemented in ReferenceField
(new version).
closesodoo/odoo#99819
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The context before click button cancel in expense sheet not cleaned yet.
closesodoo/odoo#100288
X-original-commit: 6f8d3d989cc024c8e5b3e9e1a6b2f4af636721d6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
People asked to translate the States, because they had a use case, but
it's a minority. But other people also had issues on addresses because
states were translated. Translated fields can introduce mistakes.
Example: if I send a letter to: "Virginie-Occidentale", will United
States postal services understand that they actually have to send to
"West-Virginia"? That's an easy one, but there are more tricky ones.
Translations induce a lot of mismatch when people duplicate or edit.
Suppose a user edit "New-York" state and rename into "Californie"
because they do a mistake while changing the address of a partner the
same customer might receive it's letter in New-York or California,
depending on the language. Having states being translated might lead to
more issues, than not translated.
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
Previously, 'Edit Translations' button is used to translate
the English field ir_ui_view.arch
A dialog for list view of all translations is opened
After this commit, a new 'EN' button is used to translate
the Engligsh field ir_ui_view.arch
A translation dialog (like other translatable fields) for all translations is opened
General idea of the implementation:
1. add the invisible ir_ui_view.arch_db field to the form view before ir_ui_view.arch
2. show the 'Lang' button in the edit mode
and make it look like a button for its next field ir_ui_view.arch
3. Forcely change the 'Lang' button to 'EN'
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount for each payment term lines.
The user can choose between three different kind of tax computation for the discount. If the conditions for the cash discount are fulfilled, the tax will either be:
- included : the tax and base amounts will be discounted.
- excluded : the tax will be left untouched, the base amount will be discounted.
- mixed : the tax is durably discounted, the base is discounted if the early payment occurs.
The discounted amount and the conditions to fulfill are printed below the invoice PDF if the option to do so is checked.
Took the opportunity to improve the display of the payment terms on the invoice in general.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
The Journal Items in the account.move, the payment and the reconciliation are modified as needed to take the discount into account.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts is also applied to allow as often as possible for an automatic reconciliation.
Related : odoo/enterprise#28607
Task-2968644
closesodoo/odoo#99572
Related: odoo/enterprise#31225
Signed-off-by: Laurent Smet <las@odoo.com>
This related field is useful in sale to simplify the logic of the
product configurators (incoming adaptation to OWL).
Thanks to that, we'll be able to avoid an useless rpc to get the
detailed type of the SOL product.
closesodoo/odoo#100310
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For now, the graph view completely ignores the order attribute set on
its arch root node if written in the correct way, i.e. with "asc" or
"desc" (lower case). We fix that.
closesodoo/odoo#100302
X-original-commit: 0fb64bef16914937cf4a1d1618fb58ade6d16f14
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Steps to reproduce the issue:
- Create a presentation in a course (model `slide.slide`)
- Create an entry referencing the presentation in `slide_embed` table
- Remove the presentation from the course and save the changes
Bug:
A validation error was raised
opw:2902062
closesodoo/odoo#99468
X-original-commit: e5c239fcef2ee29856428c8f0d337fffc0a22e56
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
The RappresentanteFiscale and CessionarioCommittente nodes must be in this order in the invoice xml. The RappresentanteFiscale node is only added if the company has a tax representative configured. In that case, before this fix, submitting an invoice to the SDI (Italian tax agency) would not go through and generate an error :
The invoice has been refused by the Exchange System
File non conforme al formato : Invalid content was found starting with element 'RappresentanteFiscale'. One of '{TerzoIntermediarioOSoggettoEmittente, SoggettoEmittente}' is expected.
How to reproduce :
- Install l10n_it_edi_sdicoop
- Configure a tax representative on the company
- Go to accounting settings > Electronic Document Invoicing and choose the test mode + check the “Allow odoo…” checkbox.
- Create a new invoice and confirm
- Click on “Send now”
- Click again on “Send now” until there is an update and the error is displayed.
closesodoo/odoo#100264
Task: opw-2952098
X-original-commit: 71da80deb044852a2af6b111d695f94aad7803ac
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Allow to paste font tag as it is used to style colors.
Allow style attribute on tag B, STRONG, I, S, U, FONT.
task-2980754
closesodoo/odoo#100262
X-original-commit: 0b907fe5cfb9a1f83da4079e30e46e6711ade797
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This transforms text between two backticks into a code element, when
typing the closing backtick.
task-2985108
closesodoo/odoo#100218
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit allows to define steps in tours that drag&drop records
in (wowl) kanban views. The former helper is based on jQuery,
mostly because the drag&drop feature comes from jQuery. This
feature is still necessary for the legacy codebase using jQuery.
This commit thus introduces a new helper to allow the drag&drop
in wowl Component using, for instance, the `useSortable` hook.
This commit also fixes the project tour by making it use that
new helper. Note that even though the tour was broken (when run
"automatically", not in a user onboarding), runbot was green
because there's no test running this tour. It would be nice to
add one.
closesodoo/odoo#100208
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, a record quick created in kanban would have values
left from the quick create form view in its `data` object, that would
then be used by the model of the parent view to perform onchange
actions.
This would cause a crash if said values were set on a field not included
in the parent view's active fields.
In this commit, records data are cleared at each load, ensuring that
they only contain values for their current active fields.
closesodoo/odoo#100182
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the groups returned by `web_read_group` were
unpacked using the current 'group by' field name, and not the entire
'group by' value (potentially including a granularity for date/datetime
fields). This caused mismatches in some cases and the value couldn't be
retrieved.
Also, a needless 'sum_field' parameter was passed to the
'read_progres_bar' calls, which does not exist in the request API.
This commit fixes the first issue and removed the excess parameter.
closesodoo/odoo#100149
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit aims to make the behavior of the mocked 'read_progress_bar'
requests closer to their server implementation.
Namely, the returned dictionnary is supposed to contains the display
names of the current groups in its keys. This was not the case and has
been fixed.
Part-of: odoo/odoo#100149
Avoid starting the patcher two times to not create two separate
instances of it, and only stopping one of it.
closesodoo/odoo#100058
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Now that web_studio no longer uses the legacy graph and pivot views and
that all their extensions have been converted, we can finally remove
them from the code base.
closesodoo/odoo#99734
Related: odoo/enterprise#31112
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With [1] moving the website in backend, it is now possible to display
a backend discuss chat window while browsing your website.
This window is unfortunately hidden behind the SnippetEditor when it is
open.
The choice was made to hide the chat window when the edit mode is
activated, as it could hide some content of the page.
Steps to reproduce:
- Open a Discuss chat window using the systray item from the app grid
- Open website
- Click on Edit
Chat window is hidden.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#100098
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website service method fetchWebsites was not
clearly defined: it was fetching the user groups, the websites, the
current website and it was also setting the service's current website.
There is a difference between the get_current_website backend method and
the getter from the website service, introduced in [1]: the
websiteService.currentWebsite value referes to the website currently
edited in the WebsitePreview client action. From that value depend other
components visibility (like the contextual menus).
So when a fetchWebsites call was done from outside the client action,
from a PageListController with [2], it was breaking the flow by setting
a currentWebsite outside the client action and it could lead to bugged
flows:
- Go to the "Pages" list view
=> The contextual "This page" menu is not shown, it's correct
- Refresh the page
=> The "This Page" menu is shown (and broken).
To fix that, the fetchWebsites method is divided into a fetchUserGroups,
the searchRead on the websites, and another call to get_current_website,
located in the client action. It allows to load the client action iframe
with the last viewed/edited website.
Also, the menu "This Page" is shown only when there is a pageDocument at
the website service level.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
task-2687506
closesodoo/odoo#100055
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Short summary:
- People can now use the snippets option to show/hide based on country
- We never use / test / maintain this feature, if it still works since
its introduction 4 years ago that's by luck
- It is probably barely used, we never got a single question or issue
about it
-----------
When we introduced the multi-website feature, it came with 2 main use
cases:
1. Multi website by domain -> Every website has its own domain and based
on that we serve the expected website
2. Multi website by geoip -> Multiple website can have the same domain
and based on GEOIP/country we serve the expected website
We never really supported, highlighted or promoted the geoip case.
We actually never use it ourselves when doing tests, and we don't
consider it when doing specs / improvements.
At most, only a very few people know about it in Odoo.
That GEOIP case is probably not useful at all, as displaying a whole new
website based on lang is not easy since nothing can be shared out of the
box -> Every website has its own COW records.
For instance, one could think of having its main website A and another
website B on which he just added 3 products specific to that website B
country.
But such a case won't even work properly, as any adaption on website A
won't be reflected on website B (design, theme etc).
closesodoo/odoo#99938
Related: odoo/upgrade#3892
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
William Braeckman