It was missing the bootstrap form-check class
closesodoo/odoo#102321
X-original-commit: 4218a3ed6022032577c2764deefa7923db32cf89
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the usage of the `CSS Grid` some view are broken.
The new form view system is less tolerant to missing colspan.
This commit, change the colspan when needed (e.g. no label) and in some
case extract the label outside the `DIV` to use `GRID` layout.
Steps to reproduce:
* Go to survey
* Select a survey
* Select the Option notebook, fields are not aligned => BUG
* OR
* Click on Add a question
* list view in Answers notebook are not aligned => BUG
closesodoo/odoo#102319
X-original-commit: 51c1f6ed300e3dd185c45e14dff1ee9250f6e562
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
When [1] introduced the website edition using an iframe, it did not
correctly adapt url attachments redirections.
Following this flow, in the Website Builder:
- From the Media Dialog, click on the "add document" top right button,
- Paste a google doc url and save,
- Click on the inserted document icon,
=> The google doc is opened inside the iframe (it leads to tracebacks).
This commit fixes the way these documents are opened from the
Website Preview iframe: '/web/content/...' links are always opened in
the top window, as they can be external redirections.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2172311
closesodoo/odoo#102318
X-original-commit: c05f7de22600b5719117a188ab105e4140b6a3de
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
The accounts setting allows to have default taxes on accounts, but
they are not used when changing the account on an account_move_line.
closesodoo/odoo#102313
X-original-commit: ed40e71aa879b9f42e7acbe35647a88388afc107
Signed-off-by: William André (wan) <wan@odoo.com>
Allow users to use stacked line charts. The chart.js configuration
is mimicking the one inside Odoo community.
task 2888350
closesodoo/odoo#102312
X-original-commit: 1ccb2cd685c60eecd767eb15967d4b4c25262ded
Related: odoo/enterprise#32345
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Always generate a Factur-X xml and embed it when a PDF is created. But no edi.document
is created, no warnings will be displayed on the invoice, and the PDF is not PDF/A-3.
The only purpose here is the Odoo interoperability.
Rename the 'Factur-X' option to 'Factur-X PDF/A-3' and make it only visible for FR and DE companies.
This 'Factur-X PDF/A-3' option will trigger the regular account.edi flow: create an edi.document
and show warnings on the move if errors are detected. When a PDF is printed, embed the Factur-X xml
and make the PDF a PDF/A-3. Thus, it can be used on Chorus Pro.
task-2957808
closesodoo/odoo#102311
X-original-commit: 25d4635d544a0a48ac937b35c996f2cbdb8073ec
Related: odoo/enterprise#32344
Related: odoo/documentation#2789
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
With sequence gone, the lines are now ordered incorrectly in the simplified LU tax report.
Reordering the lines correctly.
closesodoo/odoo#102310
X-original-commit: 3a5cfeb0806bbfe5245c740378883eaf8618d743
Related: odoo/enterprise#32343
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
This commit fix the following issues :
- When an event don't have a color provided, the first color was used.
The issue with this, is that that color can be used with another
filter. Now, a neutral color is used to avoid confusion.
- The filter that don't provided a color, will also use a neutral color,
to keep harmonization with the color of the event.
- The color of the current user, was missing on the user filters.
- The color attribute set on the view was taken instead of the color
attribute set on a field when the field is set as filter, which
leads to a traceback.
closesodoo/odoo#102307
X-original-commit: c83379f68f395004e1750336ced8a4a4132f67fe
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
If the components of the manufacturing order are in done or cancel
state you should NOT define the status of the manufacturing order as done.
It should only be set as done if components and finished moves are done/cancel.
TT38551
closesodoo/odoo#102273
X-original-commit: 8cc7af8af300829e25033781673b7c071dd57638
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When duplicating a location, it is currently confusing to know if we're
now updating the duplicate or the original.
Adding a (copy) to the `name` after a duplicate will make it easier to
know which location we are currently updating.
Part of task-2985735
closesodoo/odoo#102244
X-original-commit: 177c50076e175a1d607a9aae87aee8307709f71c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When converting the list view to owl, the support for view widgets was
overlooked as this feature is not used very extensively and was not
tested.
This commit adds support for them and adds a test for it.
closesodoo/odoo#102193
X-original-commit: 9098c1d3cd4af8f324b5b09668e92822575f932d
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
With version of urllib3 in ubuntu 22.04 (1.26.5) and with version of firebase_admin between 2.17.0 and 4.5.2 a gives the following
warning:
In firebase_admin/_http_client.py:30: DeprecationWarning: Using 'method_whitelist' with Retry is deprecated and will be removed in v2.0. Use 'allowed_methods' instead
It has been fixed in later version
https://github.com/firebase/firebase-admin-python/pull/532 since v4.5.2
closesodoo/odoo#101731
X-original-commit: 66934cde91843a90b99ec02557b41cb68c281119
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Currently, the "kanban compiler" parses the XML and post-processes all
dropdowns defined in the view.
This commit adds a "kanban_ignore_dropdown" class, allowing to ignore this
additional post-processing if one wants to add simple dropdowns within his
kanban cards that are not transformed by the compiler.
This will be useful notably for the social_twitter kanban where we use a
regular dropdown to show re-tweet options.
Task-2855647
closesodoo/odoo#102314
X-original-commit: 263ba9bae78f692ea84a85202e27e530af1c4f8e
Related: odoo/enterprise#32346
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Currently since the input has no name we can't
retrieve the file when using FormData instance.
This commit allows the developer to pass an input
name when instanciating a FileUploader component.
Task-2855647
X-original-commit: 33bc32c52bef4787ae2e529f05837c2f7dbddc7f
Part-of: odoo/odoo#102314
The financial account must be editable until a journal items is set, which wasn't the case before this PR. I also switched the two fields so that's more logical for the user.
closesodoo/odoo#102309
Task-id: 3006879
X-original-commit: 5cc72bb6d6f9a04ec32e47d02ebfaf8e12aba559
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
There was an option in the legacy ModelFieldSelector
that could be used to prevent following the relations.
This option was lost since the widget has been
converted. This commit simply reintroduces the option.
closesodoo/odoo#102308
X-original-commit: 673faab4dec7a0df434cf0575303df97a36db0f1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.
Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.
Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.
opw-2745014
closesodoo/odoo#102257
X-original-commit: ceb244d31a72ad826e841dfd06b7e1ed59f2c994
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
If the decimal separator of the currently selected language is a comma,
exporting data in an xlsx would use a wrong float format
Steps to reproduce:
1. Install Invoicing
2. Go to Settings > Languages, add 'French / Français' language and
switch to it
3. Go to Facturation > Fournisseurs > Factures
4. Export the data (there should be at least one amount with a decimal
part)
5. The decimal part of the amounts is not displayed
Solution:
Always use the same decimal separator to print in the xlsx as we can
only use a dot as a decimal separator (the comma is used as the thousand
separator). The value will then be displayed to the user according to
his OS regional settings (see https://xlsxwriter.readthedocs.io/format.html#number-formats-in-different-locales)
Problem:
When using a comma for the float format, we actually specify the format
of the integral part of the number (the thousands) without displaying
the decimal part (which is represented with the dot)
opw-2965984
closesodoo/odoo#102255
X-original-commit: 21efa4f18266a5c5c57157035c2357ed3e147a69
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
After the update of the bootstrap lib, the kanban records to be found in
the menu Project Stages of Project > Configuration (after activation of
a setting option) had each two weird borders. Here, we simplify the
kanban-box template in order to get only one border as it is in 15.0.
closesodoo/odoo#102249
X-original-commit: 839bdd0a853f88bfaeb0dd698d60e2168dc54188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The condition that determines whether to display the tax base was wrong
It should be displayed when either condition is met:
- There are multiple tax base amounts
- The only tax base amount is not the same as the untaxed amount
Note that this last case may happen with cash discounts
closesodoo/odoo#102247
X-original-commit: a8ff4b876c8ab48177795e6ace1bb1361744c8a7
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
Since the usage of the `CSS Grid` some view are broken due to too much
CSS rules conflicting together.
The new form view system is less tolerant to missing colspan.
This commit, change the colspan when needed (e.g. no label)
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Some fields on the form view (in panel) are not aligned => BUG
closesodoo/odoo#102246
X-original-commit: 4813d1ebd4295c8be7ee6b6a892604f15cc43fce
Related: odoo/enterprise#32320
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit, excludes the first separator from the selector to avoid too
top space.
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Click on the Price tab
* The separator on the right is misaligned => BUG
X-original-commit: 0e0a2014b31e2fc6423e80971ac451a2dfe89de9
Part-of: odoo/odoo#102246
This commit, excludes X2Many list from the selector to avoid to use
negative margin when we are in a group.
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Click on the Price tab
* The X2Many list is misaligned of the group => BUG
X-original-commit: d718ee455c05c0df419f66c0a884207322199282
Part-of: odoo/odoo#102246
Purpose
=======
Check the existence of the relational properties (many2one / many2many) in
batch and prefetch the values in batch as well to reduce the number of SQL
queries.
Allow to add the properties field in the kanban view. An option has been added
in the property definition, "View In Kanban", to decide which field must be
visible in the kanban view. This is useful when having several properties
and to avoid cluttering the UI.
This merge also contain some fixes, see sub commits for more details.
Task-2965523
closesodoo/odoo#102243
Forward-port-of: odoo/odoo#101417
Related: odoo/enterprise#32318
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The debounced timeout is useful for the auto complete when it's used for
many2one and many2many because it makes RPC calls.
But for the property tags, we don't need this timeout and it will make
the component more reactive.
Task-2980121
X-original-commit: 9701738365c50e911cb704807c929fbbb4b43c43
Part-of: odoo/odoo#102243
Bug
===
In knowledge, when we move for the first time a property, the popover
position is wrong. The technical reason is that the component DOM is
updated one time before the props changed, and so the DOM is not
up to date when we compute the new position.
Also, the popover might change it's relative position (top VS bottom)
and so the small arrow might be incorrect in that case. Always remove
it (rectangle popover better than a wrong arrow direction).
Task-2980121
X-original-commit: de37a3393b31d48add36fc6be5febf70dc3db31e
Part-of: odoo/odoo#102243
Purpose
=======
The style of the standard field has been changed due to the
"edit only" form view. Adapt the properties field style to match
standard field.
Fix a bug where the autocomplete of the many2many / tags is
displayed outside of the screen.
Change the external link icon to match the new one on standard many2one.
Task-2980121
X-original-commit: 0c8e4c03529d4306be295a59d987576ff2cab490
Part-of: odoo/odoo#102243
Purpose
=======
Allow to add the properties field in the kanban view.
An option has been added in the property definition, "View In Kanban",
to decide which field must be visible in the kanban view.
We need an option because in practice we might have a lot of
properties, and it might break the view.
Task-2980121
X-original-commit: 3af5a59c23183dd43341c1952a04354acbf3a60d
Part-of: odoo/odoo#102243
Purpose
=======
Check the existence of the relational properties (many2one / many2many)
in batch and prefetch the values in batch as well to reduce the number
of SQL queries.
Technical
=========
The existence is checked in the read method of the properties field,
because we have the entire recordset. Then, the non-existing ids are
remove from the properties values and the cache is updated.
Task-2965523
X-original-commit: dba9b684d29c0041a32a5508284573851b8dd097
Part-of: odoo/odoo#102243
Before this commit, when we go to a Task. Click on the Tags field
> Search More. Group by Projects.
We get a list of projects groups. Click on them and they go from
(x) to (0) due to invalid group result from read_group without
valid domain same as search_read.
So in this commit, override the read_group method to pass the valid
domain same as search_read.
task-2959382
closesodoo/odoo#102236
X-original-commit: f9e9964c7138485ba328ce5cd4c4c8905c392adc
Signed-off-by: Xavier <xbo@odoo.com>
pivot, graph, cohort views do not care to know whether a field
is readonly or required, as you cannot edit records in these views.
Even kanban is readonly in most cases:
- you can drag and drop records from one column to another,
which is prevented if the group by field is readonly
but this shouldn't rely on the fact the field is
within the architecture, as you can group by on any fields
from the search views / control panel.
Hence, this shouldn't rely entirely on the modifiers passed on the field
nodes in the view architecture alone.
- you can create new record inside the kanban,
with a simplified form, thanks to the `quick_create`,
but this uses an independant form view, in which the readonly and
required modifiers are correctly passed.
So, `modifiers="{'readonly': true, 'required': true}"` can be dropped
for kanban views as well.
This allow to spare some KB by not setting useless modifiers in views.
e.g. CRM > My pipeline pivot
Before
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row" modifiers="{"readonly": true}"/>
<field name="stage_id" type="col" on_change="1" can_create="true" can_write="true"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true, "readonly": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
Regarding the change of behavior shown in `addons/web/static/tests/views/kanban_view_tests.js`.
It was introduced very recently, by myself, in
odoo/odoo#100806
I revert this possibility to set readonly="0" on a field node in a
kanban view, because:
- First, this is not used anywhere in both odoo/odoo and
odoo/enterprise.
- Second, this really makes things harder if we want to do so:
- as readonly="0" is passed, the "readonly" gets removed from the node
modifiers, as they are simplified by removing falsy value:
modifiers="{'invisible: True, 'readonly': False}" becomes modifiers="{'invisible': True}"
- as readonly in not amongst the modifiers, it fallbacks on the model
field property, in the javascript code, which is readonly: True.
- the thing to do would be to still transfer "readonly"
from the field attributes to the node modifiers.
- which either mean to consider a kanban view as editable
- this will cause issues because the validation mechanism
will suddenly check the domain attribute property
https://github.com/odoo/odoo/blob/d4a92b112d0554a2624f7768feb7d54e0484469f/odoo/addons/base/models/ir_ui_view.py#L1443
and there will be plenty of views where some field used in the
domains will be missing. Besides it is pointless to validate these
domains as they are completely unused in kanban views
- either mean to find another mechanism than "editable" to decide
wheter to transfer the modifiers "readonly"/"required" or not,
which over-complicates things.
- besides only "readonly" would need to be passed, not "required.
So, to keep the code stupid simple, I remove this possibility added only
a few days ago, which is actually not used anywhere in standard for the
moment.
closesodoo/odoo#102221
X-original-commit: 69c3d5aa25655173ed66a52570559322c650c7df
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The rendering of the partner autocomplete widget has changed a bit since its
Owl conversion, the trigger needed to be updated to reflect that.
closesodoo/odoo#102220
X-original-commit: a8fce72e12836af95af883a08bdb74b6c0343c90
Related: odoo/enterprise#32310
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
The `field_partner_autocomplete` & `res_partner_many2one` widgets are now
converted to Owl.
It required some changes in the `Autocomplete` component as we needed to
access the ref of the `<input/>` element to pass it to the `useInputField`
of `CharField`.
The hook `useInputField` was also modified to allow passing a ref directly
as parameter instead of a ref name.
X-original-commit: 0b8c86bc5b19baccf7324fd4b18d438278816a5a
Part-of: odoo/odoo#102220
There was a small graphical bug caused by the `<ul>` element being
rendered even when no options were available.
X-original-commit: 32d87b2097e550b375bdc2098cdee6c669666a3a
Part-of: odoo/odoo#102220
This commit adds the possibility to change the product tag color on a product and also to edit those tags from a submenu of the ecommerce.
task_id=2904805
closesodoo/odoo#100717
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The session used to call this websocket route needs to have been
initiated with a call to /websocket/peek_notifications first.
closesodoo/odoo#102009
X-original-commit: 49aa391b4ef93b2de578c73a1fe852cea32abb43
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit converts `popover_widget`, `stock_rescheduling_popover`
and `mrp_workorder_popover` to OWL
closesodoo/odoo#101987
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
How to reproduce the problem:
- Install the purchase_requistion, purchase_requistion_stock, and any Localization modules such as l10n_be or l10n_in
(apart from USD currency any localization module)
- error caught only when at the time of module installation but it must have a different currency_id apart from USD
https://watch.screencastify.com/v/1C7GQKHBASyiluGGkFfV
Cause of the problem:
static values Currency USD cause the problem.
the following module will be set the currency value
l10n_be - EUR
l10n_in - INR
l10n_br - BRL
when we installed the following modules then cls.env.user.company_id.currency_id values get changes accordingly
will lead to this error
Traceback (most recent call last):
File /home/odoo/src/odoo/addons/purchase_requisition/tests/common.py, line 70, in setUpClass
cls.env.user.company_id.currency_id = cls.env.ref(base.USD).id
File /home/odoo/src/odoo/odoo/fields.py, line 1217, in __set__
records.write({self.name: write_value})
File /home/odoo/src/odoo/addons/account/models/company.py, line 301, in write
raise UserError(_('You cannot change the currency of the company since some journal items already exist'))
odoo.exceptions.UserError: You cannot change the currency of the company since some journal items already exist
opw-2945581
closesodoo/odoo#98512
Closes: https://github.com/odoo/odoo/pull/98174
X-original-commit: 70b7c57f7ea0a619a149461e0e738ddc25b822f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
- P1:
- Storable
- With a vendor V1
- P2:
- Storable
- With a vendor V2
- P3:
- Consumable
3. Edit V1:
- Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P2
- Product: P2
- Type: Subcontracting
- Subcontractors: V2
- Components: 1 x P3
5. Create a PO:
- Vendor: V2
- Deliver To: Dropship
- Drop Ship Address: V1
- Products: 1 x P2
6. Confirm the PO
Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).
In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.
Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)
So, because of the incorrect third condition, the condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.
[1] d73e70f22e47e81e59aff0c9f578aff260447256
[2] e6a1e240f1
[3] fd22fe221026e353aac7414348b029ae7e290b2f
OPW-2922546
closesodoo/odoo#102224
X-original-commit: a51b4158b964a11fa371a9eb8c877c9ec395f412
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Two dropdown were too small, it's now corrected by adding a new group.
closesodoo/odoo#102223
Task-id: 3006637
X-original-commit: 1a56ad9895f7b5b029a27cabdffbadba60cd87ef
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
This commit applies the same behavior between hovering an `o_input` and
a `note-editable` inside the form view
closesodoo/odoo#102205
X-original-commit: 43b1baf10bc004a2ac5d63990b9a65aab74cba9c
Related: odoo/enterprise#32304
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
This commit applies the same behavior between the community and the
enterprise for the `o_field_widget o_input:hover` effect.
Before this commit the hover on community applies a border on all
quadrant, now we only see the bottom border as in Odoo Enterprise
X-original-commit: 89d67a125fd8146d979c2b12ade1f4dbe5fc2441
Part-of: odoo/odoo#102205
Samuel Degueldre