This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.
Steps to reproduce the bug:
- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.
This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.
opw-3233684
closesodoo/odoo#121464
X-original-commit: eae10f2e154a1b6bf9f385460b1371faf9869a3f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Before this commit, there were cases where toggling the grid mode did
not work correctly. These cases are:
- when a snippet has None columns (e.g. Cover) and that an inner snippet
containing a row (e.g. Form) was dropped into it,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner snippet containing a row was dropped in this outer
content,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner content (e.g. Alert) was dropped in this outer content.
The first two cases happen because the row that was taken into account
when toggling the grid mode was the first `.row` element found in
general, instead of only considering the container children. Therefore,
what happened in these problematic cases is that the row found was the
inner snippet one, which should not be the case and caused the toggle to
fail because it was trying to put the element inside itself.
The third case happens because the `div` elements were excluded when
placing the outer content in a column, instead of only excluding the row
element.
This commit fixes these issues by only considering the container
children when looking for the row element when toggling the grid mode,
and by filtering out only the row element instead of every `div` when
creating a column for the outer content.
task-3279191
closesodoo/odoo#121393
X-original-commit: f94fe1d40f05a8dbb42f0f2a95d3fff68a3af0ec
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, input size of thread name was bigger than
the description one. This happens because the input is sized
according to the font size, and the thread name was bigger due
to `lead` classname.
This commit fixes the issue by reducing the padding of input of
thread name input, so that both input have the exact same height.
Part-of: odoo/odoo#117357
1. show hover effect in discuss sidebar
With redesign of web client style, hover effect in discuss sidebar
was not longer working.
This comes from buttons hover effect no longer having precedence
to defined bg classnames, e.g. `bg-100`.
This commit fixes the issue by explicitly defining a style for the
background when hovering items in the discuss sidebar.
2. improved background color of discuss app in dark mode
The background color was too dark. This commit fixes the issue by
using `bg-view`, which is the preferred background to put
content in both white and dark theme.
3. Send button visual matches composer rounded border
Send button lacked its border. This commit fixes the issue by
including Send button inside the element that does the pretty rounded
border of composer. That way, the border of send button will not
longer be affected by change of button style.
Also make the send button active / inactive state more visible, by
using button link (green when active, muted when inactive).
Part-of: odoo/odoo#117357
1. Display avatar in top bar next to channel name and description.
2. Edit icon appears on hover.
3. Clicking on the Edit icon opens file browser to upload a new avatar.
4. Certain file types are allowed.
5. Avatar can only be changed for group chat by any member of the channel.
6. For channel it can be done with admin rights.
7. Disable uploading text from file uploader in this case.
Also show avatar of channel/chat conversation in chat window.
Author avatar in message list no longer shown im status.
Chat window header color matches new systray color.
task-2684679
[FIX] mail: make chat window header match systray color
Part-of: odoo/odoo#117357
Before this commit, when the user is colorblind and sees the kanban
view of project.task, he cannot see the difference between
`Changes Requested` and `Approved` options and so he has to
alternatively open the form view to make sure that they are reading
it right because no check mark appeared in the dropdown to know
the current option selected.
This commit changes the icon of `Changes Requested` state option and
also adds the check mark in the dropdown options of the state field
to show which option is the current one.
task-3287326
closesodoo/odoo#121427
X-original-commit: 5e477356d2498cb0692f869053531082b4e7618f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Step to reproduce:
1. Set up Cash rounding for Tax: Accounting> Configuration > cash
rounding
2. Set up recurrent product: Service type - Prepaid - tax VAT 7.7
3. Create an order with that product - set price of 45 (to have the
rounding) > confirm order > Create an invoice
4. In the new invoice > "Other info" tab > add the rounding method
5. Change the quantity
Current behavior: tax doesn't update if there is a rounding line
Expected: tax should be updated.
Why:
What happens is that odoo trying to update the new tax amount on the
wrong line (the rounded tax amount line).
That's because the `existing_after` dict is poorly defined. It is
defined by the `existing()` inner function of `_sync_dynamic_line`
thanks to the "tax_key" of each line.
The two account move lines (VAT line and rounding on the VAT line) share
the same tax_key, and because of that the VAT line is overwritten by
the rounding line in the dict returned by`existing()`.
Then the cash rounding is recomputed from the VAT line(that still holds
the outdated values) and overwrites the updated values on the rounding
line.
Solution:
Adding the type of line in the tax_key to differentiate between a VAT
line and a rounding VAT line
opw-3224743
closesodoo/odoo#121426
X-original-commit: c27236d49d4f60940d79471e0ae66a0aed3c572d
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Sales profit tax witholds should not affect the tax report 103, it should be empty
closesodoo/odoo#121317
X-original-commit: 2dd8dd999b93dafdee5054beb71a7348eaec4eb9
Signed-off-by: Josse Colpaert <jco@odoo.com>
To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised
Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server
Solution
========
catch `TypeError` to raise a UserError
opw-3285540
closesodoo/odoo#121313
X-original-commit: 5053620c640136025f5b37c5b8d233ad63825389
Signed-off-by: abla001 <abla@odoo.com>
When inside an HttpCase, the end of a successful request will
`signal_changes` meaning that the registry_invalidated flag is removed.
A second issue is that this flag is thread local meaning that if a
request set the flag, it won't be visible from the test thread.
For those reasons, this commit ensures the registry sequences are
incremented as in production mode, and adds a check that the sequence
didn't change during the tests, calling `setup_models` the registry
manually if needed.
closesodoo/odoo#121268
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Step:
- Create a product with sale price 120 USD
- Create a giftcard with balance 40 uSD
- Create a free Shipping cost of 40 USD fixed price and freeing above 100 USD
- Go to website->shop, select the product and checkout the cart(the shipping is free because price exceeds 100)
- Add the gift card to payment
Issue:
The shipping price gets from free to 40
Cause:
When computing the cost of the shipping the fact of the presence of a giftcard is not considered.
Solution:
Create a method to returns the amount of giftcard from a sale order and add to total price to check if the shipping is free
opw-3107284
closesodoo/odoo#120174
X-original-commit: c57184fd1c3d2846df4f618dee0027364eb62596
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
- Unable to do global discounts because the `Discount` product isn't
`Available in PoS`. The available in pos paramater of the `Discount`
product in the data has then been set to true.
- The attribute `tip_product_id` gets as default the product of default_code TIPS.
- The condition of the display of tips option in pos payement has been
changed to the boolean corresponding to the tick box of the settings and
the `tip_product_id`.
- Before, if a tip product was set and the tips
option in the setting unselected the tips was still availible in the pos
payement since it was based on the tip product id and not on the tick
box. However, the `tip_product_id` still remains in the condition since
it can be possible to check the option and not select a tip product.
Task-3283007
closesodoo/odoo#119324
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the user configures PayPal/Alipay and in his PayPal/Alipay account he set
the IPN address to the webhook_url he receives a notification from PayPal/Alipay
with data. Then origin of that notification is checked and when PayPal/Alipay
sends 'invalid'/'false' as a response the error occurs.
To fix this issue the log is updated into a warning.
sentry-4116633764
closesodoo/odoo#121476
X-original-commit: 100f2526e91d781a01d959d08dc0ccfae4389061
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>
Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.
Bonus point: tests no longer need to be imported in the `__init__.py`
file.
closesodoo/odoo#121453
X-original-commit: ed1b27dbdfc0a5084051c59da9c4578262b3bf8c
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
Currently, when a specific capacity is defined for a product in a
workcenter, if a setup / cleanup time is given, it will be added to the
existing setup / cleanup time of the workcenter.
What we want instead is to be able to fully define what the
setup/cleanup time is for this specific product. So the given times in
the specific capacity override the times defined in the workcenter for
that specific product.
To help with that, we set the workcenter's setup/cleanup time as a
default for their related specific capacities, since if not changed,
they will follow the workcenter times.
Updated the tests so their specified capacities match the new behaviour.
closesodoo/odoo#119212
Related: odoo/upgrade#4576
Signed-off-by: Tiffany Chang <tic@odoo.com>
In 14.0 the menu items in the navbar sections menu could have any level.
Since the webclient refactoring landed in 15.0 0573aca this feature has
been unintentionnally limited to two levels.
More sub menus would simply not be displayed.
**Before this commit**
- Have a menu item with the following path:
`App/Menu/Group/Sub-group/Item`
- The `Sub-group` is displayed as an item. It is clickable but nothing happens.
- The `Item` is not displayed.
**After this commit**
Works properly as it should. See screenshots on the PR description.
closesodoo/odoo#121422
X-original-commit: 708d17ba3a9d12e153069ecb7ae6c8e3d6187dd0
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, the moved tours were added to the common and
frontend bundles, and were thus loaded all the time even though
they only exist for testing purposes.
This commit moves the two files to the correct bundle.
closesodoo/odoo#121408
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This test has been adapted by the milk PR, but it only passed with
all modules installed, because it relied on some items added to the
action menu. This commit makes it more robust by changing the
selector to target the "Delete" item.
closesodoo/odoo#121435
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The test test_04_pl_reset_on_login is failling determinstically
when run on a database with only `website_sale` installed, or in
some specific branches/setup (e.g. l10n nightly tests)
This commit makes sure the test works fine when only website_sale
is installed and also restricts more the test environment to make
sure data from other modules does not impact its behavior.
Finetuning of a9339c24591e4fcfe86f457accabb43050d2fe27
closesodoo/odoo#121428
X-original-commit: 929d71ccb6f180903fd30d53eeb627f2d81f5c7a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Bug:
When the `sale_loyalty_taxcloud` is installed and 'Lock Confirmed Sales'
is enabled, confirming a SO impossible.
Setup:
- install `sale_management` and `sale_loyalty_taxcloud`
- activate Taxcloud (with test credentials)
- enable 'Lock Confirmed Sales' in the settings
Steps to reproduce:
- create a quotation, fill the necessary fields and add a product
- in the 'Other Info' tab, set the fiscal position to
'Automatic Tax Mapping (TaxCloud)'
- attempt to confirm the quotation
You should be met with a message stating that you can't modify the tax
on a locked order.
Cause:
This issue was introduced by odoo/enterprise@ea954b818b
Enterprise PR: odoo/enterprise#40880
opw-3289657
closesodoo/odoo#121410
X-original-commit: d676498902adf2dcd8fa4530fc21e84fb940aad2
Related: odoo/enterprise#41060
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Prior to this commit, `o_navbar` wasn't fully hidden when we were in
edit mode and created an offset at the top of the loader when we loaded
something (eg. changing the header template).
This commit fixes this issue.
task-3326604
Part of task-3326263
closesodoo/odoo#121387
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
sale_product_configurator: not store product no variant attribute value
on the sale order line if there is a single product attribute value on
the product template attribute line.
Before this change, product no variant attribute values were not
displayed on the sale order line if there was only one product attribute
variant on the product template attribute line. This behavior was
altered in 7e42f381c3 when product configurators were migrated to Owl.
This commit ensures that when there is a single product attribute
variant on the product template attribute line, product no variant
attribute values are not displayed on the sale order line.
closesodoo/odoo#121265
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
The cookie policy banner template includes nested selectors, such as
o_cookies_bar_text_policy within o_cookies_bar_text_secondary.
The process for switching the banner layout involves copying selectors
based on the order defined in CookiesBar::selectLayout()::selectorsToKeep.
However, a bug caused o_cookies_bar_text_policy to be copied before
o_cookies_bar_text_secondary, resulting in its content being overridden
by its parent content. The fix involves reordering the selectors so that
o_cookies_bar_text_secondary is copied before o_cookies_bar_text_policy.
opw-3302511
closesodoo/odoo#121324
X-original-commit: 720ae005bce261ce3b9e32dc8ade1f1d97f1aee1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, after [1], when a user is trying to visit or view
their website from a domain that is not their current website, a
traceback would appear if the redirect took too long.
This is because when redirecting, we do not set any URL as the iframe
iframe source, so it loads the `about:blank` page. When trying to push
that page into the history (done to change the name and url displayed in
the browser), the browser crashes and displays a CORS error.
On top of that, it seems some users do not understand what is happening
and feel like they are being logged out if they're not logged into their
custom domains.
This commit prevents replacing the history state if the page displayed
in the iframe is `about:blank`.
It also displays a dialog before redirecting, explaining to the user why
it is necessary.
Steps to reproduce:
- Go to website settings
- Set a domain for your website that's different from the one you are
currently using to access Odoo (Could be anything but for a realistic
setup, if accessing from localhost, use 127.0.0.1 or the other way
around, or use different 127.0.0.X ips)
- Toggle a slow network mode from your browser's dev tools
(This is to ensure the traceback appears as it does not if the network
is quick enough with its redirect)
- Go on the website app
=> A traceback appears (and disappears as the page is unloaded)
[1]: https://github.com/odoo/odoo/commit/59b96b0742fe8da31eecf896f7a6157811d49de5
opw-3250663
closesodoo/odoo#121311
X-original-commit: 15a31cbcec9f51c72abac8df69932cc1a742baef
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, starting this test individually would not work as
the admin user is subscribed to the mailing list used during the test.
The reason the test has passed our test suite is because on runbot the
`mass_mailing_sms` module is installed, which adds a new mailing list to
which the admin user is not subscribed.
This commit changes the test to always ensure that the admin is not
subscribed to any newsletter, making the test a bit more robust.
closesodoo/odoo#121200
X-original-commit: f7465d0f13236518ee79e43e65222d0ca0c0b0fb
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Some of the Editor methods relies on not having inline elements at
the editable root. For this reason, the cursor should never be placed
at the editable root, but always inside a block element.
Before this commit, in some situations (notably around tables and
horizontal separators), the cursor could be placed having its anchorNode
at the editable root, allowing the user to insert inlined text at it.
This commit fixes the selection range in such cases, and an empty paragraph
is inserted in cases where there would be no other way to insert text before
or after an existing block.
task-3128747
opw-3106752
Part-of: odoo/odoo#119556
The `isVoidElement` utility function has a misleading name, and the need
for an actual list of void elements arose.
This commit replaces the `isVoidElement` utility by two functions:
- `isArtificialVoidElement`: returns true for elements that we decided to
treat as if they were void elements. This method is used to decide whether
they should have their "isContentEditable" attribute set to false.
- `isNotAllowedContent`: actual void elements + the ones above.
Part-of: odoo/odoo#119556
Since 15.0, it is no longer possible to have partnerless transactions.
Nonetheless, migrated databases could contain transactions without a
`partner_id` set.
This commit cleans existing rules to make those transactions are not
accessible to unwanted users.
We take the opportunity to clean the security of payment.transaction
records globally.
Now only admin and accounting users have access to payment.transaction
records. The code of different applications has been adapted accordingly.
Task - 3102824
closesodoo/odoo#113515
Related: odoo/upgrade#4564
Related: odoo/enterprise#40939
Signed-off-by: Masereel Pierre <pim@odoo.com>
The tax 21% ISP actually behaves like a normal 21% tax
(it gets reported in the same lines, ...)
But the reason for its existence is that in case of the
fiscal position Revendedor ISP... it gets mapped to the
0% ISP tax (which needs to be 0)
Before, if you would however send a 21% ISP tax to the SII,
it would be set as ISP and you would get an error telling
that the tax rate should be 0 in case of ISP. (but now, it
will be reported as S1 and not trigger the error)
See also discussion in
https://github.com/odoo/odoo/pull/119339#issuecomment-1519720558closesodoo/odoo#121400
X-original-commit: 909fcbee95d0d9e69b4b91916f075a6724c09bda
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.
closesodoo/odoo#121396
Sentry: - 4075426049
X-original-commit: ac2a3966cb035f112bf6aebb1244dc8d67831d1a
Signed-off-by: Rémy Voet <ryv@odoo.com>
The shortcut to refuse an application is overridden by the shortcut to
move the record to the next statusbar stage
Steps to reproduce:
1. Install Recruitment
2. Go to Recruitment > Applications > All Applications and open any
application
3. Press and hold `alt`
4. The hotkey for the action 'Refuse' is shown (`x`)
5. With the `alt` key held, press on `x`
6. The application goes to the next stage instead of being refused
Solution:
Change refuse hotkey to `d`
Problem:
Commit https://github.com/odoo/odoo/commit/76b513917b4dad6eeecb4decac24e8c2d2c75b00
introduced a shortcut `alt+x` to move the record to the next state in
the statusbar. Because this shortcut has been chosen for its similarity
with shortcut `alt+shift+x` (Move to %s...), we prefer to change the
hotkey to refuse an applicant
opw-3206744
closesodoo/odoo#121395
X-original-commit: 37a9d552a5d581f14fd59728ea539726b1387f0b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
pos*: point_of_sale, pos_restaurant, pos_sale
Previously the pos would rerender the entire UI when the window was
resized. In practice, most components do not care about the size of the
UI for their rendering, and so we're doing a lot of needless work, and
also using an owl feature (deep renders) whose perennity is not certain
(we may want to remove the ability to do deep renders completely in the
future).
This commit changes the pos code to use the ui service `isSmall` field,
makes the ui service reactive so that components can subscribe to
changes inside of it with `useState`, and makes the ui service update
its internal state at most once per animation frame, instead of after
100ms without resizing, so that resizing the viewport results in a
smoother user experience.
closesodoo/odoo#121343
Signed-off-by: adgu-odoo <adgu@odoo.com>
This PR aims to change the target of the email widget to _blank. Indeed depending on
your mail provider, it can open the mail editor in your current tab and might not be
practical for the user if he needs information that was present on the previous tab
to compose the mail.
task-3324948
closesodoo/odoo#121277
Signed-off-by: Luca Vitali <luvi@odoo.com>
The fact that callback recorders are put in the env by the action
service has a serious disadvantage. A view using itself some View component
can have easily its own local state and global state polluted by that
subview (views use useSetupView). This would lead to very subtle
problems hard to detect and understand. Moreover, we view the callback
recorders as rather technical stuff and we would like the developers not
to have to think about them. For that reason we pass the callback
recorders as (optional) props to the View component that make them
available in the env. Note that the situation remains unchanged for
client actions (we do not have a View analog component for the actions).
closesodoo/odoo#121050
Related: odoo/enterprise#40901
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before the PoS tours were mainly run with the `accountman` user, which
did not allow us to have a clear view of the permissions required for
each function of the Point of Sale.
Now, two users have been created for the PoS:
- `pos_user`
- `pos_admin`
The first one has no particular permission, he is a normal user of the
Point of Sale and Odoo, the second one is an administrator of the Odoo
application.
If the user `pos_user` is used and some permissions are missing in a
tour, these are added to the user with starting the test.
closesodoo/odoo#120380
Related: odoo/enterprise#40656
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit allows to share spreadsheets to other users (public, portal or
internal without the required access rights)
See Enterprise commit. This commit prepares the ground to sharing
`documents.document` spreadsheets.
(I expect dashboard spreadsheet sharing in the near future which will
use the same generic code)
The challenges of sharing odoo spreadsheets
-------------------------------------------
Odoo spreadsheets can have any data from the database.
ODOO.PIVOT and ODOO.LIST functions specifically can target *any model*
and *any field*.
The values are dynamically loaded with RPC calls when the
spreadsheet is open. Normal access rights apply to load this kind of
"embeded" data.
A user can open a spreadsheet if he can read the `documents.document` record,
but odoo specific functions might result in errors if the user doesn't have
the access rights on the underlying model.
That's obviously not what we want when sharing a spreadsheet to an external
person. We want this person to see the values and not a spreadsheet full
of errors.
Giving access to external user?
---------------------------------
Users must have a very clear understanding what they are "leaking" when
they share a spreadsheet. Sharing a spreadsheet should not open any door
the user wouldn't think of or wouldn't understand.
The best way is to be very strict with the data we are sharing.
That means: only the specific models, specific fields and specific records
visible in the spreadsheet by the user who is sharing (different users can
see different values for the same spreadsheet, depending on their access rights).
We also want to consider the following scenario:
Alice is a newcomer (with very limited access rights) and she shares a
spreadsheet to a customer. A few years later, she is manager and has a
lot more access rights (groups, ir.rules, etc.).
The forgotten spreadsheet shared years ago should not leak more data because
Alice now has access to all company data.
Specification
=============
With all those challenges in mind, here is a first approach of shared
spreadsheet:
Readonly freezed spreadsheet for external users
-----------------------------------------------
When sharing a spreadsheet, we actually copy and freeze the spreadsheet at that
time. Odoo formulas are replaced with their value. This is the easiest and safest
way to deal with access rights to other models: there's no access to other
models at all ^^
The spreadsheet is displayed in readonly since it would only be editing a copy.
If the external person wants data to be updated, he can ask a new sharing link.
Read/Write for internal users
-----------------------------
The situation for internal users is different. We can rely on their actual access
rights.
When an internal user opens a spreadsheet sharing link, he is redirected to the
regular spreadsheet client action. A token is used to read/write the
`documents.document` record (and other linked models such as `spreadsheet.revision`),
but the data for pivots, lists, etc. is loaded with the user's own access rights.
If the user doesn't have the rights to read a model or field, the function results in
an error and that's the expected behavior.
This sharing strategy is perfectly fine for all spreadsheets that doesn't contain
any odoo data (think of all the Google Sheets we receive internally by email to
register to an event or any other stuff).
Future work
-----------
From a functional point of view, the spec is far from perfect.
Users would probably expect the data to "update" itself (not freezed).
People will want write access for external users as well.
Given the complexity of getting it right (from a tecnical, security and functional POV),
this is left for a later work
closesodoo/odoo#114040
Task: 3045808
Related: odoo/enterprise#37687
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When importing data and checking the possible values of a field,
clicking on one of the records to open it throws an error
Steps to reproduce:
1. Install Projects
2. Go to Project > My Tasks and trigger the list view
3. Select any record and export it (check the import-compatible export
option)
4. Open the exported file and modify the `project_id` to a non-existing
project name
5. Click on Favorites > Import records
6. Upload the modified file and click on 'TEST'
7. In the `project_id` field, click on 'See possible values'
8. Click on any project, an error is thrown
Solution:
Prevent the form from being opened when the action is in target "new"
Problem:
Opening the record in a target new throws the error `switchView
called but the current controller isn't a view`
opw-3161777
closesodoo/odoo#121384
X-original-commit: 63d43713ea5b2efba2e63b1735954bb2069bc6f4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, the <hr/> in Discuss and Chatter
were not visible.
These <hr/> had no height but had a border. The border showed the
separator.
With the redesign of web client, <hr/> now have opacity of 25%.
This combined with borders being lighter made these separators
barely visible.
This commit removes border on these <hr>, which makes them use
their default visual, which is the same as a border.
closesodoo/odoo#121378
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
== ISSUE ==
The search component is using a `.bg-200` class which renders a grey
darker than the one of the `o_web_client`. Since we already define
a `background-color` for the web client, we do not need a custom one
on top of it.
== After this commit ==
We remove the `bg-*` class applied to the element so it matches the
`.o_web_client background.`
task-3326289
part of task-3326263
closesodoo/odoo#121347
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Benjamin Vray