Have a translatable field in a form view.
Create a new record with that form view.
Click on the button to open translations for that field.
Before this commit, the record was not saved before opening the translation dialog, hence
changing the translations could not work properly.
After this commit, this feature is back, and we ask to save a new record before
opening the translation dialog.
closesodoo/odoo#97608
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, images' url where just built upon the record's id and model.
Since the browser caches GET requests by url, the same record would always have the same image url.
Hence it appeared that when changing a record's image in form view, and going back
to the kanban, the image displayed was the old one.
A good enough approximation to solve this (and was actually solved in legacy code), is to use
the record's __last_update field, which basically tells the browser to re-fetch
a record's image when then record go through any modification.
After this commit, images are correctly updated in kanban and form views.
closesodoo/odoo#97544
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When a session is opened, the setting that allow using pricelist cannot
be modified, as it can change the prices that should be used, but
existing opened POS will still use the old one.
As the pos settings are now in the res config settings, each time a
setting is changed, all settings are re-written. As the use pricelist
setting is not readonly when a session is open, its value is sent, and
we try two write it (even if value not changed) and it trigger a
constraint saying it cannot be modified.
To avoid such a wrong behavior, we make it readonly when it cannot be
modified.
closesodoo/odoo#97731
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component
would not appear when printing a Sales Report
from the PoS backend.
To reproduce, go to PoS:
-> Reporting
-> Sales Details
-> click Print
Issue: The `BlockUI` component should appear on
top of the `Dialog` component, but it doesn't.
The reason for this is because, after some recent changes,
the z-index of 1100 that this component initially had, was
no longer applied, resulting at a lower z-index value for
the `BlockUI`.
In this commit we restore the normal behaviour.
task-2924335
closesodoo/odoo#97730
X-original-commit: 114fbe04eb92248118af46c8cbd137da7233aef9
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, the `BlockUI` component from
the web module was not rendered properly.
The reason for this is that after PR #83811 was merged,
the css from `web/static/src/core/ui/block_ui.scss`
was replaced with non-semantic Bootstrap css classes
(e.g. .d-flex, .justify-content-center). Those css
classes were inaccessible to PoS frontend, because
the `point_of_sale` module does not load Bootstrap
code (a design decision).
In this commit, we restore the proper rendering
of the `BlockUI` component both for the "frontend"
of the PoS App.
task-2924335
X-original-commit: 29cbeae90790ff503167b053ec6d9e221a82434e
Part-of: odoo/odoo#97730
The constructor of OdooEditor called a function that initialized the
Powerbox. This moves that function inline into the constructor to avoid
a function called only once, and moves the main commands and categories
directly into the arguments to `new Powerbox()`.
closesodoo/odoo#97725
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The BusService class only adds the possibilty to send notifications.
This is only used in the mail module. Let's remove this unnecessary
override and move this functionnality into mail models.
closesodoo/odoo#97685
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Running tests for `project` module only fails with the following error:
```
2022-08-02 08:19:41,777 5669 ERROR testdb odoo.addons.project.tests.test_project_report: FAIL: TestProjectReport.test_avg_rating_measure
Traceback (most recent call last):
File "/build/odoo/saas-15.3/addons/project/tests/test_project_report.py", line 22, in test_avg_rating_measure
self.assertEqual(self.task_1.rating_last_value, 5.0)
AssertionError: 4.0 != 5.0
```
With the ORM flush mechanisms when multiple ratings are created at once
they all have the same `create_date` and/or `write_date`, this commit
ensure the order is deterministic.
closesodoo/odoo#97691
X-original-commit: 567d27cc600bdbb39d62e7aa75b37d48b33d27a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The default order of the picking moves generated from a sale order should be the same order as the sale order lines.
Steps to reproduce:
- Create a sale order with several sale lines.
- Change the order of the sale lines.
- Confirm the sale order.
=> The moves of the picking don't maintain same order as set before.
closesodoo/odoo#97690
X-original-commit: 524e5e6bd8feb47256cc0941052d959dd0e0ad0c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In order to perform reverse charge self-invoicing, a company must have
its codice destinario (pa index) defined. This commit adds a valid
pa_index (from the sdicoop test channel) to the demo company.
closesodoo/odoo#97658
X-original-commit: 42c08b298dba5d4e34ed10ae4fd8828db9636a8a
Signed-off-by: Josse Colpaert <jco@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It is not possible to process an invoice and send it to the SII
Steps to reproduce:
1. Install l10n_es_edi_sii module
2. Switch to company 'ES Company'
3. Go to Settings > Invoicing > Spain Localization > Registro de Libros
connection SII and select 'Hacienda Foral de Gipuzkoa'
4. Go to Invoicing > Configuration > Accounting > Journals and open
'Customer Invoices'. In the 'Advanced Settings' tab, enable EDI
functionality 'SII IVA Llevanza de libros registro (ES)'
5. Go to Invoicing > Configuration > Spain > Certificate (ES) and import
the certificate (file named sello_entidad_act.p12 in
l10n_es_edi_sii/demo/certificates/) with password "IZDesa2021"
6. Create an invoice with any customer and product and confirm it
7. Click on 'Process now', an error is raised
Solution:
Use PyOpenSSL to be able to use certificate checking
Problem:
With the version of requests specified in the requirements, SSLContext
object doesn't have a `_ctx` attribute anymore. That's because PyOpenSSL
is not used by default (https://pyup.io/changelogs/requests/#2.24.0) and
ssl is used instead. However we need PyOpenSSL to be able to use
certificate checking (https://urllib3.readthedocs.io/en/latest/reference/contrib/pyopenssl.html)
opw-2925510
closesodoo/odoo#97655
X-original-commit: 1d76ab521ab7d457c6881181bdde557f520fd78e
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, it was possible to make the JS crash due to maximum
call stack reached due to some recursion between 2 field visibility.
It was then preventing the page to even be accessed as it is the 000.js
(public file) which is failing.
The only way to fix that is then to go through the backend.
Step to reproduce:
- Enter edit mode and drag & drop a form snippet on the page
- Select a field, let's call it field_a
- Set its visibility option in the right panel to "Visible only if" and
select another field as value, let's call it field_b
- Now select field_b and do the same operation and set field_a as value
- Save
After save, the 000.js file will be executed and the traceback will
occur, preventing the page to work at all.
Note that the illustrated example is about direct and obvious circular
dependency, but it could also be about indirect circular dependency like
field_a depends of field_b, field_b depends of field_c and field_c
depends of field_a.
opw-2889860
closesodoo/odoo#97652
X-original-commit: 90ecfab61f0c71850c1f3bc3ab2644883d18f9a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
How to reproduce the bug ?
- install point_of_sale,l10n_mx_edi
- In Point of Sale > Settings, add at least one Payment Methods
- Still in Point of Sale > Settings, create one Point of Sale
- In Point of Sale > Products > Products, select one product.
- In the Accounting tab of the product, set the UNSPSC Category.
- Go back on the dashboard of Point of Sale and start a new session.
- Add the product you have selected before and go to calidate the
invoice.
- Pick a payment methode and a costumer and check the invoice option.
- Validate the invoice.
- Close the session and go to Point of Sale > Orders > Orders.
- Click on the order you have just created and click on Invoice (in the
top right corner).
- Reset the invoice in draft.
- Wait for the cron task to be executed or execute it manually.
What is the bug ?
The cron task that send all the edi documents doesn't consider the state
of the account_move linked to it. Because of that if an invoice poster
is reset to draft, it will have a document and this document will be
sent.
opw-2925137
closesodoo/odoo#97648
X-original-commit: b27ff3c3c610102b2254acbad3801f21f0b36ef3
Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
The domain "id = False" for the visibility of the "Split Expense"
was set because I (wrongfully) thought it was necessary to save
the record before the wizard could use it.
That is not the case, as the button call will first save the record
anyway - it was weird not to have this button immediately and made
the feature hard to discover.
I also changed the "create report" button for the same reason - there
is no need to restrict its usage to "saved" records (unlike the
"attach receipt" button which is a specific widget that needs the record
to exist in database to work).
closesodoo/odoo#97634
Signed-off-by: Kevin Baptiste <kba@odoo.com>
According to
www.agenziaentrate.gov.it/portale/web/guest/schede/istanze/richiesta-ts_cf/informazioni-codificazione-pf
The tax identification number of natural persons
consists of an alphanumeric expression of sixteen characters.
The first fifteen characters are indicative of the master data
of each individual in the following order:
- 3 alphabetic characters for the surname;
- 3 alphabetic characters for the first name;
- 2 numeric characters for the year of birth;
- 1 alphabetic character for the month of birth;
- 2 numeric characters for the day of birth and sex;
- 4 characters, 1 alphabetic and 3 numeric for the Italian municipality
or foreign state of birth.
The sixteenth character, alphabetic, serves as a control.
The main fix is about this part:
When two or more individuals have master data generating
the same tax code (homocodes), the tax code is differentiated
for each of them. For this purpose, systematic substitutions
of one or more digits starting from the right one are made
within the seven numeric characters contained in the code
with corresponding alphabetic characters according to the
following table:
0 = L 4 = Q 8 = U
1 = M 5 = R 9 = V
2 = N 6 = S
3 = P 7 = T
Also the check for iva number format was incomplete.
Indeed, The three penultimate digits correspond to the region of the
VAT office and must be between 001 and 100 inclusive,
or equal to 120, 121, 888 or 999.
We use the stdnum library's methods for the validation of fiscal code
and iva number format.
opw-2797408
closesodoo/odoo#97633
X-original-commit: 262eb7bd021d177d9a05397f9cda3fc76a21d4cb
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
1. Add a few products to your cart.
2. Go to the checkout page, and stop right before clicking on 'Pay now'
(ie: customer goes to find the credit card and comes back later)
3. On another tab, go to the backend and cancel the sale.order
4. Go back to the website tab, and click on Pay now
5. Complete the payment process
Result:
* The customer is able to pay a cancelled order.
Expected:
* It shouldn't be possible to click on 'Pay now'
closes odoo/odoo#97630
Forward-port-of: #96549
X-original-commit: 37c3cf55d507e0bccf9db3e63503dfec896dfaef
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, milestone is still visible in project burger
menu even if we disable the milestone feature and due to that while
creating the milestone it was generating the traceback.
So in this commit, add groups on milestone option on project burger menu.
task-2918411
closesodoo/odoo#97629
X-original-commit: 1a7e2a298c2cbf076ce96dae85805f9dd77c7e0d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When issuing a refund for a reverse charge bill, the document type
should be the same as the parent bill type (either TD16, TD17 or TD18,
rather than TD04), and the values of the lines and totals should be
negative.
To fix this the values are made negative dependent upon whether the
invoice is a 'rc_refund' as in a "reverse charge refund". The way that
the document type is ascertained is also changed in order to include the
'in_refund' (for the case of the reverse charge refund).
The way document_total (ImportoTotaleDocumento) has been made
conditionally negative in the case when the invoice is a reverse charge
refund.
A test has been added for the reverse charge refund case, and the test
taxes have been adapted so that the correct tags are being used (and so
that tags are used on the refund lines).
closesodoo/odoo#97619
Ticket-id: 2936967
X-original-commit: ca2f4c8e1babe9444bc2c6a7421eafb63f1c9346
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Before this commit, opening a misc journal entry resulted in an error because we tried
to compute the tax totals as if it was an invoice.
This commit ignores the computation of these tax totals in case we have a misc journaly entry.
opw-2946634
closesodoo/odoo#97600
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Open Online Appointment in list view
=> a "double-border" is visible above the optional columns button
closesodoo/odoo#97592
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, modifiers containing conditions on the `id`
field weren't always correctly evaluated in form views. This
happened on new records, when the `id` field wasn't present in
the view. In this case, its value in the evalContext was
`undefined`, so a domain like `("id", "!=", "False")` was always
evaluated to true. The `id` field is handled a bit differently
than the other ones, as we do not require for the field to be
present to use it in modifiers (mostly because we don't need it
to be present to know its value).
This commit fixes the issue by forcing a `false` value for `id`
when the record has no id yet.
closesodoo/odoo#97587
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
odoo/odoo#87678 redesigned part of the search_panel however one of the
old bootstrap calsses was still used which resulted in sub categories
rendering poorly.
This commit changes that class to the new name.
closesodoo/odoo#97585
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When #96517 was merged, it was missed that if hr is *not* installed,
then the user profile opens in a dialog in edition mode (always, can't
be readonly).
Since half the tours of `auth_totp` end in the profile screen (to
check that the totp state is what we expect) this means they work fine
in most test contexts where `hr` is installed, but they fail as soon
as `hr` is *not* installed.
Fix this by adding a helper function which checks whether the profile
screen uses a dialog or not, and closes the dialog if so (otherwise it
does nothing as the "form" profile screen is not in edition mode).
While at it, improve a bunch of steps:
- fold check steps which were really `extra_triggers` (something we
wanted to check but not manipulate, in the same screen as something
we do want to manipulate)
- convert a few promise-based functions to `async` (tours don't
support promises but async functions work either way and lead to
simpler code here)
- make better use of the tour action helpers (no need for explicit
`_get_action_values` calls for the most part, and no need to
call the internal versions either)
- clarify a pair of fixmes as I'd completely forgotten what they meant
closesodoo/odoo#97567
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the column customization icon sometimes covers the
last column header in list views (or the 'ordering carret' icon).
Steps to reproduce:
- open Survey in list view
=> Avg Score column header overlaps with the icon
This commit adapts the headers last column's padding and the
customization icon's width to match each other and avoid overlapping.
It also adapts the vertical positionning of the icon.
task-2816987
closesodoo/odoo#97562
Related: odoo/enterprise#30165
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
`webclient/*` defines the main infrastructure for views and as such also
global components/utilities (like Odoo Icons variables/utility classes).
But, as the `views/*` are included *before* `webclient/*`, they can't
use SCSS variables defined in `webclient/*`.
This commit fixes it by interverting their order, which has a
significant effect on the SCSS output, but not the JavaScript (as the
modules system is responsible of the imports order, not the bundler).
Part-of: odoo/odoo#97562
When starting the import contact wizard from an active mailing list, the
mailing list to which the contact will be imported was not set. This solves the
problem.
Task-2924241
closesodoo/odoo#97560
X-original-commit: cdd102f30d2092fa31911ab2f00e90fec846165b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When importing email in mass mailing through the form (not with an excel file),
incorrect email lines were concatenated with the following next valid email
line, resulting to an incorrect import.
This solves the problem by ignoring incorrect email lines.
Technical note: the test test_mailing_contact_import has been slightly modified
to include invalid lines in the text to import, not only at the end but also at
the beginning and in the middle (the test fails before the fix and not after).
Task-2924241
X-original-commit: bd4a933f2b3259c3482b811227de0e06c7018969
Part-of: odoo/odoo#97560
Before this commit, if the header of a column (X2many/ListView) has the
focus, a record is being edited and a key is pressed, then a crash is
displayed.
closesodoo/odoo#97559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the agenda template to avoid displaying a complete column
for a location if that location is unused for this specific day.
This allows having multiple different locations for your different event days
without cluttering the display by showing empty columns for unused locations.
Task-2942630
closesodoo/odoo#97537
X-original-commit: 129b91027700313066db0305876adcf9b2a3817d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
1. Go to Inventory-->Settings-->Check option to "Display Lots & Serial
Numbers on Invoices"
2. Go to Rental App
3. Create a new Rental Order for a product that is tracked by Serial
Number. Pop up shows up. Also something to note here, though not
necessarily related to this ticket, but you cannot select available
serial number from this pop-up. It doesn't let you choose anything
even when there are multiple serial number available/in stock.
4. Confirm the order.
5. Validate the Pickup and set the Serial Number in the popup.
6. Create the invoice.
7. Confirm the invoice.
8. Print "Invoices without payment"
Bug:
in https://github.com/odoo/odoo/commit/7a030f616f7e04b3994fc718840d265b1dd21068
the filter functions were removed. They had the effect
of making sure that the sml is either a delivery or a return
by filtering on `sml.location_id.usage` and
`sml.location_dest_id.usage`
Fix:
check if the product is a delivery or a return by
making sure that either of `sml.location_id.usage` and
`sml.location_dest_id.usage` is `customer`
OPW-2936505
closesodoo/odoo#97532
X-original-commit: 953fefe736bab1cbfa3ecacd33cd1662a4dcf580
Signed-off-by: Adrien Widart <awt@odoo.com>
External images were linked to in the Recruitment email templates,
however those were not showing in the email client.
odoo/upgrade#3670
task-2908038
closesodoo/odoo#95630
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fixes a glitch on iOS (both iPhone & iPad landscape) where,
when the user attempts to open the datepicker of a custom filter's
field, it pops up and immediately close.
This is due to the desktop behavior which hides datepickers on scroll to
avoid hidding fields behind it.
In our case, a scroll is triggered once the focus is set in the date's
input and the virtual keyboard opens up... which then hides the
datepicker!
Sadly, this behavior's purpose being still useful in desktop, we don't
have much other solution than "just" disabling it on affected platforms
(ie. iOS) as it affects both small screens (ie. iPhones) and
dekstop-like ones (ie. iPad).
Hopefully, a better solution will be found at some point in a future
version, avoiding this kind of "trick"...
Note: replacing the "scroll" event with the "wheel" event seems to fix
the issue at first glance... but actually has side-effects for devices
using both touchscreens and a mouse (ie. 2-in-1 laptops).
Steps to reproduce:
- Open any collection view (list, kanban...)
- Open "Filter" dropdown and add a custom filter
- Choose a date/datetime field (ie. created_on)
- Tap the input
=> datepicker opens up and close immediately
opw-2671618
opw-2819299
closesodoo/odoo#97521
X-original-commit: 1895411d29b2b803c36bded11ba79c92e5c8756d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The widgets related to "custom" image filters in the case of background
images were never shown anymore since [1]. [1] is actually a
forward-ported version of [2] but the bug only appeared since [1] as
the forward-port adaptation created the error: the widgets of this
option were not shown or hidden before... but simply not rendered at
all, kinda by mistake. The adaptation in [1] used the conventional way
of doing things by using the `_computeWidgetVisibility` method to
indicate if widgets should be shown or not. The problem is that an
error was done when writing that visibility condition.
[1]: https://github.com/odoo/odoo/commit/89ce9f9ab5b8db148c273f70be0a06c768892566
[2]: https://github.com/odoo/odoo/commit/7c17d78fbdbb64b1aa5b55f78d3202a64a85ed2fclosesodoo/odoo#97514
X-original-commit: 10a48dc213117c4ac29b1ce56d3f1c02e58111d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Have a color field with an onchange on it.
Change the color.
Before this commit, the onchange was not passed to the server. This was
due to the internal of ColorField, which refreshed its value to the old one
even before owl or odoo did anything.
After this commit, the call to onchange is correctly passed.
closesodoo/odoo#97476
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Spawn a form view with a record and set its props "mode" to readonly.
Click on "Create".
Before this commit, the new record was in readonly mode.
This is never what we want, we always want a new record to open
in edit mode.
After this commit, the new record is in edit mode.
closesodoo/odoo#97451
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when the kanban view is grouped by m2o field, the
columns can be resequence by doing a drag and drop on one of them. In
some cases, this resequence should be disabled to keep the order of the
columns in the kanban view. For instance, in the project sharing
feature, the views are accessible by the portal users to easily follow
the tasks in the project shared but the actions allowed to the portal
user are restricted to only one model (that is `project.task` model).
So, in that case, the order of the columns should always be the same.
To avoid doing a customization code to be able to prevent the
resequence of columns in the kanban view, this commit adds a new option
in the kanban view called `groups_draggable`. By default, this option
will be true to allow the user to resequence the kanban columns
(if the field used for the group by is a m2o and not readonly).
If the option is false then the resequence of the kanban columns will
be disabled.
task-2941335
closesodoo/odoo#97447
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the parameter sent to the legacy fields were
different if the field was used on the form view, or on the kanban/list
view. Specifically, the attrs were not sent when the field was use on
the form view, and the viewType was not send when the field was use on
the kanban/list view.
Now, we standardize the parameters sent to the legacy fields regardless
of the view they are used on.
closesodoo/odoo#97431
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Lucas Perais