Before this commit, having two RadioField fields with the same values
was going to confuse them. When you click on the second, the first is modified.
Why:
The id used to link the label to the field's input was mistakenly
removed during refactoring. So we're going to put it back, and each radio
field will have its own id.
closesodoo/odoo#131663
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, in a survey, opening a question, discarding it and then reopening it no longer displayed the content of the responses.
How to reproduce
In QuestionPageOneToManyField, we overwrite the behaviour of openRecord by reloading the record to be opened. This is no longer necessary since PR 129507 as the correct record is retrieved which already contains the updated values.
How to reproduce:
Go to a survey
Click on a question with answers
Click on discard
Click on the same question
Before this commit:
Response data not displayed
After this commit:
The answer data is displayed correctly
closesodoo/odoo#131662
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, editing a x2m record in a dialog then clicking on
the close button (X) does not discard the change.
How to reproduce:
- Go to a form view with an x2m in non-editable list mode
- Click on an x2m record to open it in a dialog
- Edit a field
- Click on the close button (X)
Before this commit:
The change is kept
After this commit:
The change is discarded
Part-of: odoo/odoo#131662
Before this commit, in the form view, clicking on an action in the menu
action executed the action even though the record save had failed.
Expected behaviour:
When you click on an action, you want to save the record and execute the
action if the record was saved without error.
How to reproduce:
- Go to a form view
- Create a new record
- Edit a field to ensure that the save returns an error
- Click on an action in the action menu (for example duplicate)
- The "Oh Snap" dialog opens
- Click on "Discard
Before this commit:
The button action code executes and displays a crash
After this commit:
The button action code does not execute
closesodoo/odoo#131660
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The cause of the issue is that `datetimepicker('viewDate')` will return
the datetime of today by default event if the user selects nothing, to
remedy this, we now check if the user has chosen something before
storing the content of the field in `form_values`.
Step to reproduce:
- Install website_crm_partner_assign to have the "Partnership Date"
field on res.partner.
- Install website_sale to have the "Create customer" capability on the
website forms.
- Drag & drop a form snippet on any page
- Select "Create customer" as form action
- Add a custom field "Partnership Date"
- Submit the form without filling the Partnership Date field
- The field will be set to today's date while it should have been left
void.
opw-3333364
closesodoo/odoo#131614
X-original-commit: 0a5668d36cc43cf346c5aecb9236d690a6694a45
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, for products with attributes that do not create
variants but do carry additional costs per value, the discount
displayed on the PoS receipt inaccurately represented the price
difference based solely on the list price, excluding these additional
attribute prices. This commit corrects this issue to ensure that the
displayed discount on the PoS receipt and product screen accurately
includes any extra price from such attributes.
Steps to reproduce:
1. Create an attribute with "never" "Variants Creation Mode"
2. Add two attribute values
3. Add this attribute to a product and add an extra price
4. Enable "Discount on lines" on the user setting
5. Change the "Discount Policy" of the pricelist that is used in
the PoS to "Show public price & discount to the customer"
6. Open a PoS session and add the product with an extra price
attribute to the order
7. Add a line discount to the order line and validate the order
-> The discount amount is based on the listing price of the product
opw-3297713
closesodoo/odoo#131606
X-original-commit: 25f293ee6f601df5b2216d419ec0215710b9fef0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This commit fixes an issue causing website's `systrayItems` to don't be
styled correctly.
task-3446638
part of task-3326263
closesodoo/odoo#131099
X-original-commit: 902634b5af29021e85c0232673cf5c0df0120ac3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The sequence number, if present, was to be valitaded to match the invoice date.
However, this legimitately strict constraint would stop saving a draft invoice with an incoherent sequence number, for instance draft invoices or invoices being scanned by the OCR.
Added an extra condition deactivating the sequence check unless the action is to post the invoice.
task-3451883
closesodoo/odoo#131591
X-original-commit: 00c34755e609e2d2ad7706ead3c188266fbe529f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce
==================
- Go to project
- Switch to the list view
- Remove some optional fields
- Click on the export all button next to the "New Button"
The optional fields configuration are ignored and all fields are
exported.
Cause of the issue
==================
The `optionalActiveFields` are not taken into account when computing the
`defaultExportList`.
This was the case in 15.0
opw-3452459
closesodoo/odoo#131594
X-original-commit: 2a397cb5bb89d1a10e7ac765ff9035c102fbb436
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
In b1e2c3453f50cc05a1b03dc1c8571a01ad7b7dd2, the `res.users.settings`
model was moved from `mail/` to `base/`, but its record rules remained
in `mail/`. This means that if `mail/` is not installed, users will be
able to access other users' `res.users.settings` records. In practice,
this is not a problem, as the only field that can exist in
`res.users.settings` without `mail/` is `homemenu_config`, which
contains nothing senstive.
This commit moves the forgotten record rules to `base/`, preventing
potential problems if new fields with sensitive information were to be
added to `res.users.settings` in the future.
Task-3461652
closesodoo/odoo#131538
X-original-commit: 5a79550c8e35ce733375c2ef7df2ea12e6added6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before 16.0, optional columns used local_storage service that used
JSON.stringify and JSON.parse to store values and so the object were
directly usable.
Since 16.0, we are using the localStorage API directly, so when checking
if a optional field is enabled, we just check for example:
_.contains('currency_id,partner_id', 'id')
which returns true but shouldn't => this causes for example the ID field
to not be hideable.
note: this commit makes makeRAMLocalStorage (used for safari incognito
and tests) consistent with localStorage that stores values as string.
note: the added test without the fix, fails with:
should have 3 th, 1 for selector, 1 for columns, 1 for optional
columns ever after listview reload. Expected: 3, Result: 4.
opw-3339416
closesodoo/odoo#131309
X-original-commit: 922bd446708e05c2368a01b2399855845246885b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Problem
---------
When an invoice or bill has been canceled, the Due Date for the payment
is still showing, even though this information is not relevant anymore
as no payment is expected.
Objective
---------
Make due date invisible when the invoice/bill is cancelled.
Solution
---------
Modify the invisible attrs condition of the field in the account_move
tree view by add a condition on the state.
task-3439357
closesodoo/odoo#130028
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Following the rework of global ACLs here:
odoo/odoo@7dd1796eb7
Public users cannot access the event.sponsor.type model anymore.
This caused the sponsor "closing hours" modal to not be shown anymore, as it
raised an access error.
To fix the issue, we sudo the sponsor type access in the controller that
retrieves the sponsor data to render the template.
Task-3459726
closesodoo/odoo#131537
X-original-commit: 98c01e65277a816ec4010f3c6902953366d35cbc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.
Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
- Save the record.
- The server will stop running and not be accessible.
Error: ValueError: CSRF protection requires a configured database secret
sentry - 4291267997
closesodoo/odoo#131460
X-original-commit: fe694e5b8285ceed99b321c22af534eee25cf282
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since 6f182eeeab,
UoM should be created through the UoM category tab as the UoM form view is now unusable.
Previous bugfix commit 58a3954d606d48b2a4cf678eb0bf13d6e28b1aef disabled
the menu from the different applications, but later changes in sale
brought back the menu again.
Since it doesn't hurt to have the menu in debug mode, the lowest solution
would be to disable the creation of uoms from the uoms tree view.
closesodoo/odoo#131237
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this PR we fix a number of small issues related to the pos ui.
In addition to the specific fixes, this PR also simplifies many
of the components, most notably the `category_selector`.
In the interest of providing a cleaner API, this PR introduces
a new folder called `generic_components` whose goal is to contain
stateless components. These stateless components would allow for more
reusability, while simplifying the logic. The `category_selector` is
the first component in this folder.
Descriptions of each of the issues fixed in this PR can be found in the
closesodoo/odoo#131038
Tasks: 3457213
Related: odoo/enterprise#45600
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before:
When number of available domains exceeded the display limit, user was
unaware of the other available domains as nothing in UI indicated so.
Visible entries change only when user starts typing something.
After:
This commit adds a 'Start typing...' entry after visible models in
dropdown menu whenever number of available models exceed the display limit,
in order to provide a hint to the user.
When user starts typing, 'Start typing...' entry disappears and all available
domains are displayed with a scrollbar.
Task ID : 3375332
closesodoo/odoo#126156
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
RATIONALE
This prepares the move of ICP to mail before replacing them by dynamic alias
domains.
Cleanup tests: try to use loops with input / expected to better understand
the various test cases, add some comments, improve logs when failing to
find the right sent email. Rename tests to have a better test structure
when reading logs.
Remove a test from odoo/odoo@3b6c20805c that adds nothing except testing
the test suite.
OTHER ADDONS
In test_mail: have a specific class for testing servers as other data is
not necessary, and it allows to have a tag for it.
In mass mailing: concatenate test about server finding, several tests can be
done in a single unit test.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-3453347 (Mail: Move Mail ICP from Base to Mail)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#131492
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit there are no rollback if raise.
closesodoo/odoo#131490
X-original-commit: 0015662d166f5e07bcbd6c5e9e14f8837ffa58a3
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Issue:
The currency in the RFQ created from the list created RFQ on the Purchase Agreement is incorrect.
Steps to reproduce:
- Install Purchase Agreement
- Config multi currency
- Create a Purchase Agreement with multi currency (difference main currency) > Confirm
- Click smart button RFQs/Orders > Create
- RFQ will default currency is main currency
Fix:
Add a context on button `action_purchase_requisition_list` to default currency
closesodoo/odoo#131489
X-original-commit: ff001848a2e4906dbf5401508cc0ff2185265eac
Signed-off-by: Tiffany Chang <tic@odoo.com>
With this commit you wil have the function _get_gather_domain so you can
override and manage the gather_domain by your own logic
closesodoo/odoo#131476
X-original-commit: 92b6fd647c77ae88dfb685654ba9e9f14b7a1d03
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The _compute_amount_residual method computes residual amounts on reconcilable
account move lines. As it uses an sql query for an efficient computation it
discerns stored records from new records (having a new id) by filtering out
records with a falsy id field (new ids are always falsy). It then proceeds the
computation for stored records only.
The bug arises when the compute method is called on records during an onchange
call, as the records get reassigned a new id as well. This can be seen when
opening the total due followup view and toggling the blocked field on any of
the unreconciled entries. The problem is resolved by including records during
an onchange in the computation: in practice the computation can simply be
carried out on all _origin records.
opw-3388389
closesodoo/odoo#131465
X-original-commit: 3d52fca2979cc4bfe87540122ea7cc979040be4f
Related: odoo/enterprise#45591
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Tom De Caluwé (tdc) <tdc@odoo.com>
Versions:
---------
- 14.0+
Steps to reproduce:
-------------------
1. Settings -> Configure document layout
2. Select the Boxed layout
3. Go to Invoices -> create a new invoice and register payment
4. Click on Preview
5. The field “Amount due” is in the wrong color and barely visible
Issue:
------
The field “Amount due” is in the wrong color and barely visible in
invoice boxed layout
Cause:
------
The issue is happening because we have `<strong>` before the text
”Amount due” and it changes the font color to gray because of the CSS definitions
Solution:
---------
We need to make the text bold in a different way, to do it we can use the bootstrap
class font-weight-bold, this way we keep it bold and do not break the colors
OPW-3374092
closesodoo/odoo#131459
X-original-commit: 6e1b3f2fc36831a94c164ab281c7a6fde535cebf
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>
the default model 'useAction' service is now named 'action' no longer 'actionService'
Changed the reference where needed
closesodoo/odoo#131452
Related: odoo/enterprise#45583
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Improve Send & Print general usability by making it more streamlined overall.
Options are not activated but preemptive problematic partners are shown,
and skipped during the sending process.
closesodoo/odoo#131448
Task-id: 3336623
X-original-commit: 4105994e778459c869d885d017118492ffcd2064
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
Before this PR a huge padding was present when editing a message
on the chatter. This commit fixes the issue.
task-3458670
closesodoo/odoo#131432
X-original-commit: 332942109b0db7a96da3bd2e7f2cafe19ebb1df3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit replaces notification.notify with notification.add so that
it works without the legacy notification service.
Steps to reproduce:
- go to website settings
- add a new website with any name
- follow the steps and upload an invalid file as the logo
fix for https://github.com/odoo/odoo/commit/caefcb8590301a0ebbe947a875003b33ce7d537a
task-3338012
closesodoo/odoo#131422
X-original-commit: 0d7971e0ed7eee5b5e983c27a13c6a34457f4505
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As explained by ANV (https://github.com/odoo/odoo/pull/123237#pullrequestreview-1537263584), the override of _set_authorized method of payment.transaction model is currently dangerous and should be removed.
Indeed, he explains that any error in the _set_authorized method will remove the transaction from the database, even if it is successful.
According to him, the current safe approach is to only override _reconcile_after_done to catch successful transactions and process them safely.
closesodoo/odoo#131408
X-original-commit: b12f6df9e497fd0546c91f88f94f92dc5b606373
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The template `web_editor.assets_edit_html_field` was not used nor
required anymore. The files under that bundle were already included
in the backend.
The template under the key `cssEditAssetId` in html_field.js is in fact
loaded in wysiwyg_iframe.js through the option iframeCssAssets.
Moreover, the line `await getBundle` was doing nothing meaningful as
the bundle assets would not be loaded after being fetched.
task-3446819
closesodoo/odoo#131365
X-original-commit: 4eebfcbdf5428cd1c53bafcd89da7095964ff384
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Description of the issue/feature this PR addresses:
When an accountant adds an invoice at another date than the date of the
said invoice, it is that date that is shown on the journal entries and
items views. This makes it impossible to order the lines by invoice date
as the only date field available on those views does not give the proper
piece of information.
Current behavior before the PR:
Prior to this commit, the Journal Entries and Journal Items views show no
column giving the date of the document for every line but only for those
that have been added the same day.
Desired behavior after the PR is merged:
Adding this, the Journal Entries and Journal Items views show a "Document
Date" column which represent the date of the document. The bank
reconciliation widget presents this column too. In each of these three
locations, filters, groups and ordering have been setup to be able to be
applied on this new column.
This allows to search and filter lines using that piece of information.
The column is hidden by default.
task-3388309
closesodoo/odoo#129040
Related: odoo/enterprise#44545
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
The South African chart of accounts needed an update regarding its content
This PR updates the CoA to its newer version.
task-3391846
closesodoo/odoo#128700
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
On a putaway rule, the "Having Category" condition is not always
respected.
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- L2 only:
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock
- Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
- 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations
Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2
When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.
OPW-3437174
closesodoo/odoo#131361
X-original-commit: 66c11acdbedf8d1bcae6deb8ec54c5da5a3ae16d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
As described in #129974, the colorpicker cannot cache a promise
protected by `useService`. #129974 fixes the issue by through non
idiomatic practice (calling a service that is not protected by
`useService`). This commit fixes the issue idiomatically.
This commit caches the promise directly from a service and removes the
caching code from the `ColorPalette`.
task-3446691
closesodoo/odoo#130789
X-original-commit: 1d2e54088b0f0e28464ab6aa884fb2e1110e8e04
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This error occurs when the user manually attempts to change the mimetype of the
attachment, and then the base function `_postprocess_contents` tries to
determine the type and subtype of the attachment.
Error: `ValueError: not enough values to unpack (expected 2, got 1)`
To address this issue, this commit introduces a check for the mimetype of the
attachment before attempting to determine its type and subtype.
sentry-4283372480
closesodoo/odoo#131333
X-original-commit: fade78ed98e6902ab5465e40d2b1bf7aa282688b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
The "test_active": False context of the field specifies that this field
will ignore whether a record is active or not when fetching it.
Due to recent changes in the javascript, the "test_active": False
context of the tax_ids field on the account move model is propagated
through into the name_search query. This means that inactive taxes
appear in the dropdown when selecting a tax.
This is an issue as there are a few localisations that hide a number of
their taxes by default (by making them "inactive").
The solution is to add the key, value pair "active_test":False to the
context of the field on the view, effectively overriding the context
that gets used in the name_search query, thus only retrieving active
taxes.
closesodoo/odoo#131212
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
*: website
Some specific media items are meant to be editable even though located
in non-editable environments. The typical case in 15.0 is the website
"Team" snippet: it is made of multiple bootstrap rows, each containing
a column with an image and a column with texts. The columns with the
image are only meant to hold that image, it was therefore marked as
non editable to prevent users adding text in there by mistake... but the
image is still meant to be editable. See [1], later fixed by [2].
The problem now is that the system that [2] had to use is quite messy:
the column is marked non editable thanks to the `o_not_editable` class
but the inner images were to be declared editable via some custom JS
method overrides (`_getContentEditableAreas`). The debate about if we
should keep a class-based system and/or a method-override system will be
left to master. This commit although comes with an uniformisation about
this, introducing a new class to declare "an editable media despite its
non editable environment". This is not a counter-part of the class
`o_not_editable`: we do not want the media to be marked with the
`contenteditable` attribute. Indeed, this is actually required since [2]
was not enough to solve the problem. See those steps:
- Add a company snippet in your page
- Change one of the images by an icon
- (Save / Reenter edit mode)
- Try to change the icon again / edit its options
=> You can't. Indeed [2] relied on the media being an image to re-enable
edition on it... but even if it did not, it would not have been enough.
Indeed, icons are forced to being `contenteditable="false"` by the new
editor library (since 15.0 then), last update on that at [3].
We thus needed a different way to differentiate editable media, hence
the introduction of the new `o_editable_media` class.
Note: this system is not perfect, but so is not the whole system about
determining what is editable or not at the moment. In this case, it may
exist cases of a media marked with the class to be editable but end up
in an environment which is not editable by force (xpath somewhere etc)
... and ends up being editable anyway. Most cases work though and at
worse it will be about a non editable image being editable but not
possible to save in very rare cases. As advertised, the whole system
about what is editable or not should be improved.
[1]: https://github.com/odoo/odoo/commit/30db617bc8ff7727f40d7ef58c6578e84a13f284
[2]: https://github.com/odoo/odoo/commit/61270ee8bffb6e85f8ff0d19c7a3889fdce2f486
[3]: https://github.com/odoo/odoo/commit/7646429e894f28f398b7b212e893822c06c7b03d
task-3226172
closesodoo/odoo#131139
X-original-commit: 436265e815684046a37a8b80e4cd520c2bd637f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] refactored the event handler code in charge of handling
double click on media elements to edit them. A mistake was made making
the code consider inner elements of the media instead of the media as a
whole when clicking on it.
Steps to reproduce:
- Enter edit mode on the homepage
- Add a text-image snippet
- Change the image to a video (after dblclick on the image for instance)
- Try to change it back with a dblclick => it does nothing
[1]: https://github.com/odoo/odoo/commit/8ca115b3b9dfe87b59b6b064a4d85ea152d9214c
X-original-commit: 4b47ae0022a3e50d53dc02e399412585fc2131ef
Part-of: odoo/odoo#131139
Before this PR, when moving the snippet's position, `d-none` gets added
which should not.
With this PR, removing the `this.$target.addClass('d-none')` from
`cleanForSave` method as it was adding `d-none` unnecessarily while
moving snippets position. The fact is snippet will be hidden if the
current user has no access to the mail group. So that case will be
handled using controllers route `/group/is_member`, if this return email
of the user, snippet is visible else the user has no access to the mail
group so we remove the snippet.
task-3107451
closesodoo/odoo#131131
X-original-commit: 51e92d022d50a7a4adaca872d42849eeaf64f88d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min
It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough
closesodoo/odoo#131307
X-original-commit: cad75ac78b61046352c39d3f3b7717cfbad42c8b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
PURPOSE
=======
Starting from 16.0 we introduced some reports to log skills history, skills evolution.
It means that the skill model is linked to another model, preventing us to delete it.
Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task)
So, we need to be able to delete a skill on v16
closesodoo/odoo#131300
Taskid: 3456843
X-original-commit: d9672b55e7a596778fd542541f39e5216c06cb40
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
FrancoisGe