Since the recent css change the text of the description field was no taking all the place he could, so it was impossible to read, thanks to the colspan it's now the way it was intended
closesodoo/odoo#103634
X-original-commit: 93d29540ff6a6756a84d904047d4e9554d6d9ad7
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
The Owl web client does not suppress GTK-style mnemonics, so these
should be removed, as otherwise they are explicitly displayed.
Following GTK rules, the old GTK client would use the `_` letter
prefix in labels to underline the letter and use the corresponding
character as accelerator/mnemonic for activating the
control (https://docs.gtk.org/gtk4/ctor.Label.new_with_mnemonic.html).
The web client "supported" this feature by just ignoring and dropping
the `_` it found in labels, even after it gained support for keyboard
accelerators (= hotkeys).
The new Owl form just ignores GTK-style mnemonics entirely, not
performing that preprocessing on widget labels. As a result, the
mnemonic marker (`_`) now appears literally in some labels, and needs
to be removed.
closesodoo/odoo#103563
X-original-commit: ca80632a1045b26927f72d93f4ec58e7a58b5654
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Ducplicating a company is not allowed (see copy override in
base/res_company.py), therefore removing the button from the view
altogether can avoid user confusion.
Task-3000228
closesodoo/odoo#103250
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
classic layout issue due to the group that cause a wrong alignment
closesodoo/odoo#103205
X-original-commit: 2f5b96639c8bb7975696c507c11d57d164e52cbb
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Due to group inheritance mechanism, if we try to "downgrade" the group
on a user's form view, after saving the record, sometimes the changes
may be reset automatically. Same kind of confusing behavior appears when
groups are automatically added due to cross-apps access rights dependencies.
This is very confusing because users can not easily understand what is
happening and why.
This commit improves the behavior by providing a proper warning string
to user on the fly when the groups are changed (which can potentially
be reset upon saving). For better understanding of possible scenarios
and the warning linked with them, see the test-cases that explain
everything with visual hierarchy.
taskID-2646704
closesodoo/odoo#91641
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
The purpose of this PR is to inline the "Validate" button
with the `country_id` field on the partner form view
when using Avatax.
task-2947705
closesodoo/odoo#100093
Related: odoo/enterprise#31277
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Class ResPartnerBank modified to:
- Add field 'allow_out_payment', true iff account can be recipient
of out payments
(False by default for new accounts except when created from res.partner)
- Enable chatter tracking for base fields
- Remove barely used/useful view view_company_partner_bank_form
closesodoo/odoo#94801
See: odoo/enterprise#29916
Task: 2856231
Related: odoo/upgrade#3637
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The changes in `auth_password_policy` are largely the owlification of
the password meter widget:
- modernize the password policy module and convert it to an
odoo-module (note: now exports a pseudo-abstract class which is
really a policy, for the sake of somewhat sensibly typing
`recommendations`)
- replace the implementation of the Meter and PasswordField widgets by
owl versions
The changes to web and base stem from taking a look at converting the
ChangePassword wizard, and finding that it would be a pain in the ass
but also... unnecessary? It seems to have been done as a wizard
completely in javascript despite being backend-only for legacy
reasons: apparently one of the very old web clients (v5 or v6
probably) implemented it as a "native action" which was directly part
of the client's UI, and so it had to be implemented entirely in the
client.
Over time it was moved back into the regular UI (and moved around
quite a bit), hooked as a client action to maintain access to the
existing UI / dialog.
But since it's been an action opened via a button for years it can
just... be a normal wizard, with password fields, which
auth_password_policy can then set the widget of.
So did that:
- removed the old unnecessary JS, and its dedicated endpoint (which is
*not* used by portal, portal has its own endpoint)
- used check_identity for the "old password check"
- split out `change_password` with an internal bit so we can have a
safer (and logged) "set user password" without needing to provide
the old password, which is now used for the bulk password change
wizard as well
- added a small wizard which just takes a new password (and
confirmation), for safety a given change password wizard is only
accessible to their creator (also the wizard is restricted to
employees though technically it would probably be fine for portal
users as well)
Rather than extensive messy rewrite / monkeypatching (the original
wizard was 57 LOC, though also 22 LOC of template, the auth_policy
hooking / patching was 33, plus 8 lines of CSS),
`auth_password_policy` just sets the widget of the `new_password`
field in the new wizard, much as it did the bulk wizard.
Also improve the "hide meter if field is empty" feature by leveraging
`:placeholder-shown`. This requires setting a placeholder, and while
empty works fine in firefox, it doesn't work in chrome. So the
placeholder needs to be a single space. Still, seems better than
updating a fake attribute or manipulating a class for the sake of
trivial styling.
Notes on unlink + transient vacuum
Although the wizard object is only created when actually calling
`change_password`, and is deleted on success, it is possible for the
user to get an error and fail to continue (it should be unlikely
without overrides since the passwords are checked while creating /
saving but...).
While in that case the `new_password` in the database is not the
user's own, it could be their *future* password, or give evidence as
to their password-creation scheme, or some other signal useful to
attack that front of the user's life and behavior. As such, quickly
removing leftovers from the database (by setting a very low transient
lifetime) seems like a good idea.
This is compounded by the `check_identity` having a grace period of 10
minutes. 0.1 is 6 minutes, but because the cron runs every 10 the user
effectively has 6~10 minutes between the moment they create an
incorrect / incomplete version of the wizard and the moment where it
is destroyed if they just leave it.
closesodoo/odoo#99458
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This technical module can be used to configure onboarding panels flows at
company or global level (required for new Appointment onboarding, see ENT PR).
This implementation, which should be able to support the migration of the
other onboardings, separates the closed state from the completion state
(allowing to know that steps are not completed even though the panel is
closed).
Basic tree and form view are included.
Adding an onboarding with this module requires to provide records data for the
models:
- `onboarding.onboarding` + action to close the panel
- `onboarding.onboarding.step` + actions for the 'opening' and 'saving' of each
step.
See related ENT PR for the `appointment` example, in particular
`onboarding_data.xml` and `onboarding_onboarding.py`
Several python tests are also included.
Misc. In base, we slightly refresh the wording/style of the modal closing the
onboarding panel.
Task-2852375
Part of Task-2900763
Part-of: odoo/odoo#97105
In the `res.partner` form:
- the field `user_id` is set in base,
and is directly within the base res.partner.form form view,
within the `Sales & Purchase` notebook page
(which is in the base module despite what the tab name could make think)
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/odoo/addons/base/views/res_partner_views.xml#L343
- the field `team_id` is set in the module `sales_team`, and added
in the res.partner.form form view from this `sales_team` module
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/addons/sales_team/views/res_partner_views.xml#L9
Therefore, there isn't any obvious reason why the context `default_`
keys for `user_id` and `team_id` are set
only once the `crm` module installed,
neither why it only applies if you are a salesperson
(to the group `sales_team.group_sale_salesman`, sets in the view
`groups_id`).
If we have a look to the commit
f0b7600314
The goal described in the commit description is still achieved
by moving these default context keys in their respective module.
Besides, having a closer look in this commit,
`default_user_id` is directly added in the simplified partner form
within the base module, but is added through the crm module
for the regular form. Which doesn't make really sense.
Part-of: odoo/odoo#98551
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In this commit we cleanup server actions model in order to make it a bit
more inlined with current code state of the art.
* add no_create / no_open on technical fields (m2o towards fields notably)
as creating or updating fields on the fly is not the purpose of base
automation module;
* rewrite onchange into compute or constraint methods;
* add compute methods to cleanup data when changing configuration (model or
trigger). Some fields have no usage except in some configuration better
reset their value. Notably fields linked to the chosen model should be
reset;
* add constraints for invalid configuration, notably for models coherency
with mail features;
Task-2613245 (Server actions mail update / cleaning)
Part-of: odoo/odoo#75906
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Step to reproduce:
- Go to 'My Preference' or User profile as admin
- Click on the world icon to add a language
Old Behaviour:
- Open the technical view of languages
New Behaviour:
- Open a wizard to add a a language
taskid-2774319
closesodoo/odoo#92855
Signed-off-by: Arnaud Joset <arj@odoo.com>
* fetchmail, google_gmail, fetchmail_gmail
Purpose
=======
Improve the usability of the outlook modules.
Specifications
==============
Remove the checkbox "Use Outlook" and instead use the
smtp_authentication and the server_type, to be consistent with Gmail.
Hide the password field for Outlook / Gmail mail servers.
Add constraints on the outgoing mail server to force the user to use
the right configuration (e.g. the from_filter, so the sending does not
fail).
Add an option in the mail module to install Outlook.
Show a message for the outgoing mail servers to explain each
authentication methods.
Task-2811567
Part-of: odoo/odoo#88215
Purpose
=======
Improve the incoming mail server list view and the outgoing form view.
Show the most used option first, and make the view more responsive.
Task-2811567
Part-of: odoo/odoo#88215
This commit does the following changes:
- Improve some project filter and views
- Align the module kanban buttons
- Sort the module in uninstallation wizard
task-2731708
closesodoo/odoo#83339
Related: odoo/enterprise#23783
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In BS5 there is a check to avoid having multiple handler for one
element and we can't add two components' instance on an element.
So, before disposing a tooltip we check if there is an instance of a
tooltip and we avoid instantiation of tooltip if not already done.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.collapse.
e.g.:
> Bootstrap doesn't allow more than one instance per element. Bound
> instance: bs.carousel.
> Bootstrap doesn't allow more than one instance per element.
> Bound instance: bs.tooltip.
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 JS use the `data-bs-toggle="dropdown"` attribute to
automatically enable the BS Component.
But in this case as the `.dropdown-menu` is only rendered when the
`.dropdown-toggle` is clicked we can't initialize the Dropdown at the
first render. So we do it manually.
- change .dropdown-menu by .o-dropdown-menu (owl)
-> to handle keyboard navigation we can't use BS dropdowns
- use currentTarget of event
As the event can bubble we use currentTarget to be sure to be at the
higher level in the DOM.
> All the events for the dropdown are now triggered on the dropdown
> toggle button and then bubbled up to the parent element.
- BS5 don't add .show on parent group anymore
-> dropdown show class not on the same node on BS5
- avoid dropdown warning using margin in CSS
BS5 show a warning if we use margin statically in CSS for a dropdown.
> Popper: CSS "margin" styles cannot be used to apply padding between
> the popper and its reference element or boundary. To replicate margin,
> use the `offset` modifier, as well as the `padding` option in the
> `preventOverflow` and `flip` modifiers.
- adapt the systray activity dropdown for mobile
On desktop positions are now dynamic and on mobile it's static
- In BS5 the CSS `bottom: 100%;` is not more applied to the
`.dropup .dropdown-menu` selector.
- Change right -> end and add data-bs-popper="none" to avoid
Popper interaction
Task ID: 2766483
Part-of: odoo/odoo#95450
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
This commit does below improvements:
1/ If salesperson and sales team are set on an individual partner, we propagate
those to parent company being created from m2o of the form view.
2/ If the existing parent company is manually linked to an individual partner
being created, and salesperson and sales team are not set on the individual,
we set those values from the linked parent (if set on the parent).
Task-2636290
closesodoo/odoo#78696
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The documentation page for the external API was moved elsewhere with PR
odoo/documentation#2026.
closesodoo/odoo#94488
X-original-commit: 99eb55e14782bd32c4b2281681a62eb5f3d34407
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
view `base.res_partner_view_form_private`.
Currently, when user setting data for accounting or payroll, the bank
had not set yet.
Therefore, they have to open Contacts to adding new bank, then back to
Employees to check if bank available.
This PR will adding bank_id to improve UX make fewer duplicate processes
closesodoo/odoo#94230
X-original-commit: 5ce0b0217b897ad49e03467c57a393f27067ac3a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit:
- moves the "Company Registry Number" from `res_company` to `res_partner` (which might be different from the VAT in some localizations). This must be unique among all partners of the same country.
- allows the search of partner by using their "VAT" or their "Company Registry Number"
Task-id: 2857253
Community PR: odoo#91938
Enterprise PR: odoo/enterprise#27605
Upgrade PR: odoo/upgrade#3570closesodoo/odoo#91938
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Improves UX by adding placeholders to clarify the purpose of some inputs and
changing some field layout to ease the edition (with the use of multi-lined
editor).
Details:
Some placeholders have been added:
- description field of survey.question
- default_note field of mail.activity.type
- summary of mail_activity_type_view_form
Some field layout have been turned into multi-lined editor:
- default_note field of mail.activity.type
- write a message in mass mail mode (email_compose_message_wizard_form)
added border for field help of edit action (class oe-bordered-editor)
Task-2766291
closesodoo/odoo#85046
Related: odoo/enterprise#24599
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Revert the possibility to install languages from the form views
of opportunity/lead and partner.
We consider that the quick installation of languages is too
advanced and admin people can go through the dedicated menu if
need be.
task-2839020
closesodoo/odoo#91750
X-original-commit: 5a616997659b2359ec946883b620e2fae6d6c39d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this commit the user can search for currency name, code, symbol or even subunit name
task ID:2846565
Pr: #90913
Signed-off-by: William André (wan) <wan@odoo.com>
Since v15 and the owl improvment, the signatures of other users
could not be modified in HTML (as v14 and previous) as the
codeview button was missing.
In order to modify the signature with this commit in v15:
1/ Access a user
2/ Edit
3/ Click on the codeview button (Odoo Green button with </> inside)
4/ Copy/paste your html code
5/ (/!\) Click again on the codeview button
> You should see your HTML signature
6/ Save
opw-2728194
follow-up of https://github.com/odoo/odoo/pull/80788closesodoo/odoo#87506
X-original-commit: 573a33d10d0cc830ab6e23b4ec512f9394530c90
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: Vergote Baptiste (bve) <bve@odoo.com>
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2753905
closesodoo/odoo#84058
Related: odoo/upgrade#3228
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Some html field are not in their ideal style.
As the style for html fields is now dependent of
where you are in the xml view ( in group or not),
we have to adapt some views and flags some fields
to ensure they have the correct look.
This change is only be a visual enhancement
and should not prevent the function of said html fields
even if the views are not updated.
task-2637488
# Conflicts:
# addons/mail/wizard/mail_compose_message_views.xml
# addons/website_slides/views/slide_channel_views.xml
# Conflicts:
# addons/sale/views/sale_views.xml
closesodoo/odoo#83792
Related: odoo/enterprise#23911
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Rely on country.address_view_id instead of hacking the view on the fly. The
address layout (street VS street_name street_number street_number2) depends now
on the country of the user, not on the installed localisation. (it's now
configurable per country)
Unified street format to "Chaussee de Namur 40 - Appt 12"; the
configurable ones where actually wrong by country.
Allow street split without base_address_extended; all EDIs can now be
used with or without base_address_extended.
Merged base_address_city into base_address_extension, to avoid creating bridge
modules for no reason. Uses city_id instead of city if the country of the user
defines it AND if enforce_cities is set on this country.
Improved post_init script for large databases.
Split of street removed on res.company. (not required by any l10n)
[IMP] l10n_cn_city,l10n_nl,l10n_cl,l10n_co,l10n_pe: base_address_extended improvements
l10n_cn_city defined cities but did not provide a means to edit the city_id, so enforce_cities
l10n_nl only requires street names and numbers and thus does not need to depend on base_address_extended
l10n_cl should not depend on base_address_extended as none of the features are used
l10n_pe improve the view
l10n_co remove base_address_city dependency - move to l10n_co_edi
closesodoo/odoo#81710
Related: odoo/enterprise#23108
Related: odoo/upgrade#3129
Signed-off-by: Laurent Smet <las@odoo.com>
Bug
===
Since cd8e0e9f46 the filter "no_share"
has been renamed to "filter_no_share", but the context key
"search_default_no_share" has not been updated in the other views.
closesodoo/odoo#83048
X-original-commit: 131b366e8d841fe7b8d2325941ea8518bcf998a7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Description of the issue/feature this PR addresses:
duplicate mandatory field in popup when save the contact record.
Current behavior before PR:
Its showing same field name twice in popup which asking invalid fields.
Desired behavior after PR is merged:
it should show 'name' field only once.
Fixes#79753closesodoo/odoo#81727
X-original-commit: eb4b49e7078f4aa90f9d652de10386da38ded2dc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Damien Bouvy